Reviving Vega Strike

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

JsnMtth wrote:That seems like an excessive amount of "configuration" to expect an end user to have to do. It would be better IMO to have the program load a different shader when cubemaps are enabled and the shader in use is highend. Another option is to enable cubemaps in the configuration file, instead of using the preprocessor flag. This is of course assuming we're going to support bother cubemaps and spheremaps. If we're not going to support them, then it doesn't matter how we make the transition. Eventually everyone uses cubemaps, the spheremaps code and shaders disappear.
I strongly advocate erradicating every trace of spheremaps, and making a decisive switch to cubemaps, burning the bridges behind. There is no practical need to support spheremaps, as hardware vendors have supported cubemaps for a whole decade, already. I managed to win Klauss to my point of view; not sure if I've succeeded with Safemode. The only real problem, IMO, is getting a windows binary. I would hate to have to delay the official inauguration of dds cubemaps because we can't offer them to Windows users. On the other hand, I would hate even more to have to have two sets of shaders, and to make cubemaps a configuration option.
Can Windows users use the development data with the last binary that was built? Because they can't build a binary at the moment telling them to compile it won't work. If they can use the development data, then committing cubemap shaders to trunk is a bad idea. They won't be able to use new models and such that don't depend on cubemaps. A cubemap branch would need to be created and the cubemaps change committed there. Then when the cubemap code works on all the "supported" platforms, it can get merged into trunk.
Well, this amounts to having a non-windows branch until windows can catch up. The problem has nothing to do with cubemaps, really; rather with our inability to compile for windows. But it's probably the least of all evils, tho.

EDIT:
Yeah, I think what we should do is create a Windows tag; NOT a cubemaps branch; a Windows compilation problem addressing freeze-point.
Why?
Because, again, the problem is un-related to cubemaps; and it will rear its ugly head again with the next feature, and the next.. Until we can
compile for Windows again.
So the correct modeling of the problem is to just have a Windows branch for /data which only gets updates that are compatible with the current
Windows binary.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: Reviving Vega Strike

Post by JsnMtth »

Sounds good to me.
snow_Cat
Confed Special Operative
Confed Special Operative
Posts: 349
Joined: Thu Jan 05, 2006 12:43 am
Location: /stray/
Contact:

Re: Reviving Vega Strike

Post by snow_Cat »

^ - -^ Seems to be the best solution.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Reviving Vega Strike

Post by charlieg »

FWIW, I agree, move to cubemaps only.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
Turbo
ISO Party Member
ISO Party Member
Posts: 423
Joined: Mon Jun 11, 2007 11:54 am
Location: TX, USA
Contact:

Re: Reviving Vega Strike

Post by Turbo »

safemode wrote:So basically, a unit starts out with only their home system with a decent map of it. over the course of getting a jump drive, they may purchase some maps of varying quality depending on the location/price. There could even be a new class of job "explorers" that chart uncharted territories, or update less traveled areas for a price for merchant guilds and such.
Among the militia ship-to-ship communication lines is one where the militia pilot tells the player, "Here, you can use the readings from my nav computer... [Transmitting nav data.]" What is that about, if not the existence of previously-unknown navigation data?

Edit: I created a SourceForge account, named "Turbo6" because someone else is using "turbo."
Turbo

There are two speeds in combat: stopped, and as fast as you can go. Unless you run into something, going fast keeps you alive more often than stopping.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

Couple of things i've been finding while cleaning up gcc 4.4.2 warnings in the code-base.

1. unsigned int != size_t. At least on amd64 archs. size_t is 64bit, unsigned int is 32bit. Thus comparisons to say, string::npos will fail in the case where they should not, since unsigned int can never equal string::npos on such an arch. Be careful, just use size_t.

2. We need to implement a --debug or --verbose flag when running VS or compiling VS. There's no need for any user to want to know half of the crap vs spews during loading and running. Yet, there is no way to turn it off. The easiest way to do this is to use precompiled macro's that are inlined in the vsfilesystem.h header to be null functions. The compiler then should optimize the calls out in the codebase if we dont compile in VERBOSE mode. Something along those lines.

Other than that, most of the warnings are harmless. Caused by people comparing int counters to unsigned int variables. I'm sure most people are now using gcc 4.4.x so you should be seeing the warnings when you compile your changes. Do not ignore them.

Right now i'd say i'm mostly done with cleaning up warnings. Just a few more left in vegastrike specific sources , and a little one in replace and asteroidgen.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

I think the only ones writing code presently are you and Klauss; and Klauss uses size_t religiously.
So will I when I start hacking C++. Just hacking shaders for now.
Not sure if you're aware that Jason is working on getting the engine to compile for Windows again.
You might want to check his thread from time to time and give him a hand if you got a chance.
Here's his latest post.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

generic.cpp is a 9 year old memory leaking fiend :) It's copied with it's header in like 3 places and is nearly the same in each case. Ugly.

I'm looking into probably replacing it.

Which brings me to something else. We do a decent amount of string manipulation. This is most safely done via stl's classes, not via malloc and friends.

I'd really like to see all strings in VS moved to stl implementations. I'd rather have STL worry about memory handling than VS.

Keep an eye out for any new segfaults or infinite loops. If you come across any let me know about it because moving to unsigned int from int in many places could cause a change in behavior due to buggy code ... also in many of those places i probably should have moved to size_t instead of unsigned int.
Ed Sweetman endorses this message.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: Reviving Vega Strike

Post by JsnMtth »

Which implementation of STL are we using?
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

gcc 4.4's libstdc++6


edit: or basically gcc >= 3.x libstdc++6 works.

If you're looking for a win32 compatible stl.... you'll have to find the exact setup used by those who compiled the win32 bin before, as i'm positive they had to jump through hoops to get visual studio to compile things.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

safemode wrote:gcc 4.4's libstdc++6


edit: or basically gcc >= 3.x libstdc++6 works.

If you're looking for a win32 compatible stl.... you'll have to find the exact setup used by those who compiled the win32 bin before, as i'm positive they had to jump through hoops to get visual studio to compile things.
Jason is trying to use mingw.
And what's the story with hash_map? That's not standard stl yet; or is it? Last time I was working with it I was using an SGI version; I think the engine was using the one from STLPort, I'm not sure. At the time, BOOST were working on their own hash_map. So, which exactly is the one we use?
EDIT: Never mind; it will NEVER be standard STL. Hash_map is doomed. To be replaced by unordered_map...

So, how about we just make the move to std::tr1::unordered_map<>?
MS supports it already:
http://msdn.microsoft.com/en-us/library/bb982522.aspx
It's the exact same thing; just change the container type, and massage the code
a little bit if necessary, and it'll be forward compatible to the upcoming STL, and
compatible across platforms. It's a win win.

EDIT2:
Check this out: Open MP (Multi-Processing) library:
http://msdn.microsoft.com/en-us/library/533yh8c6.aspx

EDIT3:
I was just in chat with Klauss and mentioned to him about unordered_map<>, and
he says he believes this is already IN the engine, with some switch that uses
std::tr1::unordered_map<> instead of hash_map when it is available. But it should
be available, already, in all stl's. I don't mean it's mandatory; but market demand...
Why is the compiler trying to compile with hash_map?

EDIT4:
Found it! All this switcharoo is in /src/gnuhash.h
Trying to understand it...
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

haha
I ported the game to unordered map a long time ago. cmake looks for it and uses it if we have it in our boost installation.


edit: yes, i hated hash_map back in the day. So i transparently moved everything to unordered map when i was doing my "move everything to STL dammit" commits. We get our unordered map code from one of the many boost configurations we look for. cmake defaults to system boost, then looks for any pulled copies (i believe unordered map is found in boost anyway).

whether it's boost or not, either way we already use it with a config flag. That config flag is easy to spot in the cmake configs


edit Again:

For win32, I suggest letting yourself go insane. then when you've stared into the abyss, get sane again and try to find hellcat's or "whoever did the win32 bins before"'s config.h file and go from there. There are a lot of defines that must be set and in unix like systems there are tools to create this file automatically, but i'm not sure what was done on win32 to generate it. There are a few vc branches in svn that supposedly is what was used to create the win32 bins but i dont develop on that platform at all.

cmake exists in win32, and there used to be someone who tried working with it in windows, but i dont know whatever came from that. Theoretically, with cmake, you should be able to generate VC build files from the same set of config files (though some search paths may need conditional editing for windows) that the unix builds use. Which was why i introduced cmake into VS. I was hoping that all our ports would be buildable from the same set of config files automatically by cmake. Removing the black magic from the whole process.

I haven't used the autoconf setup in VS in probably a year. cmake just makes the whole process much easier to maintain.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

Good!

Klauss asked me to ask you... Do you know where/how to add textures to planets?
He wrote an AMAZING shader for planets, with paralax, with clouds that cast shadows
AND shadow themselves, volumetrically; proper scattering... But that shader is just
sitting there gathering dust because he needed to add a texture or two to planets
but couldn't figure out how to do it.

He says some planets have city lights, so there must be a way.

I was saying to Klauss, maybe the whole idea of planets being special should go.
Why can't planet types (in units.csv), not call for a bfxm like any other unit? Then
the bfxm can call whatever textures are needed; and even specify a technique,
which can in turn specify a shader...
Then we could have a special shader for ice planets, using sub-surface scattering,
for instance.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

On a different note, and taking on something mentioned in a different thread but more appropriate to this one, we need to address release cycles.

The #1 reason why we dont have shorter release cycles is not a lack of activity in development (although that did occur these past few months) but because we dont have a solution to the /data problem. Fix that, and we can release whenever we want.

Basically the question is:
How do we incrementally update users in a cross platform semi-automatic way without whoring sourceforge's services?

Easy answer:
Create a utility that uses python to access svn and export tags. This can be distributed with the vegastrike bins. note: (not a python script, but a program like vssetup only compiled against python libs too).

Problem with easy answer:
It uses svn, which is server intensive and basically abuses sourceforge's services.

harder answer:
Create a patch via some binary diff tool between last release and current (cross platform utility required). Then create a utility (cross platform) that parses the diff and makes all necessary changes to the installed directory.

Problem with harder answer:
This likely forces users to download and install each increment in order. it also means writing a lot of the functionality of patch and diff, etc.


We really need some other ideas or agree and get started on using the harder answer above. Before any idea of releasing the next iteration of vegastrike, we should have this setup and in-place so that we can make incremental revisions rapidly from then on. This is right up there with updating textures and models to use the new shaders to finishing the new shaders and getting the code more cleaned up a bit more and release ready in terms of compiler issues and runtime errors on all platforms.

Obviously this is a less fun area of development but it's _really_ necessary. Lets brainstorm some ideas on how to solve the issue, then worry about how and who is going to write what needs to be written.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

It seems to me the right answer would be the easy one.
The problem with it is technical: the inefficiency of svn; but svn is not the only
solution available; there's also git, which I believe is stellar in terms of efficiency.
So, perhaps I might suggest you could use the wcjunction server, if SF doesn't allow
it, install a self-updating git mirror of vegastrike, and you can distribute updates
that way. I think my bandwidth limit is 2 terabytes per month; should be plenty,
and I could get extra terabytes for just a little extra money.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

Well, i dont think it matters to this updating of data at the end user's end whether it's git or svn. As both would require downloading a diff between tags, they should both be sending the same data unless git does binary diffs and that is cheaper than just replacing the file completely as is done in svn. Otherwise the other features of git vs svn dont play into this problem at all. All we care about is being able to export (not pull to an svn working dir, but just export) a change set between a revision installed on the user's computer with one they select to update or downgrade to.

But when it comes to whatever the utility is going to be, it will have to marry itself to an embedded or python scripted svn or git client that is totally self-contained. Which can be done more easily and in a tighter package will likely win.

here's some overall requirements i think the data updater needs

1. must be self contained
2. needs to be able to be stripped down so we can expose a simple api for retrieving revision tags and merging diffs between a selected tag and current working version.
3. Needs to be able to export to fs without all the extra revision files that normally accompany something like an svn pull. (.svn). We save current working revision via a file so we can figure out how to tell the server what to diff.
4. Needs to be cross platform, no multiple solutions for multiple archs.
5. This utility need not have a graphical interface, indeed, it's better it not, so that we can provide a gui in-game eventually.

The goal i think would be to merge vssetup and this updater into vegastrike (and maybe vegaserver ...i dont know about that aspect of the game) and we can start out with no /data at all. so you can call ./vegastrike --update and it would bring up a graphical menu in GL and let you work from there to update an existing /data or if no /data exists and you run that or try running vegastrike at all it'll give you a black window with a textual readout to grab /data then continue loading the game from there.

but for now we would be infinitely better just to have a standalone python script or something that ran in console mode on all archs.
Ed Sweetman endorses this message.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Reviving Vega Strike

Post by charlieg »

Don't abuse SVN as a data distribution tool for users. You might have 1000s of users if a release gets a lot of publicity. Not only will it be unfair on the SF.net service, it'll also be pig slow for users to download updates if more than a few do it at the same time.

I have encountered many packages over the years that make use of the right SF.net download channel - it's mirror service.

You have a list of known mirrors and the URL format. Keep this in an easily accessible file - e.g. vegastrike.sourceforge.net/mirrors.txt - and when mirror URLs change, this file can be changed, and there is very little headache for users.

You can wget from that URL. Current URL format:

Code: Select all

http://downloads.sourceforge.net/project/vegastrike/vegastrike/0.5.0/vegastrike-linux-0.5.0.tar.bz2?use_mirror=garr

# wget http://downloads.sourceforge.net/project/vegastrike/vegastrike/0.5.0/vegastrike-linux-0.5.0.tar.bz2?use_mirror=garr
--2010-01-11 19:49:34--  http://downloads.sourceforge.net/project/vegastrike/vegastrike/0.5.0/vegastrike-linux-0.5.0.tar.bz2?use_mirror=garr
Resolving downloads.sourceforge.net... 216.34.181.59
Connecting to downloads.sourceforge.net|216.34.181.59|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://garr.dl.sourceforge.net/project/vegastrike/vegastrike/0.5.0/vegastrike-linux-0.5.0.tar.bz2 [following]
--2010-01-11 19:49:35--  http://garr.dl.sourceforge.net/project/vegastrike/vegastrike/0.5.0/vegastrike-linux-0.5.0.tar.bz2
Resolving garr.dl.sourceforge.net... 193.206.140.34, 2001:760:ffff:b0::34
Connecting to garr.dl.sourceforge.net|193.206.140.34|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 520498096 (496M) [application/x-bzip2]
Saving to: “vegastrike-linux-0.5.0.tar.bz2”

 0% [                                       ] 554,125      516K/s

Then upload data to the proper location, the Sourceforge download service, as minor versions and increments. That is, have:

- 0.5.0 data (full)
- 0.5.1 data (full)
- 0.5.1 data update (0.5.0->0.5.1)
- 0.5.2 data (full)
- 0.5.2 data update (0.5.1->0.5.2)
- 0.6.0 data (full)
- 0.6.1 data (full)
- 0.6.1 data update (0.6.0->0.6.1)

Each update could include a list of files to delete, and a set of files to install that either overwrite or get added. No binary or diff / patch files. Keep It Strictly Simple. Updates are simple to generate (previous version to next). If you want to update 0.5.0 to 0.5.3, you just apply the updates in sequential order.

That kind of tool is a straightforward. An amateur programmer with a bit of persistence could hack that together in python. You can include wget with Vega Strike - it works on all the platforms Vega Strike does.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

Sounds simple enough; and I can't see why there couldn't be a python app in-game or off-game
that checks for new available updates; and applies several sequentially, if necessary.
The list of releases and updates could be an xml file in a fixed url the script knows about,
so it parses the file to see if there's a new update; and if there is, it goes to SF to download it.
Or it could be connected to a button on the main screen.
Check_for_updates.mission

What's still not clear to me is how you create update files. Is there some tool that can
automate the process and is cross-platform?
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Reviving Vega Strike

Post by charlieg »

No, just use diff -q to get a list of different files, and - again something an amateur with python could write - a script to take the output from that and copy (with dir names) new files in to another location and create a list of files to delete.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

That's exactly what my second example was. ie, harder solution.

The reason why it's harder is that you need a tool that can generate the diff and it needs to be cross platform. We can't just assume we'll always have unix people around to generate it, likewise, same goes for win32. The diff util thus needs to handle being given a directory and making modifications not only to files but to directories / names and adds and deletes. diff (unix util) handles this but i'm not clear as to how compatible any win32 port would be in generating the same output given the same source. I suppose it should but i've not tested it.

Then, we need a utility that will retrieve this patch file and parse it accordingly. Deleting, renaming , adding and modifying directories and files in the target dir. Again, a utility like patch in unix land does this, but unlike the diff utility, this utility that parses the patchfile must be shipped with vegastrike and be cross platform and hopefully self contained to very few, if not 1 file. :)

All of this is done automatically in an svn/git type client, which is why i said that was easier than the harder solution.

And the downsides you mentioned of using the easy solution were addressed in the same post.

Which is why i also suggested going the harder route. but I'm willing to discuss both. Obviously, there are other source repositories other than sf.net available. There's that and the reality of how much work vs how likely we'll be to get that work done. either way, we need a solution.


You can use the same requirements i mentioned previously for something that uses a patch based update system, just ignore the stuff that's obviously svn/git oriented (revision control file stripping etc).

i think ideally, in a patch based system, we would use torrents with the seed server being say, hosted on wcjunction. This should lead to the highest transferrates for users while reducing bandwidth load on wcjunction. Worst case scenario there would be regular wcjunction bandwidth, best case, throttle the user's downlink. :) plus we would have regular mirrors in sf.net

More work obviously than slipping something like wget's functionality in, but definitely cooler.


edit:
as for the version file, i was thinking something even simpler than an xml file. Just a flat list, but then i was thinking we could implement mirrors, torrents and primary (full download) vs incremental updates in an xml file much more neatly. The updater then can parse it and provide options to the user, with each revision offering it's own set of urls and download mechanisms.

something like

Code: Select all

<version>
      <major val="0' >
              <minor val="6" >
                     <rev val="0" type="full" md5sum="somesum" size="totalpatchsize">
                           <url href="someurl" type="torrent" />
                           <url href="someurl2" type="http" />
                           <url href="anotherurl" type="http" />
                           <url href="and_so_on" type="http" />
                      </rev>
                      <rev val="1" type="inc" md5sum="somesum2" size="totalpatchsize">
                           <url href="someurl" type="torrent" />
                           <url href="someurl2" type="http" />
                           <url href="anotherurl" type="http" />
                           <url href="and_so_on" type="http" />
                       </rev>
<!-- And when we eventually want to make a 0.7.0 we can do both full and incremental so that 0.6.0 users dont have to redownload everything. -->
             </minor>
             <minor val="7">
                       <rev val="0" type="full" md5sum="somesum3" size="totalpatchsize">
                            <!-- urls -->
                        </rev>
                      <rev val="0" type="inc" md5sum="somesum4" size="totalpatchsize">
                      <!-- urls -->
                      </rev>
             </minor>
        </major>
</version>
the updater then checks the type and if you need a full download, uses the full, otherwise if you have a repo, it uses that. And it can be made smart enough to add the sizes up to download whichever is smaller if you're moving from a distant version.
Ed Sweetman endorses this message.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Reviving Vega Strike

Post by charlieg »

You are overcomplicating things. Don't let perfect be the enemy of good.

1. I said use python. Python is cross platform.
2. With mingw, so is diff.
3. Don't go for perfect. A list of files to delete, and an archive of files to unpack. That is all an update needs to be. Forget renaming, merging, whatever. That's overkill. Updates need only apply to minor versions i.e. 0.5.0->0.5.1 and there is nothing wrong with expecting people to download the full data pack for new major releases (and in VS world 0.6 is a new major release from 0.5).

That would be simple, would work on almost any platform, and all you need is 'diff -q' and a python script to parse the output, generate a list of files to delete and execute 'zip update-foo.zip <args>'. Oh, and a python script to do the outbound - that is, unzip and run 'rm <delargs>' or whatever the local OS command is.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

...and show instructions to the user for what to do, whenever vegastrike.config changes...
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: Reviving Vega Strike

Post by JsnMtth »

The incremental patches seem like the way to go to me (the harder way). They could be numbered for example, a utility could download and update the data for you. The instructions to the user are "push the update button and wait". These patches could be auto-generated too by a server side script I imagine. TA-Spring is using torrents to distribute game content as well, we might be able to offload some server traffic that way. That would make producing a "nightly-build" possible too, reducing the amount of "users" that need to do an svn checkout to play the "latest and greatest". We could tag the engine too, so it refuses to update data for an old and incompatible engine version.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

charlieg wrote:You are overcomplicating things. Don't let perfect be the enemy of good.

1. I said use python. Python is cross platform.
2. With mingw, so is diff.
3. Don't go for perfect. A list of files to delete, and an archive of files to unpack. That is all an update needs to be. Forget renaming, merging, whatever. That's overkill. Updates need only apply to minor versions i.e. 0.5.0->0.5.1 and there is nothing wrong with expecting people to download the full data pack for new major releases (and in VS world 0.6 is a new major release from 0.5).

That would be simple, would work on almost any platform, and all you need is 'diff -q' and a python script to parse the output, generate a list of files to delete and execute 'zip update-foo.zip <args>'. Oh, and a python script to do the outbound - that is, unzip and run 'rm <delargs>' or whatever the local OS command is.
Unfortunately, in win32 land, they dont have python installed. Python exists as a C++/C lib shipped with the game. Thus, a python script wouldn't do.

We could compile a bin that basically used python in the same way the game uses python, but all the helper functions provided by a full python install wouldn't be available and we'd have to implement/ship everything required from parsing a patch to wget functionality.

I'm not trying to say it should be perfect off the bat. Just that anything worth spending time writing should be written in a way that wouldn't require rewriting completely to make perfect. That requires knowing what the end result is going to look like, and then deciding how to put a limited subset of that together in a way that will allow the rest to be written later or by someone else.

eg. Having it as a standalone app would be ok but it should be written in a way that creates an api that can be plugged into vegastrike so that one day when we merge vssetup into vegastrike we can also merge the update utility by doing little more than substituting the UI.

I just dont know how many python programmers we have active at the moment.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Reviving Vega Strike

Post by klauss »

Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Post Reply