Cpp

The server MUST compute everyone. Who else would do that? clients? But then people could be able to modify the client so that it would do unfair movements and stuff like that. Server is the main database of all players, their positions, destinations, everything. It computes everything and sends the needed data to client. I think when server gets a new player destination, it computes where the player should go next, that is how to rotate and in what direction to go (1 square at a time), all that using some pathfinding algorithm. It then sends that data to the clients. The whole system works like this basically: server is the main core of the game, it does all the calculations and sends the data to all clients that need it. Client, on the other hand, only sends modified user input. Nothing more. If the clients would do the pathfiding part and send the results to the server, a client with modified map file could go through hills and buildings. So to answer your question "which packet sent to server describe those values?" i have to say, MOVE_TO. It gives all the needed information to the server to calculate the movements and rotations of the player. MOVE_TO sends to the server the end of movement vector (the destination) and the server already has the beggining of the vector (current player position). Thats all what is needed. P.S. sorry for a long post to say such a simple thing. I seem to like writing alot

Well, it sends me straight to http://imageshack.us/ :-/ Probably because there is ℑ character in the link

The link is broken... try this. Sorry for not being able to help more.

I havent got time yet to make this a reality, but i have an idea. In my opinion resync should be considered a hack. Well ok, its the most reliable way of doing this, but still... I say lets make a client side resync. It would be activated just like normal resyncs are, but, instead of discarding all actors and their commands, it would just calculate the new positions of actors by executing commands without any frames. So, first execute the frames that are already in progress (such as walking/fighting/turning frames). Then execute the following commands without changing the frames that are not needed, and just discarding some of the messages. Use move commands to calculate the current actor place, sit/stand commands, fight and other commands to find its current state. I will probably try to do that, but as i do not know much about how the fighting, dieing and other states are used, i may need some help or something If you think that some problems may arrise with that, let me know so that i wouldnt be working for nothing, but i can't think of any reason why this would be impossible or bad to implement. Of course i could add an option in ini file to set this "resync immitation" mode.

DirectX 1.0 is a total shit from what i know. Actually anything before DirectX 6.0 is worse than OpneGL. I believe that DX 8 or even 9 would speed up things pretty much. But yea, it would be a nightmare to reprogramm everything to use DirectX. Also it only works on Windows good. But using DX AND OpenGL? There is totally no reason to use both of them from what i know (at the same time).

Well, it seems to work without any nasty artifacts, but i didnt have much time to test it more. Of course it is very hard to test if it actually helps alot. One things is certain - it sure negates SOME resyncs. I got at least 6 situations where it would have been a resync, but longer que saved me. Once been only 2 messages far from a resync (30 message que, 29th resyncs), lol.

If i got it right, in your post "the mailman" was server and "checking the mail" meant getting the message from server. Then it looks correct, but there is one problem with your explanation. Lets say that you are getting the mail every day. Then when you get a package, you read it, but do not do anything about it just yet if it tells you to pay your bills (because you are used to paying your bills at friday). Now what you do is place that bill to a que and wait for friday. If you get a bill when there are already 8 bills in a que, your head explodes. Now if you are alive at friday, you get those bills paid. The same in programmer style (how its done in EL): main loop { many times { Get the messages somewhere in draw_scene() (lets say we get em right after they come); Process it: If its an actor command, add it to the que, unless the que is full. If it is, resync; } <Other work that produce some delay>; Execute the commands; } Actually i think the client only executes one or so command for each actor at the end (actually start, but whats the difference?) of the loop. One thing certain: not all of em. Even if it did empty the que at the end of each loop, it is still possible that we get 9 messages for one actor before emptying the que. Yes, its true that it is impossible to create such spam, but due to lagg the messages may come too late and all at once. What i suggest is get rid of the message reading in draw_scene() to make it cleaner and maybe even get all the messages just before emptying the que. In other words, stop running to your mailbox every day. Instead, go get all the mail at friday. You may also want to get more patience so that you could hold more bills in the que. That way your head would not expload so often.

Its in main.c in my coppy (last released patch code i think) while( SDL_PollEvent( &event ) ) { done = HandleEvent(&event); } //advance the clock cur_time = SDL_GetTicks(); //check for network data get_message_from_server(); BUT get_message_from_server() is also all over the code in draw_scene() (its commented that it reduces resyncs)

Is that really possible? I mean what i'm talking about here is to make it like 3 times bigger or so... Currently it can only hold 10 commands. With a bit more lag it gets stuffed quickely. Increasing it to 30 commands should make it much better. I'm just hoping that giving the client more time to empty the que should help. Yea, i know that. But resyncs are done when you are adding the commands! I have one question here: if a message comes, will the next message be able to come before we read the last one? If yes, then lets just read all the messages we have before emptying the que (before HandleEvent()). That way there would be no annoying get_message_from_server() calls in draw_scene(). If, of course, i'm not terribly wrong with something.

Ok, many people have noticed that resyncs are getting really annoying. So i thought i'd look at the code... From what i have understood they are done whether some character gets more than 8 commands in their que. So increasing that number (and the que size) should make it better, right? Also what are those really annoying get_message_from_server() doing in draw_scene()? I thought resyncs are triggered from a function that is only ran from em AND ques are emptied (executed) only in event loop which is outside of draw_scene(). So then how can that message getting everywhere help reduce resyncs ? What i think would help would be speeding up the execution of commands of that actor that has too many messages in the que (but if he does have too many messages, still keep adding em unless the que is really full, and only then do resync). That way the que would get empty quicker. If i understand it correctly, walking commands are the ones that really make the que full... Speeding command execution should not make it look too bad. Of course we could get away without speeding it up, but the que size should really get bigger (maybe using another way of storing commands - linked list - would also be an option so that it would not require too much space. Or maybe set the que size in el.ini?) Please correct me if i'm wrong at anything and tell me what do you think about it. Something should be done to reduce those resyncs.

But will the other person get exp if you flee? If yes, its still free exp...

Umm, how do you expect people to do massive production with this system? You would probably need someone with 100 emu do the running or else everything would cost much. Higher level players with second characters for hauling with 100 emu? Sounds funny. Just thinking how it can change things... Aside from that, it's a pretty good idea.

I have played Rubies of eventide and the death system there is pretty good imo. If you die you can either lie there and wait or return to temple where you will be resurected. If you coose to lie some other player can come and resurrect you or carry you to the temple (you dont loose your stuff this way). After being resurected you get a death penalty which makes you loose some stats untill you pay a fee of experience (some percentage of exp you got automatically goes to paying the fee). How much stats you loose depends on the way you are ressurected. If at temple, its 5% and if by player, its less. Percentage adds up if you die again before getting rid of the penalty. Some more tales about loosing stuff: If you choose to be teleported to the temple you drop all unprotected items (you can [un]protect your items at some places) but it is only takable by you for some time, after that its everyone's loot. Resurection: Several spells that differs in time when you can ressurect the player, death penalty and ressurected state (a player ressurected by necromancer is a zombie i think ^^^^^ Just a description of another game death system ^^^^^

Yea, that should be possible. It would probably be something like an additional "protocol" with event data. However, this would make the record file larger and input may flicker. I think i should reprogramm the replay/record stuff a bit so that you could record while replaying. That way you could make a big record with only server commands and later break it to smaller files with player input (except typing, i suppose). You could also make the record with player input at once. The only problem is that I also have no time now

Umm, do you imagine a place where all player items are held (storage)? Well, i think that the items MUST loose the weight, or else we would have a storage limited by weight, not different items. And yes, it would require the change to float, and thats pretty problematic.