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.  

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’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.

I hate Steve Jobs.

Actually I don’t hate Steve himself… I just hate his crowning achievement: the Apple Macintosh Computer. Making every single Vega Strike release available on this piece of s^Hhardware is like taking a fully loaded .44 aiming at your feet, and pulling the trigger repeatedly. The plus side for you Apple fans is that I need you folks to test my hard work–and see if the version works on your system. So we have a prerelease intel-only (the PPC one has no known issues right now) Macintosh beta at http://vegastrike.stanford.edu/VegaStrike0.5.0beta0.dmg

This time the 14 hour problem wasn’t linking, or porting to intel mac, or working around the really broken version of GLSL that does not allow one to mix fixed functionality with shaders without getting missing polys or abysmal perforamance, or the disasters of keeping backwards compatability to OS X 10.1 —this time the problem was a sneaky race condition in Apple’s own implementation of OpenAL. In fact they covered it up with all sorts of red tape and “optimizations” so that it wouldn’t show up on simple tests…but without the useless (as far as correctness goes) “WARM BUFFERS” loop in oalSource.cpp , the Apple OpenAL library crashes even on the simplest of tests, rather than 45 minutes into gameplay as we were seeing before.

Given the shoddy implementation of Apple’s OpenAL that would suffer from such a juvenile race condition, I decided to switch to the Open Source crossplatform version of OpenAL that has languished since Apple worked on their own version and hence only worked on the PPC mac. I ported it (using the SDL backend) to Intel Mac…and that’s what I’m asking you folks to test for me today.

Apologies for the large size. I’ve included the .svn files (which are more than half the space) so that users can keep up to date if they install a macintosh svn client and show package contents and go to resources.

So…test the audio–test the shaders (right now only your very own llama has the juicy goodness of shaderific bump mapping…but Phlogios is apt to fix that now that he can see the fruits of his labor on his very own macintosh)

As for the rest of you: linux users and windows users—well I’ll have to ask you to be patient and keep checking out subversion—right now Apple gets a bit of a head start due to their bad behavior!

The closer we get, the more we want to shove into it.

I’ve taken a break from unitcollection, even though i know it’s bound to need more work, to star working on some actual game experience changing issues. Most notably, texture processing. VS takes every texture it reads, and decompresses it from whatever format it happens to be in, then recompresses it in GL and generates mipmaps. This is extremely time consuming for loading of textures both at the beginning of a game, at the beginning of loading a system, and everytime a unit has to be loaded from disk. Not only is it cpu intensive, but it wastes a lot of ram. I thought DDS files would be an excellent way to avoid most of that and it seems to have worked. More work definitely needs to be done, but dds files load many times faster from disk read to GL rendering than the rest of the VS textures already. As more and more textures get converted to dds files, users should expect to see drastically lower load times.

The downside of such a great thing is that it needs testing before it can be considered stable. And we’re very close to what would have been a new release.

The other thing i’m going to be working on is cubemaps. cubemaps are hopefully going to replace the environment/sphere maps that we use now for space backgrounds. With any luck they should also be able to use compressed textures and natively have much less overhead than the current implementation for backgrounds. This work is slotted for ASAP, but finding the time is proving difficult with work right now, being the end of the month rush.

Another thing we’re trying to discuss and determine is how we want to organize the next release’s dataset and svn tree. It’s already been agreed that the new dataset will be data5.x and the current data5.x will be moved. What is still being determined is how we want to organize the texture maps. We want a repository for master textures (originals) so that we can update them, and read from them, and have them be separate from the compressed/lossy versions in the distribution. At least, that’s how i want to do it.

And finally.  My raided ext3 filesystem has finally succumbed to some corruption…which isn’t surprising since i’m running 24/7 without ac in the summer.

Hopefully i can get this worked out before the end of the weekend.  The corrupted parts are inside the data4.x dir …probably due to the constant activity in that area of the filesystem in addition to the fact that it’s a 500+ GB raided fs.

Anyways, good things are definitely coming.

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….

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.