Let's have a list of parts to download

Shrike · Post by **Shrike** » Wed Jun 04, 2003 9:26 pm

Okay, I know there are some newer binaries, and some newer textures and I think maybe there are some newer ships, and all of these can be downloaded. Can I have a list so I can get the latest stuff and play with it?

pontiac · Post by **pontiac** » Wed Jun 04, 2003 9:34 pm

We could add all these links to the "Download" page of the wiki:
http://www.joeredcloud.com/kandarwiki/i ... eDownloads
Some links are already there.

Pontiac

Shrike · Post by **Shrike** » Wed Jun 04, 2003 10:21 pm

That's a start. Aren't there new background boxes and other textures too?

pontiac · Post by **pontiac** » Wed Jun 04, 2003 10:53 pm

the new background boxes are already in CVS .
And if you don't want to check CVS out i think somebody had them as zip file somewhere....Ah, just saw that you have found the background thread

Not sure about the textures.

Pontiac

Shrike · Post by **Shrike** » Wed Jun 04, 2003 11:17 pm

The finaltextures.zip doesn't include all the background textures, plasma* seems to be missing (and maybe others, I didn't check).

The weekly build kicks out an error looking for libpng3.dll, but the rar from the weekly build site is libpng3d.dll. Renaming the dll fixes that, but then it comes up with a zlib.dll error. I find several different versions of this dll on my box, so I grab one and stick it into the vs dir and that's fine. Then it comes up with a expat.dll error. Don't have any of these on my box. Okay, no big deal I can get that from libexpat.org...only it's not expat.dll, it's libexpat.dll. Renaming once again gets me by that error and program tries to load and hangs. The last line in the stderr.txt is:

1.Loading bmp file vega_splash.png Fatal signal: Segmentation Fault (SDL Parachute Deployed)

The only vega_splash.png I have is in the animations subdir, so I copy it to the vs root and the program tries to run and drives the cpu (1.4ghz/512m ram) to 100% usage and then just sits there. Checking the stderr.txt again shows the same segfault.

I'm thinking the weekly build doesn't work.

Shrike · Post by **Shrike** » Wed Jun 04, 2003 11:21 pm

pontiac wrote:the new background boxes are already in CVS .
And if you don't want to check CVS out

I don't. I could boot to Linux and do a checkout and compile but I'm trying to get the various stuff mentioned in the forums to work in Windows without having to setup a compiler. This is what most people would have to do so that's why I'm doing it that way.

So far, not much luck.

Post by **hurleybird** » Thu Jun 05, 2003 12:22 am

Plasma_galaxy is a new one, but wasnt made by me, so it was not in my texture pack. It is in CVS though, it wouldnt be hard to get the six textures from there.

Post by **zaydana** » Thu Jun 05, 2003 10:40 am

shrike: i get exactly the same problem: hellcat says it is to do with libpng not having the same version for the headers and the library: eg go to libpng website and download headers + library in same package then compile yourself. I havn't tried yet, i will sometime tommorow and will tell you if it works

Also... hellcat added a new dir to CVS ... data4.x =D yay! its got all the backgrounds ALL NEW SHIPS! really nice new ships with graet textures and all... its got most of the stuff i think... its only bout a week old so it should do. BTW... who did those textuers and ships? they is really nice.

Ziolas · Post by **Ziolas** » Thu Jun 05, 2003 11:16 am

shrike: i get exactly the same problem: hellcat says it is to do with libpng not having the same version for the headers and the library: eg go to libpng website and download headers + library in same package then compile yourself. I havn't tried yet, i will sometime tommorow and will tell you if it works

The correct dll's have been moved to data4.x\bin folder. Check it out, and it will work. BTW, sorry for not posting new builds, but my hdd is badly damaged so I can't do anything until I get a new one. That'll teach me not to buy cheap samsung drives

*UPDATE*
I've managed to get-around the problems. I'm back in bussines. Todays builds will be online shortly. Yay.

Shrike · Post by **Shrike** » Thu Jun 05, 2003 3:30 pm

zaydana wrote:shrike: i get exactly the same problem: hellcat says it is to do with libpng not having the same version for the headers and the library: eg go to libpng website and download headers + library in same package then compile yourself. I havn't tried yet, i will sometime tommorow and will tell you if it works

Also... hellcat added a new dir to CVS ... data4.x =D yay! its got all the backgrounds ALL NEW SHIPS! really nice new ships with graet textures and all... its got most of the stuff i think... its only bout a week old so it should do. BTW... who did those textuers and ships? they is really nice.

Newp. As I said, I'm just trying to get the stuff which was mentioned here working. Most non-Linux users are not going to be doing any compiling, (and I'm not going to be compiling in anything but Linux). Doing a cvsupdate defeats the purpose of my excersize.

I got the finaltextures.zip to work simply by extracting to the existing directory and overwriting anything that was there that had the same name. Okay, that's fine, but a readme should be in the zip telling me to do that. The thread on the forum said that "all" of the textures had been redone, but if they had, they weren't in that zip.

The weekly build is useless. Why compile a binary if the end user has to download and compile something to go along with it? If they are going to compile, they might as well compile the whole thing themselves. Why not build a statically-linked binary for the weekly build and avoid the problem?

I also grabbed the Aera ships from the VS web site and unpacked them, but I wasn't in the game long enough to run into any of them to see how they worked.

This was the point, to try to grab the various parts which have been mentioned in the forums, and see if they work. They don't. Yes, they -can- be -made- to work, but not easily or simply.

Back on the old forum I had mentioned that there should be something which ship designers could reference which defines what goes in a new ship.zip, i.e., which files must be included, such as the .blank and the .template, as well as the .xmesh, and -also- the cockpit and the icon for the HUD and textures. The whole package. The new Aera ship zips were perfect, down to even including a readme file.

This same rationale applies to anything which someone would download and apply to the game, whether a texture pack or a replacement binary (are these the only two downloadable updates for the game, besides the Aera ships?). At the very least, a readme should be included. In the case of the compiled binary it would have been much better that trying to squash the errors one by one as they magically appeared.

Don't get me wrong, I appreciate the work that went into these, and I'm certainly capable of getting them working, but I'm playing the role of an end user in "dummy mode" and reporting on that experience. And what I experienced was frustration, not satisfaction.

pontiac · Post by **pontiac** » Thu Jun 05, 2003 5:30 pm

@ Shrike:
I see no problem in using the data from CVS.
Here is what i do:
* checking the CVS- "DATA" directory out (checkout is also described here) (don't know if the "DATA4.x" works with the weekly)
* copy the weekly binary into the data dir
* start the binary

Though the binary is a bit slow (for me), but onyl when it comes to load the different station screens.

Pontiac

Ziolas · Post by **Ziolas** » Thu Jun 05, 2003 5:45 pm

The weekly build is useless. Why compile a binary if the end user has to download and compile something to go along with it? If they are going to compile, they might as well compile the whole thing themselves. Why not build a statically-linked binary for the weekly build and avoid the problem?

The user doesn't need to compile anything as all dlls are there. I have uploaded some simple instructions on how to get started. Tell me if they are clear enough. I dunno if it can get any simplier. And statically-linked bins would take too much space, and are pointless since the dlls are there.

Shrike · Post by **Shrike** » Thu Jun 05, 2003 5:59 pm

@ Shrike:
I see no problem in using the data from CVS.

You miss the point. I myself have no problems using CVS. I've used it for years. I think I recall originally using it when it was alpha.

The point was to do it the way that 99% of normal users would do it: Download the updates and try to use them. They didn't work.

Yes, I could play with them and find workarounds. I could "figure it out". Most people can't, or won't.

Keep in mind, if we are talking about the weekly binaries, then that's Windows. Unlike Linux, Windows comes with neither a CVS client nor a compiler. Normal Windows users don't have these things. If they had them, they wouldn't need someone else to build it for them.

Shrike · Post by **Shrike** » Thu Jun 05, 2003 6:02 pm

Ziolas wrote:
The weekly build is useless. Why compile a binary if the end user has to download and compile something to go along with it? If they are going to compile, they might as well compile the whole thing themselves. Why not build a statically-linked binary for the weekly build and avoid the problem?
The user doesn't need to compile anything as all dlls are there. I have uploaded some simple instructions on how to get started. Tell me if they are clear enough. I dunno if it can get any simplier. And statically-linked bins would take too much space, and are pointless since the dlls are there.

What dlls are where?

Please do keep in mind that I'm not trying to pick on you, I think what you are doing is good. I'm playing Devil's Advocate from the POV of a normal end-user.

Shrike · Post by **Shrike** » Thu Jun 05, 2003 6:31 pm

Ziolas wrote:I have uploaded some simple instructions on how to get started. Tell me if they are clear enough.

Ahh. Yes they are quite clear, and the batch file is a nice touch. I will post the readme here both to get it in the database, but also to ask a question about it:

===============
getting started.txt
from
http://republika.pl/ziolas/vegastrike/

Getting started:
Bypass steps 1-4 if you already have the data.
1. Download and install cvsnt from www.cvsnt.org
2. Create a folder ("C:\vegastrike" is a good choice)
3. Copy the file getdata.bat to that folder
4. Run it. It will take some time depending on your connection speed.
5. Unpack the build file (use winrar 3.20 or later) to the "data" subfolder of your folder.
Example: If your folder is "c:\vegastrike" unpack the file to "c:\vegastrike\data"
6. You're set. Run "yourfolder\data\vegastrike.exe" to play
========================

Okay, the question is line 2: "Bypass steps 1-4 if you already have the data."

Does the data never change? If it does, perhaps the batch file should do a cvsupdate and then line 2 would say, "Bypass steps 1-3 if you have used the weekly update before".

Since this is a "weekly build" we can assume some will use it weekly, and thus they may need to update their data weekly.

Also, if you are going to write a batch file to script part of the download process, why not script the whole thing? I.e., download the weekly binary and unpack it to the right dir. This makes it easy for anyone to just run the script once a week and be done.

Logically:

if exist c:\program files\vegastrike\weekly beta\
then
goto update
else
mkdir
get all
touch desktop\vsbeta.lnk
goto end

[update]
cvs -update -blah -blah -blah
get binary ; unpack binary
goto end

[end]
echo "Weekly Beta Update completed"

Ziolas · Post by **Ziolas** » Thu Jun 05, 2003 8:17 pm

Okay, the question is line 2: "Bypass steps 1-4 if you already have the data."

Does the data never change? If it does, perhaps the batch file should do a cvsupdate and then line 2 would say, "Bypass steps 1-3 if you have used the weekly update before".

Since this is a "weekly build" we can assume some will use it weekly, and thus they may need to update their data weekly.

Good idea. Already done, but I don't know if it will work in win9x/ME. If anyone can test it, let me know. I'll also add some error-handeling later.

Also, if you are going to write a batch file to script part of the download process, why not script the whole thing? I.e., download the weekly binary and unpack it to the right dir. This makes it easy for anyone to just run the script once a week and be done.

Don't know if it's worth it. The site on which the files are stored does'nt support anonymous ftp.