I’m currently spending my non-VS time (read: day-job) working towards the ASPLOS conference deadline. This deadline, at just under 2 weeks from now, is fast approaching, and will degrade the amount of time I have available to work on VS until it has passed. This should not affect the August nature of a VS release, although it may make the “early” attribution initially suggested in the news post somewhat less likely, as I still need to spend more time massaging the data set.

Well, it took a long time and i really still have to go back over why it needs to be written the way it does (since i originally discarded it as redundent) but the “bases orbiting you bug” is gone. Thanks to patrick for pointing out an obvious oversight.

Right now there are a ton of extra checks in unitcollection and unititerator. Nothing is inlined that should be. Things are being played pretty safe right now from all the debugging since it’s being committed. Now that it seems that all it’s major issues are resolved, I’m going to start tearing off unecessary checks and allowing certain specific functions to be inlined (despite my hating non-const functions being in headers). This should speed up the class greatly. I’d like to get it at least as fast if not faster overall than the previous implementation before release next month. Barring any additional bugs of course.

The issue of debug code not being compatible with this implementation I believe is a far distance into secondary consideration when it comes to what should be ready for release. Debug builds are a developer tool, so it’s functionality for release isn’t really required. Obviously the performance of the container class for all the units is important, and so sometime after our main goals are met for the release deadline we should work on getting that debug code up to date so we can regression test the collection directly and gauge performance and all that.

We still have some pretty annoying and serious bugs and the due date is fast approaching.   I’ve been trying to figure out various implementations of UnitIterator that would help solve a lot of the problems that have come up more elegantly.  Unfortunately this has taken a lot of time to re-write a lot of code and in the end, they all were crap compared to the current way things are done.    On the upside, I did get exposed to probably 90% of the code-base doing it.  And i was able to remove all but 6 warnings from the build process.  Those will be committed tomorrow sometime, or at latest, this weekend.

The big issue people are angry at me about is the “stuck on you” bug.   It’s really hard to say if it’s a bug in my implementation or a bug in the game that had been previously “worked around”.   In any case, this is my main objective to figure out before mid-august.   I am almost positive it has something to do with pythonUnitIter but it could also be some issue with the intended behavior of removing UnitIterator positions that other UnitIterator’s reference throughout the game.    Currentlny I go around those classes’ backs and change the iterator directly, before, a second list was kept that would hold these “removed” iterator’s until the classes that held them, decided to no longer use them.

In any case, i’ll have something done before release.

I’m a bit on the busy side, so forgive me for being excessively terse.

Jump/SPEC tweaks — Jumping while in SPEC no longer allowed. Shields should also drop on jump — haven’t implemented that yet. In general I’m going to attempt to (where reasonable, given timeframes) limit the interactions possible while in SPEC. I’ll need to test some ideas out against the tail mission in the example campaign, to make sure that doesn’t break.

HUD tweaks — All 8 armor faces now have their own graphical representation on the HUD.  Need to get around to adding new display for velocity reference object, and then add it to all the cockpit files. Likewise need to add long overdue change to velocity gauge to only display the velocity relative to the reference object (the V relative to the system just isn’t useful when using the set/unset velocity reference functions).

Basecomputer — Upgrades now have more colors… it’s still not quite what I wanted, with a clear correspondence between reason for non-purchasable status and color, because the categories that can be discerned are a bit broad, but it’s an improvement over what it was. I’ll make another pass and see if I can hijack the existing “can’t-buy” flag preprocessing behavior to a more useful end.  Changed the prohibited upgrades functionality to work on category tree roots rather than leaf nodes only (can prohibit/quantity-limit at arbitrary depth in tree) and then coupled that with adding explicit quantity limits for the categories with multiple items in units.csv. Will need to sit down soon and bite the bullet on trying to debug why certain upgrades appear damaged immediately upon purchase… my deep suspicion is that the PercentOperational function is flawed, perhaps inherently so - it has previously displayed some very odd behaviors that have required kludge workarounds.

I’ve been spending the past few days clearing out the blacklog of artwork in the production pipeline. I am now happy to report that I’ve added seven new models from Oblivion and Fendorin to the subversion repository with a few more still to come.

I’ll let the artwork speak for itself.

First of all, this is my first post to the dev blog… I’ll hope to post more when I make progress on networking.

I would be surprised if the majority of Vega Strike players have not run into some sound-related problem while playing at some point… whether it be that the music and sound will not play at the same time … or that the game crashes because the firewall blocks vegastrike from connecting to ther soundserver… or that you look into “top” or the task manager, and see ten stray soundserver’s eating up CPU in the background.

Whatever the problem may have been, I can say for certain that most of the troubles related to the soundserver program have been eliminated. Vega Strike now uses OpenAL directly for all sound and music, rather than SDL_mixer. This is not because SDL_mixer was a bad library, since it supported more sound formats than any other music player on my system (except maybe mplayer). Rather, the internal disagreements that SDL_mixer and OpenAL had with each other, was what forced soundserver to be created in the first place. If we were going to try solving the fundamental problems created by having two separate programs talk to each other and the sound card at the same time, one of them would have to go.

Actually, the first idea that came up was to use OpenAL’s seemingly convenient (and too good to be true) “SDL” mode, which would make it talk to SDL directly. However, it had two major problems: first, it was not enabled by default, so anyone playing would have to compile OpenAL themselves to solve sound problems, and second, that OpenAL uses the SDL_Audio module, and not the SDL_mixer, which means that it would not mix with the music.

Anyway, it turns out, since we already have OGG support for the sound effects, that it was incredibly easy to get music to play just like a sound effect.

So, that was the easy part… there are a few smaller and less important issues that haven’t been solved yet, such as cross fading and loading in the background. Both of those are easy to solve. Loading in the background can be solved using threads, which seems complicated, but really does not involve much inter-process communication…just one mutex and a data structure.

Anyway, the smaller issues are unsolved (For example, volume isn’t exactly right because music is controlled along with sound, and fading does not work, and a few others). But they are all solvable, now exist, but the big issue, the soundserver, is solved now.

As of version 11045, this is in SVN, and should mostly work… Win32 might still have some bugs because it uses different threads.

-Patrick

In the safemode branch Unit is going to be going through some evolutionary changes.  I’m creating base classes to Unit that Unit inherits and compartmentalizing functionality to those classes and removing them from Unit. The object of this is to allow numerous source files across the tree to only have to include the lower level base Unit header and deal with those pointers rather than have to include unit_generic.h and thus the entire build tree.   This should result in lower compile times, lower compile fs footprint, and it should make it much more easy to deal with working on Unit and it’s sub-classes.  Eventually these layers may be used to create a server only “Unit” that doesn’t include the code for graphics etc etc, that it doesn’t need.   For now though, I’m just creating a layer or two directly under Unit in order to allow more and more source files avoid including unit_generic.h.

The great thing about this is that it’s minimally invasive.   The game should work without alteration and I can continue to change over source files to use the lower level classes without breaking the game.  There would be no need to change _everything_ before it works.  This means this type of improvement can find it’s way into the next release perhaps.

Now, some people might think that this means we’re going to have a runtime performance hit.   Let me assure you, it wont.  We already have to use inheritance  during gameplay because GameUnit inherits Unit while being templated.   Additional subclasses under Unit wont make a difference.  A class that inherits a class takes the same perf hit as a class that inherits a class that inherits a class etc.

There really is only one thing about doing it this way.   Sure, i can compartmentalize a lot of code from Unit via creating subclasses under it, but that may not be the best way to do things.   It’s just the least invasive way to improve things.  I think we should really get together and brain storm what we want to change about Unit for down the road.   Perhaps branch off the HEAD  and do the Unit changes there.   I’d really like to see layers of functionality and a way to minimalize cpu/memory footprints of Unit.   Like a way to create a Unit that has no graphics/media/ etc… for parts of the game where that unit is not being rendered on screen, Then when it is it can be copy-constructed to a full Unit.  A way for things like missiles to be a Unit, but not include code for everything it doesn’t need or use.  Same with cargo and Units that can’t move or aren’t affected by physics etc etc.

Anyways, for now the method i described first is useful, non-invasive, and doesn’t require immediate widespread alterations.

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

Hey guys.

I’ve been away from this project a bit too long now. At least from the public’s POV.

For those that don’t know, there’s a reason or two: school… and school. And school too, perhaps. Thing is, I’ve been rushing towards the end of the career and, believe you me, that leaves you exhausted. I’m still a bit far from the end, but not that far. Hey, I’m already considering subjects for the thesis so…

Anyway. That left little time for the public face of this project, and so I’ve been behind the scenes, doing little things as I could. I’ve been helping John release the late and last release of Gemini Gold (baby steps at a time, but something’s something), and though I wish I could spend the time to push the Ogre port, that’s the kind of major task that I honestly don’t have time to. And that sucks.

But… as all things must come to an end, this term must just as well and soon I’ll have more time for the project indeed. And as soon as that happens there are two areas that need immediate attention: The oh-so-delayed Ogre port, which I’ll try to rush into service by redesigning the GUI framework that frankly didn’t go well (it became too complex), and the unit upgrade system which, let’s face it, became unmantainable already. There’s some people taking a look at that already, and so I may be helping someone rather than doing by myself.

Finally, and the whole point, don’t take my apparent inactivity as a sign of gonedom (ie - me leaving), but as a sign that I’m busy with invisible stuff. Also, don’t think this state as a permanent state, for it is not.

In lesser, more famous words: I’ll be back.

Klauss++

I’m the new guy I suppose, and as such, it’s my duty to destabilize some things and brake others and then spend too many hours fixing them.

Right now the main contribution that the safemode branch has brought to vegastrike is an std::list backend to UnitCollection and a total redesign of the UnitIterator UnitCollection classes. It’s important to note that the current incarnation of those classes are not the final incarnation that I envision. Right now there are still some lingering issues with how the rest of the program and the Python data files utilize the UnitCollection both via the regular UnitIterator’s and PythonUnitIter’s and PlanetIterators. A lack of testing by other people, however, has made detection of the wrong behaviors hard….as I dont spend much time playing the game compared to developing it. The safemode branch also brings a cleanup effort both in the form of code formatting and in the form of numerous minor bugfixes/optimizations. For right now that is it. The evolution of the UnitCollection class and UnitIterator class may make it slower at times than the older version, but that is only temporary, once all the code has been properly updated, and the UnitCollection class is in it’s final form, it should be much more streamlined and most if not all of the conditionals regarding correct values will be gone.

So, what’s the status?

Right now UnitCollection and UnitIterator and UnitConstIterator exist as the base classes. PlanetIterator and PythonUnitIter exist as derived classes of UnitIterator.

UnitCollection uses an std::list to hold it’s Units*’s.

UnitCollection’s methods still operate and attempt to completely mimic exactly how the old UnitCollection worked.

UnitCollection also uses an std::vector of UnitIterator*’s to maintain a registry of active iterator’s to it’s list. This allows it to make sure one iterator doesn’t invalidate the position of another iterator that may also be active. It does this currently by incrementing the iterators at the same position, and then erasing the position. Erasing is currently the only method that cares about this, since in std::list, erase is the only method that can invalidate positions. The registry is by no means a permanent thing, it’s only there because i needed a solution to the problem of invalidating positions held by other iterator’s. I may go with another solution later on when I think of one.

UnitIterator’s also work almost exactly like their previous incarnation. Backwards compatibility is only maintained in the PythonUnitIter class. The current() method has been removed in favor of the operator*(). Eventually UnitIterator will have only those methods that an std::iterator has. The UnitCollection class would have mostly only those methods than an std container class has.

Other than that work, I’m stil chugging along reformatting code to a more legible state. I’ve halted it for now because of all the issues i’ve been having with UnitCollection, but once that’s taken care of, I’ll be reformatting source left and right.

Future:

I make semi-regular merges to the svn head since _most_ of my changes are fix related or cosmetic. The purpose of the safemode branch is to clean up VS, simplify where possible and optimize via good programming practices. That means most of my work will result in no change to gameplay, so regular users wont notice much at all except hopefully, a lighter and more responsive game. A lot of the code fights against me *cough*unit_generic.cpp/.h*cough* . Code cleaning sounds non-invasive but cleaning can be very invasive, the std::list change began as a cleaning of the UnitCollection class. This invasiveness will hopefully dive deep enough to actually do something constructive to help vegastrike but not too deep that it becomes something not doable with our current resources.

For the most part, I really want to fix the Unit class. I think it’s entirely too much of a victim to feature creep and abandoned code. It’s way too large, non-compartmentalized, lacking any sort of api or layer system, and it combines templates and inheritance, making most of the benefits of using templates nullified. I feel very strongly about needing to clean it up and it’s at the top of my list once my current things are complete.

This is going to take time since i’m juggling it between 12 hours of work and real life.

So now you know why your latest pull of the SVN may be acting funny. It’s not bad, it’s progress.. Just dont flip out and throw a line either on the wiki or via the forum about the problem. We really need more testers willing to give feedback. Especially those that can run gdb or some alternative and give backtraces (if the game actually segfaults). Thanks.

Clocking out,

Ed Sweetman.