SL showing I do not have mod after I exit a game

[malric]

I know that reload maps/mods does not work but this seems a bit different.

Start SL, join battle (springie, XTA), play, exit battle, now in the list it shows I do not have XTA (for same host!).

Is the only solution to restart after each game played?

What is the root cause of the problem? As a workaround, will the server accept me if SL will not do any check (I assume I can disable the check in the code) ?

[Beherith]

If you are on windows, you might want to try TASClient. Make sure you are up to date with SL and spring .85

[Licho]

Use zero-k lobby or tasclient until SL is fixed.

It will be like that on all springie-type autohosts.

[koshi]

You make it sound as if SL has a bug because we haven't implemented the protocol abuse you're trying to force on everyone.
I have no intention of getting into a position again where a certain lobby makes unilateral changes and we're starting to play catch-up in SL. And no, "announcing" the change only makes it marginally better.

[Licho]

We talked about it like year ago and SL actually implemented it.

The implementation is buggy. Its a simple one word fix in the code.

For the user the answer is simple - use other lobbies for now or learn to live with fake desync. SL is not exactly fast at implementing common features.. after 3 years - where is the rapid?

[koshi]

Good job on ignoring my point and deflecting to something completely unrelated to lobby protocol.

Even if there was an implementation, which I at least cannot remember agreeing to, what I guess you're referring to was committed 19 months ago. (Nevermind that it was a solution to a problem I had with simpleinterface) Suddenly you couldn't wait anymore? Your request for implementation was made official 3 weeks ago.
Was it that after satirik added it in tasclient that you figured you could now get away with, putting it mildly, inconveniencing every SL user on your springies? I really don't get it. Your bottom line is if you don't force the change upon us, via pressure from users, it won't happen?

[Licho]

I asked for it to be fixed about 8x in #sy and several times personally BrainDamage - just in the past few weeks.
I also made a ticket and Abma made a SL patch.

There was no specific response from SL devs.. it felt like poking a dead animal..

Last week, autohost which would host dev branch of spring was requested and it needed a way to get away without engine-dependent content hashes.
Thats why the regime changed.

[malric]

I am using primarily Linux so as far as I know springlobby is the only option.

Licho, could you please tell me the ticket number? I would like to apply the patch and check if it is working.

If this disagreement is so fundamental that it can not be fixed, I think it would be much better (if possible) that springlobby just hides springie autohosts, and avoid all the confusion to the Linux users.

[Licho]

Note that springie autohost = all non BA autohosts..

Here is the commit:

https://github.com/abma/springlobby/com ... b8f88fff69

The commit is ok, problem is the double negation
instead of if ( !m_host_map.hash!=0 )
there should be if ( m_host_map.hash!=0 )

and instead of if ( !m_host_mod.hash!=0 )
there should be if ( m_host_mod.hash!=0 )


Actually if this is live we could jsut set hashes to 1 instead of 0 and it should work..

[malric]

The commit as it is does not work.

With your suggested modification it does not even compile (error: ambiguous overload for ‘operator!=’)

Can you please (any of you) give a reference to the previous discussion/commit that broke this in springie/any other info that I can use to understand the problem?

Seems multiple people are affected by this (in the games last night, 2-3 people needed always to explain others that they should force start).

[Licho]

Then use map_hash != "0"

basically you can only compare map and mod hash if its not 0

thats all..

[koshi]

You're referring to this ticket that makes no mention of hashes?

Then there's a commit that obviously hasn't been tested, nor compiled and for which there's no pull request.

Seriously, no matter what straws you pick next, in my opinion it's still a dick move to set this live with the full knowledge it would fuck SL users over.

[Licho]

Its not a major problem for SL users. There is an exception in Springie that lets it start even if SL people are desynced.

The ticket made for hashes is very old coudlnt find it.

[malric]

Then use map_hash != "0"

basically you can only compare map and mod hash if its not 0

thats all..

Ok, this seems useful information. It is better for everybody to explain than to point to untested patches.

Also, it seems there is no ticket about this. Can create one if this fix works.

[det]

Here is a working patch http://projects.springlobby.info/issues/1646

[SirMaverick]

Here is a working patch http://projects.springlobby.info/issues/1646

Works nice, thanks.

[abma]

i know that my patch didn't work but didn't fix it, because BD said, he will do it...

thanks det for implementing it + please apply the patch @springlobby-devs.

[se5a]

why is this still not out?

I seem to remmeber SL wanting to update nearly ever freeking day at one point, now when there's actualy a decent bug which has been fixed... there's nothing?

[koshi]

How I love people like you who are apparently incapable of reading and understanding threads. Really makes this place a fun place to be. Also _really_ encourages me to hurry up with anything.

[se5a]

actualy it reads like you're not doing anything just because you've got your pantys in a twist, and are too busy balathering from your soapbox.