Please add IPX protocol support becouse i can't connect trough tcp/ip
I have a broadband router which assigns ip's automaticaly so i don't know my or other comp's ip.
Idea for better high-latency multiplayer support
Moderator: OpenTTD Developers
Hmm, to give my two cents, it isn't very likely that the vehicle should get out of sync, so in general you don't need to send all data everytime.
If one byte is wrong, TCP doesn't send the full data stream ...
If you want to be really really proof the data didn't get desynced,
send a checksum for a block of 20 vehicles, and only if you get a desynced block you resync the data.
If one byte is wrong, TCP doesn't send the full data stream ...
If you want to be really really proof the data didn't get desynced,
send a checksum for a block of 20 vehicles, and only if you get a desynced block you resync the data.
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
You have an IP (simulated or no) where you can be reached, or you wouldn't be able to surf the net. You should be able to request what your IP is from the router.Killer 11 wrote:Please add IPX protocol support becouse i can't connect trough tcp/ip
I have a broadband router which assigns ip's automaticaly so i don't know my or other comp's ip.
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
And that's what I gonna do. Checksum check, wait every some number of ticks for master tick, and the like, and synch only what needs to be synchronized.eis_os wrote:Hmm, to give my two cents, it isn't very likely that the vehicle should get out of sync, so in general you don't need to send all data everytime.
If one byte is wrong, TCP doesn't send the full data stream ...
If you want to be really really proof the data didn't get desynced,
send a checksum for a block of 20 vehicles, and only if you get a desynced block you resync the data.
Guyver
You can play with tcp/ip on a local lan, all you need to do is set your ip's to LAN settings (192.168.x.x or 10.100.0.x). IPX works, but it's far from desirable...
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
Having a big server in the sky somewhere (OwenRudge.net of course!) is the right way to do it, for so many reasons. For one thing, it solves the reason I and many people I know can't use the new multiplayer code - because it doesn't work across firewalls. But if you had a server, all I would have to do at my end is type in the server IP address (or even the hostname, if you're slick about it) and I'm in, because your server can figure out my masked address in the same way as a website server would, and send and receive information as needed. This way I could play with someone else, when both of us are behind firewalls, by relaying via the server.
As far as the synching is concerned, as long as both games are using exactly the same Patch versions, Patch settings, and GRF files (which ought to be checked at startup, and reconciled if not), then I would think the server would only need to transmit "events" such as construction, industry, or economic events, and random events like disasters and breakdowns. It wouldn't need to transmit movements of vehicles, because those are calculated on a known set of rules, and as long as the rules are the same at each end, wouldn't the calculated movements be the same even without communicating them? I mean, like this:
Consider if you have a new train built. That's an event, so the purchase of the train, its type, location (which depot), cars, etc. need to be transmitted via the server.
Then the player clicks the button to start the train. That's an event also which needs to be transmitted.
Now the train is moving out of the depot. Why does this behavior need to be transmitted? The info on the train is exactly the same on all players, so wouldn't their respective TTD engines calculate the movement of the train in exactly the same way? So it wouldn't desync, because the calculations would be the same everywhere.
Then the train breaks down. That's a quasi random event, so it would need to be transmitted, so all the players' computers know to stop the train.
But for normal movement, I think you can do without the communication. There isn't any random element in the movement algorithms as far as I know, what appears to be random is actually based on the numerical ID of the vehicles, which would be the same everywhere.
As far as the synching is concerned, as long as both games are using exactly the same Patch versions, Patch settings, and GRF files (which ought to be checked at startup, and reconciled if not), then I would think the server would only need to transmit "events" such as construction, industry, or economic events, and random events like disasters and breakdowns. It wouldn't need to transmit movements of vehicles, because those are calculated on a known set of rules, and as long as the rules are the same at each end, wouldn't the calculated movements be the same even without communicating them? I mean, like this:
Consider if you have a new train built. That's an event, so the purchase of the train, its type, location (which depot), cars, etc. need to be transmitted via the server.
Then the player clicks the button to start the train. That's an event also which needs to be transmitted.
Now the train is moving out of the depot. Why does this behavior need to be transmitted? The info on the train is exactly the same on all players, so wouldn't their respective TTD engines calculate the movement of the train in exactly the same way? So it wouldn't desync, because the calculations would be the same everywhere.
Then the train breaks down. That's a quasi random event, so it would need to be transmitted, so all the players' computers know to stop the train.
But for normal movement, I think you can do without the communication. There isn't any random element in the movement algorithms as far as I know, what appears to be random is actually based on the numerical ID of the vehicles, which would be the same everywhere.
Development Projects Site:
http://www.as-st.com/ttd
Japan, American Transition, Planeset, and Project Generic Stations available there
http://www.as-st.com/ttd
Japan, American Transition, Planeset, and Project Generic Stations available there
It could just use ARPkrtaylor wrote:all I would have to do at my end is type in the server IP address (or even the hostname, if you're slick about it)
!Re: Random events. As it can be ensured that the psuedo random algorithms are the same on all machines, all you would need is to have the same initial seed, and all 'should' be fine (although things would probably go awry).
It must be ensured, however, that all machines are running at the same speed, so issue of syncing still exist. A timing singal could be sent out from the server, using some form of NTP server perhaps.
So you could send out just the human events, and a timing signal, and optionally any other 'resync' information (or a master frame). Not sure how much traffic just the human events would cause, but this way does try to minimise network traffic.
This sounds to me like a sensible scheme. I understand your point about "random" events being the same if you use the same seed, but I think it's safer just to transmit them. Really there aren't that many, industry productions changing, new industries, dying industries, and vehicle breakdowns. As far as different speeds of computers, does anyone know how that impacts the timing? Does it just take longer per "tick," or is there some other effect? Because if it just takes longer per tick, then you could have some sort of relation between ticks and realtime clock - that is, 1 tick = 10 ms, even if your computer can go faster than that. To find the lowest common denominator, in other words. And you still run the syncing command, so if one system gets ahead, it will pause for an instant to let the others catch up.
Development Projects Site:
http://www.as-st.com/ttd
Japan, American Transition, Planeset, and Project Generic Stations available there
http://www.as-st.com/ttd
Japan, American Transition, Planeset, and Project Generic Stations available there
krtaylor, that is already how ttd works right now.
unfortunately there can be timing problems with sending events (what happens if two players build a track on the same spot at the same time) and lag problems/packet loss that can cause desyncing.
also ttd uses synced random seeding, and this is how it detects that the games are desynced - a test random value is not the same.
perhaps some research could be done to see if less events need to be sent... otherwise this won't speed things up since it is already status quo
(thanks to patchman for explaining this)
unfortunately there can be timing problems with sending events (what happens if two players build a track on the same spot at the same time) and lag problems/packet loss that can cause desyncing.
also ttd uses synced random seeding, and this is how it detects that the games are desynced - a test random value is not the same.
perhaps some research could be done to see if less events need to be sent... otherwise this won't speed things up since it is already status quo
(thanks to patchman for explaining this)
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
That would have the same effect: slow gameplay, exactly the problem that's to be avoided...dJP wrote:Err... I'm no Networking Guru but, why not just slow down the game tick if there is network lag?
Wouldn't that eliminate the need for Teleporting trucks?
"Peace cannot be kept by force. It can only be achieved by understanding." - Albert Einstein
I don't have read the articles, but maybe someone else has the time:
http://www.gamedev.net/reference/list.a ... ryid=30#68
http://www.gamedev.net/reference/list.a ... ryid=30#68
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
that is one cool site...
will take me some time to sift through the huge amount of info though
will take me some time to sift through the huge amount of info though
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
What about a server version ?
A small exe centralises connections, generate ticks and take account of the update.
Client version is just sending actions to the server with the current tick, and display action the server send back.
So, we should be able to play online up to 8 player, also giving possibility to leave a party (your compagny become a computer one) or entering in a party while player are already playing. Should be great.
I'm not sure it would be very hard to do. The server version would be a simple connection pool with array of action to do at a tick. After all clients sent their actions (even if nothing), the server send it to the clients that will display it. When all clients leaves the server, it shunt down automatically. The AI/map can be managed by the client that launched the party, and then replicated to the other players, that should vote for the next clients that will manage the ai/map when first player leaves. I think it's the current way TTD works, but we add a server that centralise and broadcast actions of all players.
With that system, we should have :
- No need to pause the game while small desynchronisation
- Ability to play up to 8 players/ai (for ai, it should be necessary when a player leaves the party while other players wants to continue)
- Ability to enter a game that is already started.
What about it ?
A small exe centralises connections, generate ticks and take account of the update.
Client version is just sending actions to the server with the current tick, and display action the server send back.
So, we should be able to play online up to 8 player, also giving possibility to leave a party (your compagny become a computer one) or entering in a party while player are already playing. Should be great.
I'm not sure it would be very hard to do. The server version would be a simple connection pool with array of action to do at a tick. After all clients sent their actions (even if nothing), the server send it to the clients that will display it. When all clients leaves the server, it shunt down automatically. The AI/map can be managed by the client that launched the party, and then replicated to the other players, that should vote for the next clients that will manage the ai/map when first player leaves. I think it's the current way TTD works, but we add a server that centralise and broadcast actions of all players.
With that system, we should have :
- No need to pause the game while small desynchronisation
- Ability to play up to 8 players/ai (for ai, it should be necessary when a player leaves the party while other players wants to continue)
- Ability to enter a game that is already started.
What about it ?
Thuther more, while lag time, I think a right way to avoid slowing down the game should be :
-> Forbidden any action from users such as building tracks, actions on vehicules, and display a waiting icon instead of the cursor.
-> Each client continue to display vehicules running, and a correction about their real position will be done when synchronization come back. Some vehicule should have strange moves, but for most of theim, it will have no impact.
It's the was as RPG games such as Counter Strike, Quake and other handle lag. Other players have some strange moves, but the overall position is near to be thereal one, so it doesn't matter.
-> Forbidden any action from users such as building tracks, actions on vehicules, and display a waiting icon instead of the cursor.
-> Each client continue to display vehicules running, and a correction about their real position will be done when synchronization come back. Some vehicule should have strange moves, but for most of theim, it will have no impact.
It's the was as RPG games such as Counter Strike, Quake and other handle lag. Other players have some strange moves, but the overall position is near to be thereal one, so it doesn't matter.
If some stuff in TTD isn't synced anymore the random seed get broken, and A LOT other stuff gets desynced. This could be avoided if you create 10 or more Random seeds results, then use this seed for all clients. After a sucessfull resync you can make the next seeds...
Ohh, and to compare it to a Shooter, you have to consinder if the map would dynamical change what would then happen? And TTD is a game where mostly all Gameelements change...
Ohh, and to compare it to a Shooter, you have to consinder if the map would dynamical change what would then happen? And TTD is a game where mostly all Gameelements change...
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
MagicBuzz, that was exactly what we were talking about already.
Anyway, I think the checksum thing is a good idea, it should cut down transfers a lot.
And maybe even only transfer relevant things, like only the current screen gets synced to the server, the rest of the map gets synced when you get there..
Hmm, on second thought, that could create problems on income and stuff.
Anyway, I don't really like the thing patchman was talking about, using UDP to initiate the connection, negotiate about port and use TCP for communication. That would already mean that the game would use several ports instead of just one. And if I hate something in multiplayer games, it's when the use loads of ports(Worms3D for example
).
I don't really see the problem using UDP. If a packet does not arrive, that's too bad, happens all the time. Will get corrected in the next sync that does arrive. If that doesn't arrive again, the player probably should think about another Internet connection
Anyway, I think the checksum thing is a good idea, it should cut down transfers a lot.
And maybe even only transfer relevant things, like only the current screen gets synced to the server, the rest of the map gets synced when you get there..
Hmm, on second thought, that could create problems on income and stuff.
Anyway, I don't really like the thing patchman was talking about, using UDP to initiate the connection, negotiate about port and use TCP for communication. That would already mean that the game would use several ports instead of just one. And if I hate something in multiplayer games, it's when the use loads of ports(Worms3D for example
).I don't really see the problem using UDP. If a packet does not arrive, that's too bad, happens all the time. Will get corrected in the next sync that does arrive. If that doesn't arrive again, the player probably should think about another Internet connection
Protect the Banana
I think the whole multiplayer interface should be rethinked.eis_os wrote:If some stuff in TTD isn't synced anymore the random seed get broken, and A LOT other stuff gets desynced. This could be avoided if you create 10 or more Random seeds results, then use this seed for all clients. After a sucessfull resync you can make the next seeds...
Ohh, and to compare it to a Shooter, you have to consinder if the map would dynamical change what would then happen? And TTD is a game where mostly all Gameelements change...
Imagine.
A client is designed as "master".
It manage any change on the map (contruction, trees, etc.) Other clients doesn"t manage it att all.
Then the master generate next 5 ticks (by exemple).
And broadcast it to the server (a dedicated program).
The server manage ticks, and broadcast informations sent by the master to all the clients for each tick, and store the forecast of five ticks sents by the master.
Clients, even master, display only data sent by the server.
When a user do any change, (building, stoping vehicule, etc.) it send it with it's own tickID to the server. And the server relay it to the master with tickID + 10 (by exemple).
When the master recieve this change, it take it in account when generating the "tickID + 10".
For vehicule movements, each client can manage "simple movements" (runing front-away, climbing, stoping to a station, etc.).
However, master will manage heading change on crossways (because I think it is somewhat random isn't it ?), breakdown, loading, etc. with a forcast of 5 ticks (same as map managing)
Master disconnection.
If the master crash or anything else (conection become very poor etc.) game, the server assign role of master to the client that have the best connection. Master role transfert should be easy because all clients have information about evrything but 5 next ticks.
Server sends the next 5 ticks, and then when there is no more data, it sends to the new master the order to start managing map etc.
And then, all clients pause until the server recieves the new master's 5 first ticks informations.
With that way :
- Clients can experience game without problem even if they have a poor connection (they don't need to be synchronized, they can enjoy as much as 5 ticks of lag.
- Different users don't need to know IP of others computers, they just have to know the server's one (they just connect to it)
- Only the server needs to broadcast / recieve many information (it's the only one that need a high speed connection)
- The master also need a quite good connection because it recieves/sends a lot of data from/to the server. But it is less than if the master was brodcasting information to all players.
- With this way, when using a high speed connection server, we should be able to play up to xx (no limit ?
) players with ai and so on with no need of hight speed connection for all players.The only "bad" thing is that any action won't be instantaneously, we should wait for 10 ticks. But if current TTD tick is 27ms, 10x27ms is less that 1/3 second, so it's not a problem.
I don't have experience about network programming, but IO think it should be realisable.
Who is online
Users browsing this forum: No registered users and 10 guests