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 )
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

Revamped weapon set (first approximation of long planned overhaul).

Fixed broken feature relating to ammunition: for non-missile weapons, you now have to actually have a gun of the appropriate type before ammunition can be purchased.

Ammunition made extremely plentiful for testing purposes. Levels will be reduced tomorrow now that I remembered to make each ammo pack have multiple rounds :-/.

Keys changed in MPL/units.csv — new savegames reccommended for anyone pulling newest SVN.

Images of initial upgrades now appear properly.

Added workaround for bug where purchase of additional sensors would make the previous upgrade appear broken. Root cause likely remains, but should probably be ignored. Entire upgrade system will need to be reimplemented after next release anyway.

Began cleanup of ship variants available for sale. Separated noextension (equipped military) and .milspec (for sale, from military). Likewise separated .blank (explicitly referenced by game engine, assumed to be BLANK SLATE) and .stock (most basic ship variant for sale). This should eventually both ameliorate some of the problems historically caused when using milspecs and allow greater flexibility in the variants available (making .blanks immediately flyable at purchase has unfortunate consequences for all other variants. No longer having this restriction (leaving that task to the .stock variants) frees one to make more interesting variants.)

Noted that some upgrades are reported as upgrading columns for which they have no entries. Initial investigation showed the generated upgrade unit having non-default values for the reported fields. I will look into this further tomorrow.

Upgrade re-sizing and sanity checking of prices still pending. Will switch over to said tasks if above mentioned bughunt does not seem promising.