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

Archive for the ‘Bug Hunting’ Category

Enjoy the release

Saturday, April 26th, 2008

Hi Folks! I just wanted to let everyone know how excited I am that we got this release out the door! First of all it should be fun to have a system that should work on all modern platforms with installers for 5 major platforms (Windows, Linux-32, Linux-64, Mac Intel, Mac PPC).  

Since pyramid just made a post about the artwork, I’d like to talk some about the code. This release should finally provide some polish to the new warp system, some interesting and improved gameplay and very scenic systems that are now populated with hundreds or even thousands of ships each.  To do this we needed to completely revamp the physics system with jacks idea of asynchronous physics simulation atoms.  We also needed to optimize the heck out of the game. Thanks to Safemode’s DDS code, we can load compressed textures directly onto the GPUs without decoding them from png first. And our talented artists just keep on contributing, from beautiful models to high resolution planets! What really needs doing now is for the artists to come together and start generating normal maps for our ships so they appear to have higher detail geometry. Take a look at the starting ship, the llama in game and notice the high resolution bump maps!

And most importantly of all, with Safemode’s contributions to the collision library we are legally allowed to distribute this game again after a brief period where it was discovered that the Crystal Space collision system was using GPL-incompatible code!  So we’re 100% free software again: congrats Vega Strike.   

This occasion also marks the 10 year anniversary of Vega Strike.  If you go back to the archives and find the first blog posts, you can see the first public release was in april of 1998.  With any luck, since this is 0.5.0, that means we’ll have 1.0.0 (the space sim to end all other spacesims) out in 2018 ;-)   

Speaking of game changing features, 0.5.0 marks a very nice place since it allows us to become more experimental in the subversion head.  This means more development focus on multiplayer, which we will allow users to test in spurts (right now public access to the MMO version is blocked…but that’s simply because the server has a few bugs that we didn’t want to delay the release for).  But multiplayer is coming–all of the feature-driven code is there and it’s mostly just bugfixing from here on out!  This means in the next few releases we should start to see more heavy multiplayer integration–and in this release you can setup your own deathmatch servers with the provided vegaserver executable! 

So as you can see the state of the Vega is strong. 

0.5.0 Looks a little closer!

Tuesday, August 14th, 2007

After SIGGRAPH in San Diego this year, I probably spent 2 of my most productive Vega Strike hacking days in a long time with jacks.

We started simple, fixing bugs like the idling star streaks and the presence of spec interdictors on the bases, but then we got ambitious. Radar has gotten a long overdue overhaul so now a unit appears in at most one radar rather than both front and back, which makes it much easier to tell where the different starships are.  The problem where mission craft appear right in front of your nose is now gone, because we forced a minimum spawning distance. We made sure units would not cluster around the sun in generated systems and we improved the planet layouts in those systems so that the spec wells are not too harsh.

Our most noticable change has been the massive python mission reorganization causing all missions to look to a central area for naming conventions. Now missions should be much easier to complete since they will give both a flightgroup and a number in addition to the ship class for the ship needed to meet. Additionally they will enable you to cycle through friendly mission craft with a new key to make it easier to find far-off targets.

As icing on the cake we completely revisited the ASAP autopilot system. Instead of turning you onto a collision course to the object, the new system plots a nearly optimal path through the spec gravity wells to minimize your travel time to a far off target. Until your spec value is at least 100, you will be launch perpendicular to your origin planet, then you will slowly orbit around that planet until the object is straight ahead….at which point you will zip directly to your destination. When you reach the destination, autopilot will release control and put you at your cruising velocity–meaning you can set your velocity to 0, grab a quick snack…and when you’re back, you will be there— if of course– the pirates haven’t gotten to you first. Hopefully this improves the enjoyability of cruising around space. We’re still considering potentially allowing you to change targets while in ASAP but have it continue to its original course, instead of allowing you to redirect midstream. User input is certainly welcome!

Anyhow I have a feeling the 0.5.0 release is closer than ever before–and if we get time, we may have a few more surprises up our sleeve for that gem….

Working down the laundry list

Thursday, July 12th, 2007

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.

Breaking the silence

Monday, July 9th, 2007

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.


Weekend update

Sunday, July 1st, 2007

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.