Spring Dev build, 073b1, first impressions

[Argh]

Short bug report, then I've gotta get back to the mod and do some more work.

1. It required Python (and not just any Python, either- it had to be 2.3, which is older than current) to be installed before I could fire up the client.

2. It crashes on not finding anything in gamedata/particles, but there isn't any documentation saying what, if anything, needs to be in that file to make it go. After going through the SVN notes, I found AF's cryptic notes about making the following entries:

Code: Select all

 [nanospray]
{
allow_team_colours=1;
}

... there are no other notes documenting how to turn off the nano particles anywhere... which was a bummer, since that's one of the main things I wanted to test.

3. The reflective water is gorgeous and much faster than the dynamic stuff, but it doesn't seem to handle explosiongenerator groundflashes correctly yet.

4. There's a a very weird aiming bug going on that's affecting certain units. I strongly suspect it's the ones with custom aiming arcs... where I wrote custom BOS code so that they'd aim properly in the first place- a hack for the last version of Spring. I'll test this assumption and report back. I assume this has to do with finally fixing the weapon-arc problems with things like the Strider, so that they steer towards their closest enemy, instead of charging right past them. However, without an AI build to test with, this is pure speculation.

5. I'd really like to see a NTAI build for this, so that I can do more practical load-testing than just building 500 Wolves and telling them to converge and attack a single point (which is hilarious btw).

6. I see we're now using the Flare graphic as the default graphic for flamethrowers, but the SVN, if I recall correctly, implies that this can be customized somewhere. I should probably read through those commits and find out how I'm going to test this nifty new particle code... and determine whether the big bugs with hit-detection, which seems to affect most of the weapons using FX (most especially beamweapons and beamlasers) have been resolved... otherwise this Great New Thing will actually be a big waste of time. Yes, I know... hitscan stuff is boring as all get out. The thing is, the different Weapon Types aren't all using the same code. The code for models works great, the code for things with FX does not. Personally, I think that the best way to resolve this would be:

A. All Beamweapons, Beamlasers, etc., on each firing event, fire TWO THINGS: a particle/fx object (our graphical effect) and a S3O point-object (included in a new revision of Base as, say, "point.s3o", just in case some modder really needs to alter it) with a Radius of 1.0. Both objects, needless to say, have to travel the exact same path, or this is all pretty pointless.

B. Now have all of these Weapon Types use the .S3O-models-as-weapons code to determine hits, using that point object, and cut out the now-redundant code for the special cases. Voila... now we'd have fancy FX and proper hit-detection, which would make us modders happy... and it would be one fateful step towards finally arriving at a unified Weapon Types model

7. We really should have the ability to draw ground patches beneath moving units. Then we could finally have fake "blob" shadows, or even fake-perspective raytraced ones, that would be faster than drawing raytraced ones. I'm not even saying I prefer this option to the current shadow code, which is quite pretty. I'd just like this to be an option, so that I could maybe offer an "NanoBlobs for the Computer-Impaired", or whatever, with fake shadows.

8. I see that the bug Caydr reported (and that I have supported, with screenshots) with the Origins of S3O models getting displaced during rotational motions has not been fixed. This is a serious problem on three levels:

A. Flying objects, as they turn sharply or spin, are getting the hitsphere displaced by as much as the original radius. After testing, I have determined that this happens when the hitsphere is not at precisely 0,0,0...

B. It is apparant that the real positions of the model's XYZ is not the position of the model's actual geometry! This makes very little sense... among other things, it implies very strongly that S3O objects are being, in fact, tracked at least twice. This is almost certainly because of the un-abstracted 3DO code and the areas where S3O was shoehorned in, so I guess we'll just have to live with it until a mighty coder can clean this mess up.



...that's it for now. I'm going to test the Friendly-Fire stuff and see if I can resolve the aiming bugs I'm observing with limited-arc units (again, this is probably caused by my hack-around for the last version, so I'm withholding conclusions until I'm done).

If the Spring developers would like, I will release an interim version of NanoBlobs using all of the new features as soon as I have it ready, for testing purposes.

[Argh]

Also:

1. Lightning weapons do not allow for explosiongenerator code, and use default explosiongenerators yet.

2. I can't quite figure out how I'm supposed to invoke the Large Beam class of weapons, to test the FX. I read through the code in WeaponDefHandler.cpp, but I'm still confused. Is it basically, "beamlaser=1" and then... er... a "tile1=FileName.tga" + "tile2=FileName2.tga" and "scrollspeed" "tilelength" and "pulsespeed"?

3. How do I set up new Muzzleflashes? I see the new TGAs in there... how do I invoke a new one?

4. How do I set up new Groundflashes? Same question... I assume this is a line that needs to be in my Explosion definition?

[Argh]

There's updated documentation in Docs! Yay!

Back to work...

[Argh]

Bah! I've been trying to make an updated and prettier LightningDefault texture for y'all, to be GPL'd and included with Spring.

Well, there's a minor problem with that: no matter what I do, it doesn't seem to want to draw

My TGA is 32-bit, with an all-white alpha channel, just like the existing graphics. I've tried 24-bit and 16-bit too. No matter what, the darn thing doesn't work

Here's a GIF version: ... it may not look quite totally professional yet, but I think you will be surprised... I made it specfically to tile.

I've tested with the default largelaserfalloff, and it works just fine... just not the new one. And yes, I have a Resources.tdf in my mods Gamedata folder, and yes, I wrote a line in Resources that according to the files, should be correct. I've also tried just replacing the default largebeamfalloff with the new file... no good, same problems.

This is all very frustrating. Is this a bug, or is there a distinct trick to getting the file right? What format, exactly, is the TGA? 16, 24, or 32 bits? Is the alpha channel significant? Are you using GIMP, or Photoshop? Something's very wrong here Also, can I just use DDS? That would get rid of this problem, as I know exactly which types of DDS can be used by Spring correctly...

Also, while I'm getting ready to give up and get some sleep... I should mention that having a rgbcolor1 and rgbcolor2 as the starting and ending colors of the flamethrower would be very cool, for "gas guns" and "sound beams" and other kewl things that should expand... and not look like fire. I've tried out the size tags, and they're wonderful... if only it would obey gravity, so that it'd be a physically-accurate flamethrower, it'd be perfect. However, the tags GravityAffected and TrajectoryHeight don't work, which means I'm stuck with slightly less than perfect. And I can't define a texture1, let alone a tiling texture, so I can't quite make it look perfect from the art side, either. Ah well, one step at a time...

[Buggi]

Holy conversations with yourself batman!


You seem very technically able, why can't you join the development? :D

[Argh]

It's not a conversation with myself when it gets read over 80 times

And ... um... I'm not a developer, I'm a game designer. These are pretty distinctly different roles, really.

Spring has the potential to be a good game engine for game designers to use. It's a good set of tools. I'm not here because of nostalgic attachment to OTA, which was a good game in 1997... and, er... not so sexy-looking now.

Good tools are why I'm here, and not, say, working with the HL2 engine, which is very painful to work with, or eagerly sitting on the SupCom forums, hoping that the SupCom game engine will fit my needs. SupCom is closed-source, which has zero appeal to me at this point, having gone through a lot of pain and suffering with the last game engine I worked with (Freelancer, in case you've never visited my website)

Spring is Open Source, and being actively developed... therefore, it's suitable for my needs, and I am willing to live with the fact that my suggestions may not always be acted on, or get acted upon too late for it to matter to my development cycle. It's a tradeoff- if I had a budget of a million dollars, I'd want dictatorial control, but I don't, so I see my job here as one of gentle remonstration and persuasion. Which is OK with me, because I'm used to developing in mod communities anyhow, where acting like a dictator doesn't work really well

One of the game engine's biggest current problems is that SJ was halfway between worlds, and was acting partly as a game designer, making fundamental choices about the operation of Spring based on his expectations as to how he wanted gameplay to work. This is how most game developers who're making their own game do things, so it's not surprising, but it's made further progress towards a more flexible game-development environment difficult. The current moves away from that are very exciting, and as things have matured, I've naturally been paying more attention to the engineering-level things that are going on- after all, I want content ready for the engine when the next version is released, able to take full advantage of any new methods that are available. NanoBlobs is a good project for all of this, because I'm not committed to any particular game design limitations other than a few things that are unlikely to change, so I can use it as a sandbox. When Project Two is in full development, however, I'm going to be a lot more limited... so I'm holding off on it until I either get the features I really need, or am convinced they won't be available, and am resigned to adjusting the game design accordingly. I don't have a "omg, it needs to be done by Christmas" issue with Project Two- I'm not making any money, just like everybody else here, remember? So I can afford to wait and see.

I create content. I create game designs, using the tools that developers make available. At least, when the game engine isn't driving me crazy

My objective here is pretty simple: to point out where the current planned features aren't working, or aren't totally ... intuitive. For example, why am I having so much trouble making a new, custom graphics for projectiles? I'm not stupid, and I know a lot about making graphics.

I opened up the TGAs in the Base folder, looked at 'em in Photoshop, studied the existing files (64/64 TGAs for the beams, grayscale values, but still 16-bit RGB, with pure white alpha channels) and made the one that's shown above, then after doing some reading, figured out what file I needed to include in my mod, where the graphic file needs to be, etc., and then proceeded to test.

It doesn't work... therefore, something's still borked. What? I dunno. It really should be as easy as just making a TGA file, with an alpha, but obviously, it ain't. This is the kind of thing that will drive us crazy when we're trying to get deployments done, so I wrote it up.

I saw stuff about pathnames and other issues being fixed, so it may be that this got fixed in a commit just a few hours afterwards, but I'm looking at the build from 8/3. Smoth's compiling a new one, so I'll take a look at the current build and kind've go from there...

[AF]

Nanoblobz seems to expose more errors in spring than most other mods, which is good because they're slowly getting fixed. Tobi said in IRC not to recently he fixed 5 bugs that he found with nanoblobz.

A lot of these problems are ones I would fix myself but I dont have a clue how, hence why i havent gone into the s3o code etc and stuck to stuff I'm more comfortable with, such as nanospray and other little things and experiments.

[Argh]

NanoBlobs is a very good place to see bugs. It's clean, and simple, and you get to see hundreds of unit interactions per minute, instead of a few dozen, so when Something is Wrong, but it's subtle... you can actually see it, instead of writing it off as bad observation. After all, it was originally designed to show AI developers more unit interactions per second, so that certain types of weakness would be obvious... this is just a fringe benefit, really. It's just that I tend to stretch the capabilities of a game engine with whatever I do, and I'm all about finding floors and ceilings... my dream games are always so much better than what I can actually build with the resources I have available, I'm always trying to get just a wee bit more about've the engine...

[Buggi]

I notice how many bugs seem to get squeezed out into the open by your efforts and know that we all benefit from the finds.

Good to know we have someone working so hard at highly unique concepts! Nanoblobs, love the name...

[Dragon45]

Argh, its really cool you're doing this


Lord knows how many engines could have used insane guys like you ( ) to push what is possible to the limit, and to fix bugs...

[Yeha]

Textures used by weapons must be defined in resources.tdf under the [projectiletextures] section.

If you have a mytexture.tga in the bitmap directory; In resources.tdf, under [projectiletextures] section put the line
lightningtexture=mytexture.tga;

and in your lightningweapon tdf put the line
texture1=lightningtexture:


The default files are 32bit TGAs, but most fileformats should work.

[Argh]

Hmm... that's exactly what I did... I think. I'll try 32-bit TGA, and if that doesn't work, I'll use DDS DXT3, because my results with that have always been good... thanks Yeha :)

[Argh]

Nope, it didn't work, period. Here's my code, from my RESOURCES.TDF in the GAMEDATA directory:

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;
		}
	}
}

The LightningDefault.tga file, a 32-bit TGA, in the Bitmaps folder with a pure white alpha channel, never renders.

I think I may have found *part* of the problem. After messing around with the Dependencies and stuff, it appears that nothing in my Bitmaps folder is getting read by Spring

Moreover, if I decompress Bitmaps.sdz, it doesn't work. If I add the new TGA to that SDZ, put the new filename into the Resources file sitting in Spring's root, and recompress it, it doesn't work (but if named as a Dependency, then everything ELSE draws).

Soooo... as my final test, to prove this... I swapped out the largelaserfalloff.tga with my nifty file, and...



... so, it's a file-system problem, or whatever is supposedly gathering up new files into the TextureAtlas isn't working. I dunno which, but when I swap out that ONE instance of that ONE file, and this build clearly isn't obeying dependencies correctly (which makes it a wonder that it works right at all)... I'm thinking file system / path stuff. But why did this work at all, then? Are the paths for the defaults hardcoded? That seems inefficient, for anything but testing purposes- I may want to make a mod where all default dependencies are torn out, after all (in fact, NanoBlobs is getting closer to that goal with each sub-release).

[SwiftSpear]

Wow, that looks pretty good. A bit more believable then the current lightning gun IMO anyways. Hopefully this research can help lead to some more abstraction in the weapon display system. Awesome work Argh.

[KDR_11k]

I figure this may be the right thread to ask: How does the laser projectile fadeout work? Some lasers fade out (get more and more transparent until they are gone), others dissolve from the point of firing. What determines which happens?

Hunch: The existing projectile fades out when another one is launched from the same piece (not in a burst). I hope that's not true, I wanted to make the orbital weapon lasers fade out but that thing's supposed to have a slooooooow reload...

[Tobi]

Argh, CLightingProjectile & CLightingCannon are a code generated lighting effect with 1 texture applied to it, which is by default the largelaserfalloff texture. Overriding it works fine here, set e.g. in the TRIROOK weapon texture1=lightningdefault; and in resources.tdf: lightningdefault=LightningDefault.tga. Then put some random LightningDefault.tga in the bitmaps folder (I just copied wake.tga) and voila:


If that still doesn't work then indeed something in that particular build or on Windows only must have been / be broken (I tested with latest SVN on Linux).

E: it also worked fine with ocean.jpg

[GrOuNd_ZeRo]

Any chance there will be a way to make customized muzzleflashes for independant units? or is that currently the plan?

[Argh]

@GroundZero: If you read through the documentation, it appears that's part of the plan, for the majority of the projectiles.

Even more exciting is the fact that we'll be able to name new Smoketrails and other ancillary effects, giving us a huge new range of things to play with

@Tobi: As for the Lightning... I'll take a look at the build of Spring that I got to play around with the custom icons, and see if it also obeys the custom explosiongenerator... the build released 8/4 still had lightning weapons using the old default explosiongenerator.

I think that the developer release and the SVN releases are differing widely at this point, and the release colorblind put out had OpenAL in it, which was very strange, since I would've thought OpenAL had been entirely removed from the MSVC project, since it's terribly buggy.

Basically, in the releases I've used thus far, they don't seem to understand what directory they're in. Maybe that's because I installed the development version to a different path... hmm, that's probably it... it doesn't understand relative paths to root...

[KDR_11k]

Apropos lightning (and flamers), do those weapons get deflected by shields now?

[KDR_11k]

I can't find it in the changelog: How did you disable nanospray?