About Gallery SF.net Project Bug tracker Downloads Forums Manual Wiki DevBlog News

Data Set Ruminations

Spent a bit of time primarily working on the data set itself, although there were a couple of negligible code changes I commited tonight.

Ammo levels are somewhat more sane now. I’ve split the ammunition category into some subcategories so that there can be some factional/basetype differentiation on quantity, pricing, and just plain old availabilty. I’ll be doing the same thing with some other categories too tomorrow, and likely introducing some more species-specific variants of some types of upgrades.

While testing, I realized that all of the Sartre variants were missing the damage map they referenced, so I dirtied up copies of the texture and named them appropriately. It’ll do for the moment, but I’m no Picasso, so someone will probably want to replace those at some point. Likewise in the missing category - there were some missing unit warnings among the newly defined weapon upgrades caused by some mismatched keys, so I tracked those down and fixed them. This would perhaps have been easier to find if there weren’t a slew of warnings concerning nonexistent .template files (which the VS data set doesn’t use), so I put in a check before the warning is printed to check a new config variable for whether .templates are being used. The deluge of (harmless) “missing” factional variant texture messages is far worse, but it looked like it would be a bit more invasive to make those statements conditional, as it is non-trivial to determine whether you really are missing a file, or there just is no factional variant art for that vessel (the latter being much more common) — and the level at which the statement is being printed doesn’t match the level at which such knowledge would be more readily available. So, I’ll let that be for the moment, but we _really_ need to clean up our stderr sometime soon.

Back in the land of dataset hackery, I went and changed the required volumes of some of the key upgrades. The reactors were the most heavily affected, and this because the reactor is in many ways the place with the most leverage: if you can’t fit a larger reactor, and have to take a smaller one, you may still have room for a more advanced shield module, but you probably won’t be able to sustain its recharge rate, etc. This is just a first go over, so I’m sure I’ll change it again, but we’ll see how the new sizes play out. Pricing for the basic vessels, ammo, and weaponry was also modified. I’m less confident about the absolute range those numbers have wandered into, but the relative is probably a bit better now than it was before.

There were some changes to keys and relevant categories that had to be mirrored in the python code. I don’t know that I’ve found them all yet, but I think the primary places of reference are fine (I may have missed some of the less used python modules — gives me something to do tomorrow while I’m not BBQing.)

Moved the player start position to a few hundred Km from starting planet rather than a few 100,000 Km. This causes an immediate redock on initially leaving the planet, but no further hassle. I have a pretty good idea what’s causing the re-dock, but I’m not sure how to fix it yet, so I’ll sleep on it.

Other assorted fiddlings/minor bug fixes:

Fixed AI turret key binding typo in vegastrike.config (config file change) (it’s amazing what one can find if one actually reads stdout.txt :-P )
Changing warp-stretch settings, attempting to only have length distortion at relativistic and greater (FTL) effective velocities (config file changes)
Expanded size of stars (and indirectly, planets) and increased spacing of objects therein (config file changes)
Fixed typo in reference to config variable in galaxy_gen.cpp relating to above

In any event, it’s naptime here -

-jackS

5 Responses to “Data Set Ruminations”

  1. safemode Says:

    I had a patch early on that would just render stdout and stderr via the vs_fprintf method a conditional based at compile time (could be adapted to runtime). Basically, I wanted to completely remove all non vs_fprintf statements and make them into either cout/cerr statements or remove them completely. Then I wrapped vs_fprintf in a macro so that it would be an empty function if the user compiled without verbose/debug flags.

    I’d really like to see all printf/fprintf statements gone from VS. It’s an unecessary buffer sync and IO wait for the game. At the very least we could use cout/cerr and not have to sync buffers with stdio but it looks like a lot of output is from old internal debugging that’s just been forgotten.

  2. klauss Says:

    Just a note: if you want to avoid buffer sync, don’t use

  3. klauss Says:

  4. klauss Says:

    … endl.
    endl is an affector which is just a shortcut for — “\n” — flush, and flush is another affector which… you know… syncs buffers (replacing - by less signs which the blog seems to choke on, proof found in those two failed comments above).
    If performance is your goal, you don’t want cout/cerr: printf is about a hundred times faster. But if debugging output is what you’re producing, you probably (shouldn’t) care about performance - debug output should be disabled for release builds. So, I imagine you should delete what isn’t an error/warning (whatever is debugging/tracing output of the kind “hey… i’m doing this now” should be simply deleted, I think), and leave what could mean potential trouble with a flushing method - ie: cout/cerr with

  5. safemode Says:

    http://www.codeguru.com/forum/showthread.php?t=383112

    the speed of printf vs cout/cerr is compiler dependent. The buffer sync i was talking about was C++ iostreams having to sync to stdio (this occurs when you mix stdio with iostream). Whatever is decided, we should stick to one or the other.

Leave a Reply

You must be logged in to post a comment.