More Custom Weapon FX problems

[Argh]

Now that I have the basic issues of "how to get things working, period" sorted out... here's what I'm seeing, and my opinions and problems.

1. I have found that the default Resources.tdf is taking precedence and apparantly over-writing my Resources.tdf. Even after correcting for the case-sensitive stuff, I have found that I have to write my new weapon textures to Spring's root Resources.tdf in order for them to be loaded by the engine

This is clearly more than just a case-sensitivity bug. There's something borked about the way that the engine is loading things into TextureAtlas- I think it loads everything that's called by the default Resources.tdf first, then ... it doesn't seem to load anything else.[/] This is, obviously... not good. I'm not calling any dependencies- Spring should never be loading the default bitmaps or the default Resources.tdf file in the first place.

This is in addition to the case-sensitivity bug Tobi was able to find and squash.

2. Weapon textures for EmgProjectile and ExplosiveProjectile aren't aligning with the vector Y that they are being fired along. This means that anything that isn't circular doesn't exactly work out

Lasers and missiles work just fine. However, EmgProjectile and ExplosiveProjectile, and I presume the FlameThrowerProjectile... are not. This should be pretty easy to fix.

The "standard" for which direction X,Z on a 2D bitmap is "forward" is usually that the left-hand edge is "forward". I don't care which direction it is, so long as it's something other than nothing...

3. Please, devs, get rid of the drawing code that draws these projectiles multiple times. It's a complete waste of rendering resources and results in massive overdraw that is entirely un-necessary now that we have a better way.

4. Last but not least, content designers should be made well aware of the content specifications for each effect... and, whenever possible, these should all be the same.

For example, I have discovered that the TGA used by EmgProjectile and ExplosiveProjectile is not a 24-bit TGA with an all-white alpha, like my new LightningDefault is. Nope... it's a 32-bit TGA with an 8-bit alpha! While I can see the point of having this, so that we can have multi-colored shots, this is the kind of thing that must be documented somewhere, or newbies are going to be tied into knots

[Argh]

Regarding the TextureAtlas problems, here's a quick proof:

This is the one sitting in my Spring root/gamedata folder:

Code: Select all

[resources]
{
	[graphics]
	{
		[smoke]
		{
			smoke00=smoke/smoke00.tga;
			smoke01=smoke/smoke01.tga;
			smoke02=smoke/smoke02.tga;
			smoke03=smoke/smoke03.tga;
			smoke04=smoke/smoke04.tga;
			smoke05=smoke/smoke05.tga;
			smoke06=smoke/smoke06.tga;
			smoke07=smoke/smoke07.tga;
			smoke08=smoke/smoke08.tga;
			smoke09=smoke/smoke09.tga;
			smoke10=smoke/smoke10.tga;
			smoke11=smoke/smoke11.tga;
		}
		[scars]
		{
			scar1=scars/scar1.bmp;
			scar2=scars/scar2.bmp;
			scar3=scars/scar3.bmp;
			scar4=scars/scar4.bmp;
		}
		[trees]
		{
			bark=Bark.bmp;
			leaf=bleaf.bmp;
			gran1=gran.bmp;
			gran2=gran2.bmp;
			birch1=birch1.bmp;
			birch2=birch2.bmp;
			birch3=birch3.bmp;
		}
		[maps]
		{
			detailtex=detailtex2.bmp;
			watertex=ocean.jpg;
		}
		[groundfx]
		{
			groundflash=groundflash.tga;
			groundring=groundring.tga;
			seismic=circles.tga;
		}
		[projectiletextures]
		{
			circularthingy=circularthingy.tga;
			laserend=laserend.tga;
			laserfalloff=laserfalloff.tga;
			randdots=randdots.tga;
			smoketrail=smoketrail.tga;
			wake=wake.tga;
			flare=flare.tga;
			explo=explo.tga;
			explofade=explofade.tga;
			test=test2.tga;
			muzzleside=muzzleside.tga;
			muzzlefront=muzzlefront.tga;
			largebeam=largelaserfalloff.tga;
		}
	}
}

This is the one in NanoBlobs 0.60:

Code: Select all

[resources]
{
	[graphics]
	{
		[smoke]
		{
			smoke00=smoke/smoke00.tga;
			smoke01=smoke/smoke01.tga;
			smoke02=smoke/smoke02.tga;
			smoke03=smoke/smoke03.tga;
			smoke04=smoke/smoke04.tga;
			smoke05=smoke/smoke05.tga;
			smoke06=smoke/smoke06.tga;
			smoke07=smoke/smoke07.tga;
			smoke08=smoke/smoke08.tga;
			smoke09=smoke/smoke09.tga;
			smoke10=smoke/smoke10.tga;
			smoke11=smoke/smoke11.tga;
		}
		[scars]
		{
			scar1=scars/scar1.bmp;
			scar2=scars/scar2.bmp;
			scar3=scars/scar3.bmp;
			scar4=scars/scar4.bmp;
		}
		[trees]
		{
			bark=Bark.bmp;
			leaf=bleaf.bmp;
			gran1=gran.bmp;
			gran2=gran2.bmp;
			birch1=birch1.bmp;
			birch2=birch2.bmp;
			birch3=birch3.bmp;
		}
		[maps]
		{
			detailtex=detailtex2.bmp;
			watertex=ocean.jpg;
		}
		[groundfx]
		{
			groundflash=groundflash.tga;
			groundring=groundring.tga;
			seismic=circles.tga;
		}
		[projectiletextures]
		{
			circularthingy=circularthingy.tga;
			laserend=laserend.tga;
			laserfalloff=laserfalloff.tga;
			randdots=randdots.tga;
			smoketrail=smoketrail.tga;
			wake=wake.tga;
			flare=flare.tga;
			explo=explo.tga;
			explofade=explofade.tga;
			test=test2.tga;
			muzzleside=muzzleside.tga;
			muzzlefront=muzzlefront.tga;
			largebeam=largelaserfalloff.tga;
			lightningdefault=lightningdefault.tga;
			plasma_spam=plasma_spam.tga;
		}
	}
}

Unless the two lines:

Code: Select all

			lightningdefault=lightningdefault.tga;
			plasma_spam=plasma_spam.tga;

... are present in the resources.tdf located in root/gamedata, these textures are clearly not being added to textureatlas- they draw as semi-transparent squares, instead of using the textures defined. If I define the textures there... everything works.

[Argh]

And as for the texture mis-alignment and the un-necessary overdraw... here's the screen:

[Tobi]

1. I have found that the default Resources.tdf is taking precedence and apparantly over-writing my Resources.tdf. Even after correcting for the case-sensitive stuff, I have found that I have to write my new weapon textures to Spring's root Resources.tdf in order for them to be loaded by the engine

This is clearly more than just a case-sensitivity bug. There's something borked about the way that the engine is loading things into TextureAtlas- I think it loads everything that's called by the default Resources.tdf first, then ... it doesn't seem to load anything else.[/] This is, obviously... not good. I'm not calling any dependencies- Spring should never be loading the default bitmaps or the default Resources.tdf file in the first place.

I ask again, did you use a version where the Resources.tdf was distributed as a normal file? Ie. does C:\Program Files\TASpring\gamedata\resources.tdf exist?

Normal files override VFS files in any case currently. Hence we'll ship the gamedata/* stuff in an archive with 0.73 (so it can actually be overridden). See also this thread on the ML.

So, remove C:\Program Files\TASpring\gamedata\resources.tdf and optionally put it in springcontent.sdz (which is where it will be in 0.73) and things _should_ work...

[Argh]

Aha!!! I apparantly missed that part of your post, Tobi!

Yes, I am basically throwing new versions of 0.73b exe into the test-build distributed on 8/6/2006, where that file did exist!


.... comes back from testing...

It works!!! Thank goodness!

Now back to making more FX for the NanoBlobs release

[KDR_11k]

Shouldn't files in the mod's file systems (virtual and real) take precedence over any files in the root filesystems?

[Tobi]

That's what I personally think too yes, but I didn't want to push such a major change in behaviour through without consulting others. Guess I'll raise the issue on the ML again...

[Argh]

+1 to the above, if it helps any. I dunno why it's the inverse, to be honest- it's likely to cause all sorts of problems unless it's veeeeery carefully dealt with, as my somewhat-fumbling early experiments have been showing.

[jcnossen]

If it can be fixed easily with an archive why change to more complicated solutions?
We could also just move gamedata to gamedata.sdd/gamedata

[Tobi]

Swapping the priority is a matter of seconds (I actually use the swapped version locally here, because I found that much more convenient , so I can commit it anytime we want...).

Just swapping the 2 pieces of code in CFileHandler (the one that loads from ifstream & the one that loads from VFS) ...

[patmo98]

Swapping the priority is a matter of seconds (I actually use the swapped version locally here, because I found that much more convenient , so I can commit it anytime we want...).

Just swapping the 2 pieces of code in CFileHandler (the one that loads from ifstream & the one that loads from VFS) ...

All that we need to do is just put the files into an arcive that is a dependency of something in base/

I think that it's inportant to keep it the way it is for two reasons. First, it will make people less confused when they switch from OTA. Second, and more important, it makes it very easy to work on mods. All you need to do is change an uncompressed file. You don't need to repack an arcive every time.

[Tobi]

You don't need to repack an arcive every time.

That wouldn't be needed when it's swapped either - you can use .sdd archives in any case.

I don't really care anymore once we properly get rid of all real files in trunk/game and in the release, but until now I have seen more arguments pro-swapping then against.

[Argh]

Having read the SVN ML back-and-forth, it appears that there is also consensus that this would be a good change. I hope that this is done, to prevent problems in the future, as mods are going to want to override almost everything (including things like shaders, I suspect) as Spring becomes more advanced.