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

svn, 0.5.1 and organizing.

Posted by safemode on May 16th, 2008

I just felt bored at work and decided that it would be good to give a heads up on what’s going on with things.

First, we have all the svn activity lately.  This is going to probably annoy everyone because of all the redownloading and annoy those who package VS even more.   We’re sorry.  This had to be done sometime, so we figured early on in the next dev cycle was better than later.   Basically, all the images in VS’s data repo are named based on their original extensions.  Over the years the datatypes changed, but the names remained, due to people not wanting to edit all the files that referenced that image and potentially break something, so out of laziness.   Then the switchover to DDS further compounded the problem becuase now, most image viewing apps would error because they didn’t have the dds viewing plugin and the user would see the filename as being a plain .png or .jpg and get all confused.   So we felt the need to standardize the naming extensions of the various images in VS based on usage.   No longer using the codec extensions frees us from ever having to do this again. 

Second, 0.5.1 is coming along nicely.   Code-wise, we have only a few (but important) changes left to get done.   Most of the work left to do for the release is data side.  Most of that is shader specific.  Best estimates right now put the release at a month from now.  This is a bit more trustworthy than the estimate for 0.5.0 that was about 6 months off target. 

 Thirdly, we’re working very hard at being more cohesive in direction and communication. Any users reading this, would be well informed to visit freenode’s irc network and join #vegastrike.  The plans we’re making and the directions we’re taking are being followed and taken seriously by all working on VS, and that will translate into faster and tighter releases as we approach 0.6.0.   Users who wish to have a more weighted effect on the roadmap should try and have more directed and explicit feature / bug fixes.   That is to say, rather than suggest something that has no hope of being worked on in any immediate release, try and think of things that bug you or could be tweaked that are neither vague or require rewriting huge parts of the game.   More pinpointed suggestions for pet peeves I think are better.   A list of things that bother users about how the game currently works would be neat too. 

 I guess that’s all i got to say about that.

IMPORTANT: Subversion repository changes

Posted by Patrick/ace123 on May 1st, 2008

This has been discussed for a while, but there are going to be some major SVN repository changes for all users.  As you know, we have released 0.5.0, yet our repository is still called “data4.x”!

A “4.x” is terribly confusing, so I have moved the repository from “data4.x” to “data”.  Oh great, you are probably thinking, now I have to wait for another Gigabyte of Vega Strike data to download.  Well it turns out that luckily for you, SVN will not require you to waste bandwidth if you follow certain steps that I’ll outline below, and document in more detail on the Wiki.

Also, we are making one other change as well that will help users of all platforms download the necessary files… we will make a “win32″ and a “mac” folder that you can download and have a working application.

See the Wiki for more information on how to convert an existing repository:

or, for information on how to download from SVN, see:

Enjoy the release

Posted by HellcatV on 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. 


Posted by klauss on April 25th, 2008

Not yet.

Soon, though.

I’ve been working on the past few week (maybe month?) on getting movies support (using the ffmpeg library to decode pretty much about any format you could think of). I’ve already commited video playback code, but video streams without sound are boring… right?

Lately I’ve been working on getting audio streams out of video files, and it’s been quite some work. For one, I didn’t want all that work to go to waste later, so I’ve been trying to code it in a useful, reusable way. I think I managed to write it in a way that could be reused in the eventual rewrite of the audio system. For two, I’ve been greatly tempted to start that rewrite right now - getting streaming using the current audio system in VS is… challenging. I’ll probably be hacking my way around VS’s aldrv API (the one that handles audio calls).

As much as I’d like to rewrite the entire audio system, the reality of things is that movies are required by many ASAP, so I will struggle hard to overcome the temptation ;-)

The code to handle various codecs, needed since we want ffmpeg to be a compile-time option, has just been finished. I’ll probably commit it as soon as it builds without issue, although it will not be linked to any part of VS.

Those curious to know how the upcoming audiosystem will look like are welcome to peek into that code (src/audio), to get an idea of, at least, the coding style involved.

Stay tuned - you may even get radio support on VS after all! (ffmpeg does support network streaming) *

* disclaimer: theoretically possible, but nowhere near available right now. However, the guys against it have one reason less to think so :-p

Graphics Developments

Posted by pyramid on April 16th, 2008

To slightly sweeten the remaining time while (impatiently) awaiting the 0.5 release, here’s a short update on the recent graphics developments.

Support for mipmapless DDS textures for space backgrounds has been enabled in the recent version (thanks go to safemode), which will reduce the memory footprint used by your graphics card and further speed up system loading. Two missing backgrounds have been also added to the data set.

More planet textures have been improved over the last month. Now all 74 exo-planet textures are of high quality (though I think I will go back to the gas planets and remake them after 0.5). The remaining 46 textures are from solar system planets and bodies. Here, the previously existing 2 different data sets have been joined inheriting the best textures and more than half of the solar system bodies have got additional improved textures. While all solar system planets have high quality textures (2048×1024 resolution ), I wanted to keep the remaining bodies as close to the reality as possible. However, freely licensed high quality maps for moons and other significant bodies are not readily available, so the approach was to reduce the release quality resolution requirements to 1024×512. Still 11 maps remain with lower quality (512x), probably until our solar system has been better researched and photographed. Nevertheless, the phase of improving planet textures is considered closed for now, and I will focus on other future tasks.

Finally, new and better planet rings are now available in the data set. They are of reasonable quality so that you may still enjoy them when flying close by. Further, 20 of the upgrade images have been provided with better quality pictures. And last, on your HUD you will notice that 3 indicators - the weapons capacitor charge, the FTL and JUMP drives energy, and the fuel status - have now a text overlay, so you don’t need to remember the meaning of each one.

You may wait for the new release or check out the SVN version to start enjoying the improvements already.
I hope that you will like those changes.

Graphics and Artwork

Posted by safemode on February 29th, 2008

 Courtesy of Pyramid: 

Those who have been playing Vega Strike (the game) version 0.4.3 surely remember those blurry planets seen all over the universe. While a lot of work has been and is being invested into the game engine, we will also see many visual improvements in the upcoming release. I would like to give you here a heads up and share of taste on the changes you will find in the next release, some of which were only introduced after the last beta.

For one, many planet types have new textures with better resolution and visual aspect. They will be more realistic and less blurry than the previous ones, trying to represent more or less realistically how extra terrestrial planets might look like.. Almost all of the previously missing textures, resulting in untextured white planets, will be included now. All in all, against the 8 out of 120 planet textures with release quality present in the previous version of VS, now all planets will have textures with 60 percent of them being of acceptable quality. Besides the planets themselves, each of the 27 planet types has now its own HUD image as well as the planet type being shown.

Another one of the changes that will be immediately visible, is the armor and shields status indicators for your own vessel on your cockpit. Four gradually semi-transparent arcs have replaced the simple curves used before as simplified status representations. Though some of the cockpits have been currently disabled due to their quality and believability being very limited, they still have their individual armor and shield gauge styles in the data set.

Many new cargo images that were missing were added to the game. Besides the fact that there are now 34 new images, they are also of relatively high quality as compared to those previously available.

Besides the very visible changes, there are other changes which are less obvious at the first glance. One of them is the default number of concurrent comm message lines on the HUD which has been increased from 2 to 5. In addition, the default time before scrolling the messages has been increased from 5 to 30 seconds, while the user or modder can still adjust both in the config file. Another, less apparent, feature is the ability to disable, via the config file, the cursor and the target arrow for two specific cameras, the external view and the target view making the cameras bare of any HUD elements and very well suited to take screen shots. In addition to that, the pan and yaw speeds of the cameras have been lowered and are now configurable, too.

The HUD has been given some additional status indicators. You can now see new stati for flight computer, autopilot activity, SPEC drive, governor control, total vessel mass, docking readiness, turret control, cloaking device, and electronic countermeasures.

Further, three new splash screen images have been added. The first one is an advertisement for the SMC, the Shmrn Medical Consortium. The other one is a call by the Botete Merchant Fleet for supplies shipment to a planet during Aeran blockade. And the last one is a Luddite virus hack screen.

Though not directly graphics or art related, I thought I should mention one more point here. In order to speed up game execution and optimize memory usage, all images and textures have been converted to dds format. Unfortunately, during this process incompatibility with some nVidia drivers on some card families has become more apparent, which, adding fortune to infortune, can be solved by using the latest nVidia driver release (169.12). We greatly appreciate any failure or success reports on our bug triage forum.

You might be on the right track if you are expecting more changes to be coming along. Some of the ideas for further (non-engine related) graphics and artwork development include but are not limited to:
* substitution of the remaining 40 percent of low quality planet textures
* complementing missing cargo, upgrades, and weapons UI images
* extending the variety of space backgrounds
* improving planetary rings
* making own vessel shields and armor be made up of 8 faces each
* providing visually improved shield status for targets
* throwing in a little surprise for enjoyment by VS gamers

To the hangar and off we spec!


if you notice weird stipled white bars across any graphics, please post your gl_version and gl_renderer lines from glxinfo or related app in the bug triage forum  http://vegastrike.sourceforge.net/forums/viewtopic.php?t=10588

new collider info

Posted by safemode on February 10th, 2008

As many of you know, our rapid collider is not 100% GPL compatible.  Thus, the mission of replacing it became a top priority for 0.5, and is one of the major reasons why it’s not released yet.

Well, after a lot of learning how our basic collider works (and still needing to learn more) I’ve got the basic opcode collider functioning somewhat in vegastrike.    That is to say, there is no raycollider yet.   Things are going to be slower than the rapid collider until we work out the general bugs, then we can start turning on optimizations and getting things streamlined.  At that point, we will probably remove the old collider from SVN.   And then after that get things using the raycollider.

In the coming couple of weeks, we’re gonna need people to test the svn head with –enable-opcode turned on in the ./configure script.  Backtraces of any segfaults are good, so are descriptions of performance (both speed and accuracy).    Compilation issues as well.   my hacks to opcode may mean that it doesn’t work on non-64 bit cpu’s or non-intel compatible ones…i dont know.  it’s gotta get tested on those archs.

The first person to leave such a report should do so in the bug triage forum under a topic to the effect of “opcode collider errata” or something.

When using vegastrike with –enable-opcode, dont be surprised if it segfaults or you can fly through things you shouldn’t.   We’re not really using opcode the way it should be right now (so we can mimic rapid collider’s api) so I may have done one or two stupid things in the process.   Hopefully now that it’s in a testable form, other devs can help me fix it up.

Thanks for testing.

Moving Along

Posted by safemode on January 4th, 2008

Beta 5.0 is out for the most part.  I say most part because of the obvious lack of linux binaries.  Many have complained about the lack of a linux binary and to that i have only one response I have for that besides the fact that I work in a different area, is that in linux, we have a much more efficient way of distribution than possible in Mac and Windows environments.  In Linux, distributions will package up the game as they require and link against their specific libraries and distribute from thier mirrors.  I can only assume we are waiting for that to occur and that those maintainers are waiting on a stable release from us so they dont spend all that time packaging up 200MB of data for nothing.  So, unless someone does build a linux beta, the only current solution is locally building the game.  A feat that takes about 20 minutes or less on most machines. 

 The good news is, that a stable release really isn’t that far off.   The holidays and real life have definitely put a road block on being able to give VS some much needed attention.  I know it has for me.  I think the main issue is realizing that we aren’t going to get everything in this release that we’d like.  We’re not going to get everything working 100% for all people in this release.   Thing’s aren’t going to be complete even though it’s a stable release.   We’re going to have to accept that even a stable release, has bug fixes released for it and it’s just the nature of software to require some polishing.   A stable release simply signifies a concrete api and functionality, not a lack of bugs.  We’re not calling this 1.0 for a reason, it’s not going to be complete, it’s not in the form that we’d all like it to be.   So I dont think people are expecting it to be full and complete at 0.5.  That being said, I have no doubt that it’s better than 0.4.3, and that is what really matters. 

So that brings us to what is actually still to be done.  I’m really happy to see the new layout of how development is done on the art side of things is going along nicely. I’m not sure if any name changes are still being debated for directories or what not, and I know we need to spell out how to go about interfacing with the Masters repository but that is all going well.  The artwork changes and thus the repository changes were a major change and we’re still making sure everything in-game is happy with it.  The shader support is another late addition that is fairly major, though it can be disabled and ignored by users that it doesn’t work for.   And as always, more unit work is and has to be done in the ways of data sets.   And definitely, not to forget networked play.

 I think we’re really stuck at that point where, as a developer, you want your work to reflect your level of skill and you want people to be awed and love it, and another point where people are losing interest because of a percieved lack of activity.   We need to basically shore up the api for the game (which has changed very little , most real show stoppers for mods lie withing the changing api of python), and turn off shading as a default (unless it’s complete enough for the guys behind it) and just put out the stable branch.  It’s ready now, it needs a little polishing, but it’ll be more beneficial to the game to do that polishing along a stable branch than to continue in this beta phase that is too unstable ( in the changeable sense) for most people to stomach.  

Lets get the mods up to date (the ones that are still alive) and get 0.5 out there and put our effort towards 0.5.1 as far as more shader additions, more units/new artwork, and fixes to the data set.  Sure, some people will point out the defects and that’s great.  We will only benefit from both the good and bad but nobody’s talking about our beta releases.  We have a lot of little work to do in 0.5 and that should keep us busy for a while before we start looking towards 0.6. 

 I havn’t touched on the networked side because I think that can be worked on during 0.5 and it will probably dictate when a 0.6 development branch should be forked because I’m sure some aspect of it will require a major change somewhere along the line.   But for now, it wont effect the main game.

 So that’s my little plea with everyone working on VS to really decide what is absolutely neccesary for a stable release and what we can push off for subsequent patching.  I think the main holdup is simply time and we all have so very little of it this time of year. 

 Since I’m at work right now, I figured it would be a good time to talk about the data set, something I haven’t been really involved in since I dont know python and the I prefer to work on backend stuff.  We all have ideas that involve huge changes, both in the backend and in the front that is innapropriate for 0.5.x, so I’ll limit to stuff that is.   What is appropriate, is Unit specification changes, weapon and such availability, economic values and most importantly, missions.  Well defined campaigns and missions.  Picking up python is going to be aggrivating, since it’s whitespace sensitive, but it shouldn’t be too hard and there’s a lot to build off of.  But I hope to do at least a little work in this much starved area.  I hope to create “missions” not for the player, since he can do what he wants, but for the AI.  I want to create generic missions that go into effect for the AI when certain criteria are met or situations accur, so that rather than have to worry about inter-AI communication and juggling units, the game can give all the AI units of a given faction in an area, the same “mission” which it will then play through as a real player would have to.  Only, these “missions” would compel the AI to work towards the goal, and since all the AI units loaded up with the mission would have the same goals, they would be appearing to work together.  Without ant real reworking of the way the game functions.  These “missions” would vary greatly for various situations, and have mirrors per factions with alterations to play to that faction’s characteristics.  The idea of the fixer for the AI would be replaced by some changes to how the default mission file functions.  Every N seconds, it can scan the entire unit list, sort it and depending on the results of the sort, it forces a “mission” onto the appropriate units.  This “mission” will basically be a set of goals just as a regular mission would be, but the computer AI would be forced to try and complete them.  That may require some minor changes to some backend AI work.  Either the mini-mission will change or the unit will complete it and do what it normally does now.    I think this will alter gameplay greatly, but it still falls within a stable change, because it shouldn’t alter mods or savegames and in-fact, can be a “campaign” option rather than the default privateer/explore one.   This is my idea of how 0.5.0 AI should be and I’m hoping to get some work done towards that soon.   I think it will give the user a perception of factions that doesn’t exist right now, a perception that factions work as a group and have characteristics that make diplomacy and actions effect each differently.   It’ll make gameplay much more immersive due to you now having to deal with factions actually directed towards things meant to change the play of the game.   Watching the news will suddenly be necessary.   I am really excited about the prospect of this and what it can open up.  

 for example.   A new universe is created and you’re privateering around making money transporting cargo and patrolling.  The game would probably see a pretty dispersed unit list.  The first thing it can do is give all the factions their basic mission ( a mission made dependent on their characteristics).  Remember, each unit gets the mission just as the user would get one from the computer.  Pirates first goal could be to attack a small ship that is not a pirate.   The next goal could be to goto their base. Then back out to attack a ship.  Repeat.  Then say the game finds a large number of large cargo type ships in a system with pirates.  The game then loads a “coordinated” mission to all the pirate ships.  This causes the pirate ships to return to base and then target the nearst large cargo ship.  All the pirate ships in the system would then targe the same ship and attack.   Giving the appearance of a coordinated attack.   After the attack they would return to base and repeat, until loaded with a new mission or all the cargo ships are destroyed.   

 In a similar manner, aera ships could take over and Hold systems.   And equally, if factions are friendly enough the computer could load similar missions on both factions to cause them to work together against a common enemy.   Imagine the epic battle that would take place if all the factions were enemies of the aera and they entered a system in force.  The game would load up an “AttackAera” mission into all non aera units.   Units may be recruited from neighboring systems.  Alliances would then become important to monitor..   Your own vessel may become the target of all the units in a system if you’re enemies with the wrong people.  

 I really think something like this is doable within the confines of a stable release, while simultaneously providing a level of AI that has been extremely hard to implement.  So basically we would have this as the game layer.

 Core:  Game super structure.  Controls scheduling and non-mission things. 
             Missionizer:   Runs every N seconds instead of the schedular for a cycle.  It reads unit list and if various situations that match various criteria exist, it loads affected units with the appropriate mission. 
                                      Missions:   Every faction gets a mirror set of missions for various situations. 

              Campaigns/Missions:   This is the user directed missions that are possible.   Work should be done to interoperate with the missionizer so that they dont conflict, with the user campaigns/missions taking precedence in most situations.

Missionizer should be fairly fast, so it wont impact gameplay.   The key to that is to keep the criteria simple and small.   It isn’t cycled per unit, but per faction so it’ll cycle through it’s criteria for each faction (each faction has different criteria) and they are listed in order of importance.  The fist to match is the mission that gets loaded to all of that faction affected. 

 Anyway that’s enough for now.  I really just wanted to voice about how it’s ok to release now, and fix the details later.  The rest about the missionizer will be in a forum post where it belongs.   I hope to get working on it asap.   Since it will be a different Mission than the default game one, it shouldn’t destabalize normal gameplay at all (since it wont exist in the default misson file).   just gotta learn some python.  

Help us help you: test 0.5.0!

Posted by HellcatV on October 2nd, 2007

So we’ve finally delivered our half of the bargain of making 0.5.0 beta available to you. It’s time for you as a community to help us test and find bugs. It’s been years since a full blown Vega Strike release, so doubtless there will be a few fixes before this is ready for primetime, but we hope that this beta will be at least as enjoyable for you as it has been for us to produce.

To gauge how many people are actually testing, we’ve thrown in a feature that looks a bit like a easter egg/bug having to do with one of the new station designs. Go and explore the wild blue yonder. Buy a jump drive and visit uncharted regions trade and dock.

When someone reports what we’re thinking of, I suspect we’ll be ready for primetime and our universe will have gotten enough coverage for testers!

Leave any comments you may have at the forums
and go ahead and use our bug tracker system for actual bugs.

Good luck!

I smell a beta approaching (for all os’s)

Posted by safemode on September 11th, 2007

I’ve tracked the rather annoying white planet/texture dds issue down to a config variable.  Now it’s just a matter of figuring out if the config var is valid anymore or if the code needs to be fixed to work with it.   Aside from that, a lot of work has been done to clean up the artwork and get everything that should be compressed, compressed.  But I think the extra few weeks of development has finally started to come to fruition.  

 There are a couple things being discussed on the forums that should be brought up though.  None of these are written in stone yet.

1.  The data directory will soon undergo a name change to data5.x to mark the new version. 

2.  Since the majority of textures will be in a lossy DXT format in that directory, we need a master repository for the lossless(hopefully) original images. 

3. Development of data5.x is likely going to occur in data5.x-test, so that at any given time, we may package data5.x and make a release, knowing that the code in it and images are stable and functioning… since all testing of new modifications have to first pass through data5.x-test.

 4.  Image types for the in-game art masters are going to be standardized, so we dont have a hodgepodge of formats being used. 

I think these are going to be very important given the extensive use of dds files for in-game textures and ramped up development pace. 

But, with the white texture issue nearly resolved (i have a fix just not sure yet if it’s correct) a beta release is definitely not far off.