91.0 problem

[cleanrock]

Not sure if to post this on SL or here. I noticed that if you have the 91.0 pr-d downloaded engine with archive support in pr-d SL and flobby crashes/hangs. Just try some usage of pr-d downloaded 91.0 engine in SL and i bet you will see hangs and crashes, at least on 64-bit linux.

[abma]

spring 91.0 unitsync is broken, nothing to fix here

[abma]

FYI, this should have fixed this specific crash:

https://github.com/spring/spring/commit/078565f335eb0b5680bc8fcdd029da7a67de3555

[cleanrock]

I must say its odd that you ignore this SL problem, SL is pretty useless for playing zk atm on linux i guess.

[abma]

zero-k just has to use an up-to date spring version. i dislike to care about VERY old versions of spring, sorry. 91.0 has no static builds, the build(s) provided are self-made and they still require many external libs. if you want to fix this problem, create a static build with the patch which disables threading for unitsync.

[cleanrock]

I know how to fix it for flobby but i think SL should support zk atm. I posted this to let you know SL have a problem with zk on linux.

[abma]

"I know how to fix it for flobby" .... how?

afaik unitsync crashes somewhere in Init()...

[cleanrock]

My plan is to use external pr-downloader (process), i recently added pr-d statically linked but i think i will skip it and go the "unix way". It will be more of a hassle for flobby users but it is clean. I also want to launch pr-d process to avoid the problem that archive is not updated on every download attempt, this is a problem when a new zk test version is released after you started flobby. I was about to talk to you about this but it wont be a problem if i start pr-d in a process each time i try to download something. I am pretty sure you will see this problem in SL also.

[abma]

then i didn't understand your problem, can't reproduce. pr-downloader --download-engine 91.0 works fine for me.

please give gdb stacktrace at least.

springlobby hangs/crashes when it tries to load 91.0 unitsync! pr-downloader doesn't hang/crash.

[cleanrock]

Running pr-d as a separate process is fine, try the corresponding thing with SL and think you will see the problem.

[abma]

you don't understand. 91.0 unitsync is broken!

springlobby downloads 91.0, then extracts it. when extraction is done, it loads unitsync. because 91.0 unitsync is broken springlobby hangs/crashes.

[abma]

side node: "use external pr-downloader (process)" won't solve this

[cleanrock]

I am pretty sure SL is broken for linux zk users downloading static 91.0 engine, try it, that is what you should investigate,

[abma]

I am pretty sure SL is broken:

wrong, 91.0 unitsync is broken! provide more details if you are sure springlobby is broken. i already gave https://github.com/spring/spring/commit/078565f335eb0b5680bc8fcdd029da7a67de3555 as reference

[cleanrock]

I dont doubt 91.0 unitsync is broken but i think you want SL linux users to be able to play zk atm if they download 91.0 via SL.

[abma]

then what do you suggest as workarround for the broken unitsync which is acceptable?

imo thats a waste of time because zk really tries to switch to a current engine. you should have made this report ~two years ago.

[abma]

still: if you want to fix this problem, provide a build of spring 91.0 with the patch applied. but please don't waste your time in fixing in 91.0. fixing blocking bugs of 98.0 should be our priority. see http://springrts.com/mantis/roadmap_page.php

[cleanrock]

I recently saw this problem when trying out SL. Since i did not see problem reports i thought it was a local problem of mine but when i investigated this today i realized more ppl than me may see this issue. I suggest you talk to the person who made the 91.0 static build available via pr-d to solve this issue (if it is worth the effort).

[abma]

fyi: springweblobby has a bad hack to workarround this. afaik they use a different unitsync version... idk who made the 91.0 static build. also spring 91.0 doesn't work for me at all because of bugs in spring with invalid opengl usage, i expect others to suffer from this bug as well, so imo not worth the trouble to fix spring 91.0 unitsync.

the problem is: zero-k still uses spring 91.0, that has to be fixed!

[db81]

weblobby uses 96.0 unitsync instead of 91.0. So far it hasn't caused any problems, knock on wood.

[abma]

i regret to add such a hack:

https://code.google.com/p/springweblobby/source/browse/branches/qtcpp/site/lwidgets/BattleRoom.js#189

sync check possible is broken with it. also zero-k lobby moves towards 97+, so why spent any time into this?

[db81]

Back in the middle of April it wasn't quite as clear that zk would finally be switching engines, and it was crashing a lot. Sync check works somehow, but I'll be happy once I can get rid of that hack.

[db81]

Actually, I was wrong, checksum sync is indeed broken, but since springie sets hashes to 0 it doesn't manifest.