After a week of intense bugfixing, we proudly announce: Spring 0.80.1

We will wait 2 days before deploing the new version on the server, so installer, packages etc. can be made.

Changes:

• don't write spring-files where they don't belong
• some rendering fixes (ATI errors, bumpwater)
• IPs of players not broadcasted
• area reclaim doesn't know of features not in los anymore
• slightly better paralyzeDamage handling
• fixed several issues with ArchiveMover - it now moves files to
  My Documents\My Games\Spring and should be more reliable

Download links can be found on the download page

THanks to everyone who helped testing, notably MelTraX, tizbac, SteveZissou and Pizzi (and anyone I might have forgotten to list here).

Please make a separarate directory for the stray files in the main Spring folder for this next release.

stray files?

But why do you look at the folder anyway?

Which boost version is now required?
Last release it was 1.35< but I heard something about going backwards to 1.34?

some buggies:

• can't run any other skirmish AI than RAI (infolog.txt from 'gameplay' againist KAIK) - crash just after start
• when running new XTA (9.585) some Core units are missing textures - they've got only team colour - examples: 1, 2, 3 & 4. everything worked fine before (0.79.1.2).
• i find it strange gameplay leaves some RES files in Spring dir. after couple of battles there will be such a mess...

suggestions:

• if you move mods/maps into users data directory, can you move there: screenshots, config files, etc too?
• could you make Spring Downloader installation not dependent on TASClient installation?
• it'd be great if installing/uninstalling Spring (separate dirs) don't reset resolution to default (1024x768) no matter if i want to keep settings when installer asks

PS: are the other AIs from repository not included cause of bugs/errors or are they still in development/upgrade phase? i mean NTai and E323AI.


me too:

Hehe, yeah thats what I mean. I hope it is still 1.34 compatible.
Will change the packaging requirements.

Because it's my main Spring Folder. I have all sorts of files I often edit in there such as UiKeys, Selection editor etc. When there's an extra 20-30 odd files in there, it makes it hard and it looks messey anyway.

There is no need to chuck loads of files in the main folder. I suggest you chuck all the important ones that don't even need to be opened in their own folder so noobs don't go and screw them up accidentially.


The Spring folder is a tree. All the sub folders inside it are branches. The files inside the folders are the fruit. Unfortunately, the nasty farmed doesn't want us touching his fruit and so he hid them high up in the branches. However, for some reason, the tree is growing fruit from the trunk of the tree. The small kiddies can easily grab the fruit growing from the trunk and steal or ruin them. Somebody has given the farmer advise to pick off and hide all the fruit that grows from the trunk to keep his fruit safe from kiddies.

Already possible. Just set spring-datadir path to where you want those files to be, or install somewhere you don't have access rights (program files / uac on)


On normal install, it should use your old settings (including resolution).

Install spring to program files, keep your user files in "My Documents/My Games/Spring", problem solved.

there's currently a problem with settings - unitsync doesn't pick up your app data/springsettings.cfg and instead insists on writing a new one if the installation dir is writable.

if you mean installing like: next, agree, next, next, install etc (or simple click middle button as long as you can, deselect readme file at the last page) then i guess it doesn't work - i tested 0.80.0, current one, some previous from http://buildbot.eat-peet.net/spring/installer/ and most of time (if not all the times) i was getting 1024x768... and the same after uninstalling them

oh, and i forgot about ArchiveMover

• can it check if source == destination - sometimes i run it on some files already in maps/mod folder and it renames file
• checking if source and destinations files are same (different locations - 1st size then (if matches) content) can be also useful - it would prevent dupllicates

working with few installations can be annoying without it, if you are using AM (i'm not always sure which executable handles files) instead of ctrl+c, ctrl+v.


[EDIT]
noticed imbaczek's reply when submitting - no need to quote it again - i just didn't want to erase top half part of post if i had nothing to add i'd not simply post it

Texture-binding issue is still not resolved. Multitexturing causes huge problems. See here for details and a test environment.

That's caused by a bug in XTA itself, see viewtopic.php?f=48&t=19644.



Textures should be back to normal now.

Not exactly "normal" yet:

The Unit on the right does not have a normalmap, and should be rendering normally. And look at those ground plates, lol!

I add another normalmapped Unit, and everything in the game inherits that Unit's texture.

I'll test again when Buildbot shows a new compile.

Between 0.80.0 and 0.80.1, the offset used to place gl.Text changed.

This wreck all my tooltips, all my menus, ...

Please revert to previous gl.Text positioning.

0.80.0

0.80.1

Difference between 0.80.0 and 0.80.1

Exemple of ingame GUI being wrecked by this bug

we already explained this to you.
most of them are DLLs, which cant be moved. for explanation, see the other place where we explained it (forgot where, but it was your topic, so you should know).

as i understood from discussions in the lobby, it was planned ot have a nother RC before the release (that was yesterday). but as it is presented here, this is a release (no RC). i think think that is not good, it should rather be an RC.

I'm no supergeek but I don't see why they can't be moved? I understand that you can't just move them because Spring only looks in the main Spring folder for those files. You'd just have to tell it where to look right?

No, see the other thread.

And what about doing like a "bin" directory where you put the executable and all related stuff? Just having the lobbies and maybe singleplayer frontends later on in Spring's main directory probably will solve some noob traps...