Spring RTS Engine

Issue:

F:\games\strategy\spring is where I keep spring, note the weirdness with the string concat.

Minor bitching:
so yeah, I get maybe 3 hours an evening to test gundam. This continuous updating is getting a bit annoying, kicks me off the server, I have to download the latest update and by the time it downloads all it's shit including redundant files I have maybe an hour or two left. Which does not allow for much testing. Are these latest releases for major bugs or minor fixes? *edit* so including the precaching TASClient does: 1hr 25min*/edit*

Same issue for me.

And wahtever happened to update installers? Smoth is right that generally we don't need to redownload the base files every time.

Same happened to me, I had to manually download the b4 exe and reinstall.

Same here.

Jonanin wrote:Same happened to me, I had to manually download the b4 exe and reinstall.

same thing for me, except when i manually dl'ed the b4 exe and tried to update with it this happens.

"Error opening file for writing:

E:\Jez's Crap\Games\Spring\unitsync.dll"

then asks if i want to retry, abort or ignore.

I did ignore just to see if it would work anyway...the same error came up for many more files, a lot of dlls, and even Tasclient.exe

You need to close springdownloader for that.

And I have the same problem, cmon people, test before relaeasing!

link

but why do i have to install it completly new? why no update, is it sooooooooo hard to make the next 0.77b5 as update?

smoth wrote:Are these latest releases for major bugs or minor fixes?

Thats what changelogs are for...

FLOZi wrote:Same issue for me.

And wahtever happened to update installers? Smoth is right that generally we don't need to redownload the base files every time.

They changed, so a redownload was needed.

And I tested the installer before releasing it, it worked. Don't know why it fails in autoupdate.

Also:
STOP WHINING. Make suggestions how the release workflow can be improved instead.

Okay, the update should just work, you shouldnt have to do anything for it, currently you need to find out that you needs to close clients, downloader, ect, those need to be closed automaticly by the installer, alot of people cant upgrade, and are confused.

Auswaschbar:

smoth wrote: it downloads all it's shit including redundant files

FLOZi wrote: And wahtever happened to update installers? Smoth is right that generally we don't need to redownload the base files every time.

I am not always the best for describing things it seems somepeople pick up on what I am getting at and others miss it. I need to work on that I guess. Anyway see quoted lines.

only for info, autoupdate doesnt work for me 2.

Hoi wrote:And I have the same problem, cmon people, test before relaeasing!

How are they supposed to do that? If it works right for 3 or 4 people then they have pretty much gone to the max extent that they can to test. You're on IRC most of the time, so you know what is going on behind the scenes generally.

And to the rest of you, What AUS said. Quit whining. It's not a perfect world, and there is no such thing as a perfect release. Shit happens, so deal with it and be constructive.

Forb, I know you are having a hard time and probably posting emotionally. Don't forget yourself. I was the one he said was whining which I did, venting/bitching can be seen as whining, so I guess he can vent back. Flozi and I were also attempting to make helpful suggestions. I apologized for my lack of clarity in my reply to the thread. However, he was talking to me so it is not fair to attack the rest of the thread.

The bug exists and the the updater needs to take less time. The updater IS erroring for some people. This is a legitimate defect as it showed up in the latest download. To dismiss a real defect as whining would be foolish. That isn't what he is doing. Reporting issues is important, we are all trying to help the devs.

FYI: I wasn't even aware that TASClient tries to download and launch the update file itself... I always download by hand (guess having insider information about the release helps ^^)

Update installers are complete time-wasters, until the team has automated dif tools set up that can create one automatically, creating an installer "package" with a button-click. Doing it by hand is a massive waste of coder-time.

I am pretty sure that such things are available for automated build environments, and this would help a lot (I've been thinking I need to get one for P.U.R.E. patches, eventually).

Also, if we had fewer DLLs that were version-dependent (a tall order, I realize) then compile times and the size of the final deliverable would both shrink considerably, I suspect- why re-compile all of the AI DLLs because you changed one line in Spring or UnitSync?

Updating installers used to be made a long time ago but, as Argh already said, without full automation they take incredible amount of extra time:

- At least two times amount of installer testing, at least full one and updating one. Even worse in case of updating installers we made cause they claimed to be able to update any e.g. 0.77b* to 0.77b4, so you'd need to test 0.77b1->b4, 0.77b2->b4 and 0.77b3->b4. Besides that you'd need to test uninstall of all those combinations. And if you want to do the full thing you'd need to test actually all upgrade paths (e.g. 0.77b1->b2->b4, b2->b3->b4, etc.) or ensure single upgrades end up exactly same as the full install variant for that version..

- NSIS can make patches for files in the installer, but, IIRC, you still need to figure out which files you want to include by hand.

It could be worth taking a look again, but I'd advise to make some tests then. Maybe I'll pick up on my installer tests using wine again actually.

Thanks for explaining it Tobi.

thanks tobi

I'm actually playing with the idea of dropping content altogether from installer starting from next release (except springcontent.sdz and bitmaps.sdz of course), to push modders to make their own installers.

If so however, I'd want to have tool too for modders to easily make this installer, like just put some checkboxes "include OTA content", "include SpringLobby", "include TASClient", "include Spring" (for version for ppl who already have Spring), etc., so it's really easy to build new installer with new Spring version. This way it would also reduce chance for possible installers that would break existing Spring install.

Tobi wrote:I'm actually playing with the idea of dropping content altogether from installer starting from next release (except springcontent.sdz and bitmaps.sdz of course), to push modders to make their own installers.

If so however, I'd want to have tool too for modders to easily make this installer, like just put some checkboxes "include OTA content", "include SpringLobby", "include TASClient", "include Spring" (for version for ppl who already have Spring), etc., so it's really easy to build new installer with new Spring version. This way it would also reduce chance for possible installers that would break existing Spring install.

+infinity

Its about time that this was done and that your having to force the hand of content developers to get it done is sad. I really should get on with that NSIS installer blogpost.

Either way an installer that just has the core engine would be useful, as long as it was marked out as such clearly.