Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.
Is there anything else it can be used for? Are there any other subsections than [Los]? i.e. Are there sections for radar, sonar etc?
Thinking of writing a patch to shove it all in modrules, seen as the incredibly pointless particles.tdf can already be done away with in favour of an entry in modrules. (Part of my evil plan to do away with Tedious Data Format altogether)
Last edited by FLOZi on 20 May 2008, 20:44, edited 2 times in total.
No, there's nothing else that goes there. I think it was intended to allow more parameters for radar resolution vs. LOS resolution, etc., etc., but nothing got done. I went into this in some detail awhile ago, and basically arrived at the conclusion that game designers should raise the mip levels to their maximum values, for the best performance possible, as my tests showed little practical difference between lower and higher levels on typical maps, due to the fact that the collision-test for weapons is independent of LOS per se.
Meh, if you're going to go poking around in that... I would still like this area to get fixed up a bit. I'd really like an option to make radar able to ignore the LOS map entirely, for example, and get rid of LOS map checks on Units if wanted (it'd save a lot of processor cycles, and in a few cases, such as high-flying aircraft, it wouldn't create a lot of obvious discontinuity of the user experience if mixed with traditional LOS). And I'd really like to see CEGs that obey ground LOS, not the AirLOS (that is the only use of AirLOS that I know of in Spring) because it results in silly behavior where you can see CEGs being generated by Units you cannot see yet.
I tend to agree. Now, I'm tempted to do away with SensorHandler altogether and read from modInfo when needed; does any dev see a flaw with that?
Also, how important do modders think backwards compatability is for this? It seems to me in SVN particles.tdf is now completely disregarded, I'd like to do the same with Sensors.tdf in all honesty - most mods will use the defaults, and its not a large effort to change them.
I use non-standard sensors.tdf settings, so I'd like to know what to change in modRules, if this is how it's going to be read by Spring.
I'm not in favor of dropping Particles.tdf entirely- global settings may be appropriate in some instances, and it'd be silly to make that only possible via a Lua workaround, imo. IIRC (I'll check) NanoBlobs does it this way, since no Units use a nanoframe, etc.
Just put it into modRules, like sensors, and it'll still be around for people to use if needbe.
Particles.tdf was already made redundant (presumably by trepan), and don't get confused; all particles.tdf did was allow_nano_team_colours, by including the functionality into modrules. It was partly the inspiration for the change in Sensors.
If you are still using a modrules.tdf, simply copy paste the contents of sensors.tdf into it. If you are using modrules.lua, you should know what to do anyway.
I already committed it btw, so feel free to play around.
It also seems that subections within the [projectiletextures] and [groundfx] sections are allowed. This seems a little strange to me - does anyone actually utilise this?
edit: Also of note is that when trepan added support for resources_map.tdf (which allows map specified atlas textures for gaia unit projectiles) that does not read from subsections within [projectiletextures].
Anyway - I kept backwards compatibility with the subsections at the request of jK.
Resources.tdf is dead, long live resources.lua!
Next up is sidedata. How do modders feel about losing canbuild/buildoptions from sidedata.lua? It's currently kept available in sidedata.tdf by parsing it seperately. Obviously the idea is that buildoptions belong in the lua unitdefs.
The build options have already been moved out of sidedata.tdf.
It's only used for the commander names now (note that the
parse_fbi.lua script does use sidedata.tdf to load build options for
backwards compatibility, but that native lua unitDefs do not benefit
from parse_fbi.lua's use of sidedata.tdf (nor should they)).
Ah well. I just did a straight port over like everythign else. I did do some other cleanups though;
Start scripts no longer default to OTA commanders if the parser fails to find one from sidedata. This means no more 'cannot load unittype armcom' when you have no intention or mention of it anyway. Instead, the start script will throw a content error specifying for which side it failed to load the commander for.
Also, scripts with a default of two sides (i.e. all of them except Commander Script when using a lobby-supplied script.txt), the second side now defaults to the first, so mods are no longer required to have two sides to run directly from Spring.exe.
One less OTA-ism, hurrah! Speaking of which, I'm wondering what to do about the Air Combat Test script, which uses hardcoded OTA unit names. For now I'm leaving it alone, but I'd prefer to either ditch it all together, or make it pick air units from the loaded mod, if it has them. Does anyone have any particular reasons to keep it?
Well, I use the Air Combat script to test my graphical settings - sort of a poor man's benchmark. But I'm sure there is a better test script that involves units and projectiles that somebody could point out.
You broke backwards compatibility, for games that aren't calling anything from Base. It's not reading my Resources.tdf file properly, and complains that it can't find "explofade.tga", etc., which is not the reference I'm using in the TDF.
My TDF, which refers all of the defaults to a "null_texture.tga" file, should take precedence. It obviously doesn't.
Lemme mess with fixing it, and see what I need to do, to prevent this retarded behavior from happening. I don't want my TextureAtlas space wasted on a bunch of files I never use, however.
Ok, I know what's wrong. It doesn't handle long comments correctly- i.e., "////////////////////////////" causes an error in the loop. Then it returns a value of nil, and Spring crashes, while asking for a phantom file name.
Easy enough to address, but I'm going to have to fix NanoBlobs as well, and other mods may have been broken by this. I think the parser needs to see "//" and disregard that entire line, including all subsequent "/" characters.
