1.5a Server

New server version. Same functionality as the last one, but IT WORKS, at least on my comp. LoY probably still broken. Moral of the story, test throughly before releasing...

/sigh 1.5a also busted.

http://alteria.sf.net/myseqserverc-1.5b.zip

Virgin 1.4 code plus the one tiny addition to make the moving mob lines work. Never have I seen the addition of minor error cehcking code case so much trouble...

LOL

Do you sleep ?

Dont burn yourself out !!!

I still can not see mto get this code to work me with 1.8 client or the 1.7b.

what does work still is the 1.4server and 1.7b client.

any thing else locks immediately after the spawnlist populates before it paints them to the map.

thanks for your hard work.

one more thing i was wonderong if it is possible to add an option to select the mob that you con.

after poking around with my modified debug version a bit more, I'm seing this much more too. I believe it's the same problem as the LoY zones, as it seems to hang up in the same place on ther server side (according to all the debug messages I am getting.)

(I would wager that this is also the same lockup problem I've been having intermitantly, regardless of zone. Although, those lockups are hard lockups where I have no control over the client and must end task.)

This should all be fixed shortly though. Going to a pull situation where the client asks for packets instead of getting flooding.

I think what's happening is you are actually sending the packets to the client sSO fast and furious that you are causing a DOS attack. hehe That's pretty much the anology and what it looks like... The client gets overrun, and just quits listening, or never sends the proper packet back to the server ACK'ing the recipt. (If it even is designed in such a way as to send ACK packets.)

I really do believe we are just flooding the client and it is drowning.

Mr. Doh

This is what is happening. I will post a test version shortly with a quick client request implementation. It seems to work better and it can if you want just run as fast as it can limited either by the client processor, network throughput or server output speed.

Just a thought about this...

Lemme know if it won't work, but there should be a "formula" that can be worked out that will.

You set how fast the server reads the memory updates. I see no usefull purpose on polling the server any more often than the server itself updates. Would it possible, (or even beneficial at all) for in one of the very initial packet exchanges, have the server send its update speed to the client, and let the client start with that poll the speed (this is where that formula comes in... maybe have to add a few ms for the server to get everyting updated before it sends it). Then, if the users wishes, they can modify the update time more to their liking. If 250ms is to fast to send the packets out (1/4 second shouldn't be too fast I wouldn't think) then what's the point of having the server read that fast. And if the client is set to update faster than the server, you are causing unnecisarry network traffic because nothing will have changed because there hasn't been an update. (read duplicate packets)

Just some thoughts,
Mr. Doh