Linux Server Hosting

I believe server manager doesn't work because it can't change the names of the server windows under WINE. I changed my server back to Windows because I wanted to be able to use server manager again.

?????????? 

Is it possible to contact who ever runs QT  ? : describe the problem and ask what can be done. 
If the issue is on QT side, you cannot do anything from your side...

toadlife wrote:

I believe server manager doesn't work because it can't change the names of the server windows under WINE. I changed my server back to Windows because I wanted to be able to use server manager again.

 

Actually I read through the server manager's source code and followed its operation and this is not the reason it doesn't work. The manager already fails before getting to the step of renaming the window.
The underlying issue is that after creating the server process, the manager calls WaitForInputIdle on that process with a timeout of 10 seconds. This means that the manager waits for the server process to say it is done initializing, aka idle, after which the manager proceeds with patching, renaming and running the server config. For whatever reason the server process actually never reports an idle state, so the 10 second timer runs out and the manager deems the start-up as having failed.
This step could easily be avoided by replacing the wait function with a fixed timer, but I have no promises on the fact that the manager wouldn't still fail at a later point.
The idle timer not working under WINE clearly is because of some technical differences in how the server runs under WINE and WINE's implementation of the Windows functions. Perhaps - and I am purely guessing here - it would be possible to fix this issue if it could be traced back to an emulated DLL for example. Then replacing that DLL with a native windows DLL could fix the issue.
I am currently investigating re-writing a similar manager that would run native under linux, as all of the manager's functions (memory addressing, command sending, UDP querying and TCP server for remote control) are easy to write under linux and I have already gotten the maxclients patch and UDP query working.
Reading player data (specifically their IPs) through the memory is not as straight forward though, but I don't even think this is my code's problem - when following the exact same addresses as the manager, about 1 out of 7 times when a player connects, their name is missing its first character. This is evident in the process memory when browsing it; the first character is simply not present at all.
I predict this bug actually exists in the server manager as well but goes unnoticed as the manager mostly only deals with data received via UDP - which does not suffer from this issue. The only reason to read player names from memory is in order to connect them with the corresponding IP address as there is absolutely no other way of retreiving player IPs in a H&D2 server otherwise, making IP banning impossible without memory hacking.

you want to create GUI based server manager or a console app ?

Did you use pointer scan to get correct addresses for names ?

My search results display it correctly.
 

Stern wrote:

you want to create GUI based server manager or a console app ?

Did you use pointer scan to get correct addresses for names ?

My search results display it correctly.
 

Either, really. Currently at a very early stage so obviously not really bothering with a GUI yet as I barely have any functionality anyway. I suppose if this ever becomes "anything real" it would be optimal for it to be able to do both.
Pointer scan? I am not familiar at all with memory hacking and the terminology that comes with it, but this is how my code works (I mimicked exactly what the server manager does):
Read 4 bytes from address 0x9D6A50 to get the memory address from which the player list starts.
Then read 32 192-byte long blocks starting from the previously read address. Player name starts at address + 192 × id + 8, player IP is stored at address + 192 × id + 4, in four consequtive bytes.
The IP address reading works flawlessly every time, but as I said, about 1 out of 7 reconnects ends up having the name missing its first character in the list. The IP is still correct. Another reconnect typically fixes the issue.