At the moment, Alphalobby keeps track of renames and puts the old name in parenthesis. It doesn't work if someone makes a new account though

EDIT:
I've thought a little longer on this and you have a point, but just because you use cpu field to identify players doesn't mean it is the best way to detect smurfs. Its a hack.
You get false negatives and false positives. And it forces you to remember flag+cpu combinations because its not precise enough for the lobby to do for you.

Using cpu to identify lobbies is a hack too; but for smurf detection, tracking user ids is a much better solution.
From my experience, the "new username every week" players aren't actually smurfing since they have their usual rank and user ID. Since they have the same user ID, I can easily display their old username. And when I display someones old username, its guaranteed to be correct.
I can't identify second accounts like this but renames is 95% of cases anyway.

Sounds pretty much like what !smurfs does on autohosts, except that they have much more userdata collected than what a typical client will have. It's not completely effective.

flag+cpu is used because it's still the most reliable way, it gives some false negatives but otherwise fine(if you have good memory). Userids change when you create a new account and most infamous smurfs will create new accounts when their account becomes too well-known.

They best way would probably be to make the account creation process more difficult and time-consuming to deter people from creating new ones all the time. And also limit the amount of renames per month to 1.

0.02 wont launch on win7 x64 or winxp sp3 x86 , running the debug throws the following error on both:
The procedure entry point Init@8 could not be located in the dll unitsync.dll
Edit:
win7:


winxp:

@Cheesecan
very important rules in engineering:

• optimze only when required
• optimze first what is most limiting

with a protocol that is already in use by many parties, the first one is to be followed^10. the donators would not be happy by the community spending huge efforts and introducing tons of new bugs with no visible benefit at all.

First of all thanks.

Looks like the problem is with linking to unitsync, though I'm sure that is obvious to you.
Backtrace shows nothing as far as I can tell, which would be expected for a linking error.

I'm not entirely sure what to make of this tbh. Since other lobbies are working, I'm probably not linking correctly.

It does for me, without problems. Try dependency walker to inspect linking problems to DLLs. Maybe there are different versions of unitsync.dll around that export their functions with different names? DW does show function Init@8 in my unitsync.dll but it seems alphalobby only uses plain Init for me.

Surprisingly enough I actually agree with you xD, though I do think you are overestimating the time required adapt to a new protocol.

Network code is only a small part of each lobby. Yeah my lobby is little more than a toy, but of its 6000 SLOC, less than 1000 deal with the server.

Having said that, it isn't worth the effort if it only saves $100 or so year (yeah i picked that number right out of my arse) and it would inevitably result in bugs and downtime.

I also don't think that it's worth the trouble to remove strings from messages, but some changes such as renaming only once per month, could be implemented without affecting the protocol much. I don't like the idea of using CPU speed as a hack for lobby identification, as someone earlier pointed out it's used to detect smurfs, so by doing so you would break one of the few means we have to do that.

I've been looking through springlobby's source, it uses runtime linking instead of load time linking.
I don't know if this would any difference. I need to study up on dynamic linking.

And I don't think that there is any difference between Init@8 and Init, the decorated version is exported for C++ and the undecorated for C. Both would have the same entry point.

OK I'm pretty certain that the problem is that I'm relying on load-time linking. Export ordinals change with different versions of unitsync.dll, so Alphalobby is only working when its loading the same dll I compiled with.

Fix coming soon...

Are you sure alphalobby is importing unitsync functions by ordinal numbers instead of function names? According to DW it is importing by name. Beherith's error message implies the same. I dont think it would be a good move to import by ordinal.

This build uses runtime linking:
http://springfiles.com/system/files/downloads/alphalobby0.02-runtimelink.exe

I don't know if it will fix it, but its how springlobby links so maybe it will. At the very least it might give a better error message.

This isn't the only bug I've run in to, though the first release wasn't too bad, I ended up breaking a lot of things in the meantime.

from the lobby protocol doc XML:
at https://github.com/spring/LobbyProtocol ... n.xml#L299

and in TASServer source code i found this (from Betalord still):

Its pretty easy to get cpu freq. The only reason why I would use a static value would be to let lobbies be easily identified, as you seemed to be suggesting in an earlier post.

For now I'll just leave it as 0. I have more than enough stuff to do atm and this is kinda a low-priority.

Ok, that runtime build works on win7. Great work!

Thanks for helping me fix it.

works here too!

only gripe atm is i wish you could turn off sounds. Great work!

edit: another thing is that i dont have a bar i can type in on the main chat window, but i do have it in battleroom.

I share your distaste for sounds btw, but I haven't added any sound effects, so I don't know where they are coming from. Maybe windows is adding them automatically for clicks or something, in which case they probably use settings from control panel.


The main channel has a chat bar. I intentionally removed the chat bar from the official server because there isn't really sane thing to do with input. I guess it would handle "/ingame" etc, but you could do that anywhere.

alpha 0.02 is pretty buggy. I really only wanted to see if the linking issue was fixed; there are a few crashes and other stuff that simply doesn't work.

my lobby didnt join main by default on first run, so i had nowhere to type /j #whatever :)

and yes its some windows default sound, i have a temp windows theme on and it has sounds enabled. Don't get it with other lobbies tho, even with this theme


Very nice work btw, im probably using it as main as soon as i remember my passwords.

Next release will autojoin main, and support all the commands springlobby does.

I'm not opposed to adding a chatbox to the server window; but most commands could easily accessible in menus which has better discoverability.