Firstly, I would like to read what it is your referencing... so a reference would be nice. secondly, I direct you to a quote on this thread "I'd like to remind people that I intended this as discussion about potential solutions... It seems that some people are more focused on feeling good about telling people they are wrong." I of course care what has been said by the developers but I am more interested in starting a discussion about potential solutions... simply saying no because developers said so isn't talking about how to make it work. --- Post updated --- Are you suggesting that it would be impossible to take a general direction from all the nodes to be used in simulating a much simpler object on another client, for the sake of being less server intensive? --- Post updated --- ... very productive, please read the first post before contributing nothing to the conversation. --- Post updated --- I did search for threads discussing solutions to the problems. perhaps I didn't search well enough but I didn't see a thread talking about solutions really. I'm not interested in whether my ideas are new are not. After all, we all stand on the shoulders of giants when it comes to this stuff. I am interested in starting a dialogue about possible solutions to the problems. Please explain the flaws in the ideas I've proposed so that they might be improved upon, hence making progress on a solution. Thanks --- Post updated --- If you believe it to be the only way, it is still a way. Care to talk a little about the methods of optimization going through your mind? Perhaps then we can find a solution. --- Post updated --- If you believe it to be the only way, it is still a way. Care to talk a little about methods Interesting, I've not heard of the program. would it allow for the rendering of two different perspectives or only remote access for a second hot seat player?
*sniffs* https://wiki.beamng.com/BeamNG_FAQ#Is_multiplayer_planned.3F Is multiplayer planned? Networked multiplayer wasn't originally planned. We are aware that it's a highly requested feature, but may be impossible or highly difficult to implement properly, given our physics engine complexity. We are keeping an eye on it, but no promises here. It will most probably not happen in the short term. Non-networked multiplayer is available, and is called "multiseat". See #How can I play with multiseat? answer.
No it's definitely not impossible, but perhaps pointless? Turning BeamNG into a multiplayer experience comes with a few presumptions from the community. What's the first thing you think people will do when they find out BeamNG has multiplayer? I'm guessing some variation of a death race, chicken race whatever. Something involving a crash. In fact crashes has been the main selling point for this game all along. And you're suggesting that it's a valid sacrifice for multiplayer to cut out interactive crashes completely? If you wan't multiplayer so bad you're willing to give up that, you might as well just play another game all together.
Well, would say that because others 50-100 threads do the same thing as you do: Multiplayer plsssss... Also, if it would, the game would we VERY unstable. Because Physics. Beamng has one thing, approch to real life, to make it cool If multiplayer planned, it would need a downgrade of physics, graphics and other stuff... You want multiplayer? Fine. Just play Rigs of Rods!
I'm not a computer wiz, so sorry if this isn't a solution, but if nobody has noticed, this guy, @zorilya actually knows (Atleast IMO) what he's talking about, exept for all the other threads that are around. He didn't just whip up a thread asking for multiplayer in a minute, he actually tried and, I'm hoping, researched his heart out, knowing what these forums are like. He has made that account since 2014, so just because he hasn't messaged a lot, does that really mean he should be picked out like this? Nobody gives people a chance anymore. I'm not saying anything else, just wanted to have some people think for once, instead of saying No...
Please. Tell me how many data points are sent in a regular racing game from one player to another and at what rate they're calculated Now tell me how many beamng has and at what rate they're calculated. The simple solution for beamng is only send the ref nodes positions and orientations but this leads to rapid desynchronization of the mesh states as the rest of the mesh is calculated clientside at a different rate once you factor in network update rate versus game physics rate and latency. So you send the full skeleton. Theres a few thousand points of data there. No chance
I see a couple things for the data over buffer problem and being able to calculate nodes - Server hosted; if Dev say, imaginary, made a second front end loader with the physics engine (so BeamNG_Multi say) The catch is front end network dependent with a slimed version of BeamNG
Wut, synced damage is possible if the code is efficiently written, you can make it so it sends over the beam length when it changes a certain percentage and set the same beam length on the other side upon arrival of the data. Only thing holding it back is that beamng resets its vehicles if you rotate them via lua. How does one move the car?, beamng has a nice build in function for that. How laggy is this?, not look at that beam Regen thing what it does is set all the beam lengths to original length. Why haven't I done this in my mp, because I'm a lazy.
The problem with multiplayer in BeamNg is that networks aren't really built to handle the massive information transfer BeamNg's physics engine uses. Let's say an average car has 10,000 nodes, and the server only needs to keep track of and send node position data to every other client (this is stupid simple and would require a lot more overhead if multiplayer was to be good). Let's say each node's position is stored in a 3D Vector of X, Y, and Z double precision values. A double prevision value requires 8 bytes of memory, so each node alone takes up 24 bytes. multiply that by 10,000 nodes and you have to send 240,000 bytes every update, and that's only for 1 other vehicle. That's 240KB. Now send that 240KB of data every 10ms for a 100/s server refresh rate. Now you have to transfer 24,000 KB per second for just one vehicle, or 24 MB/s. Most home connections outside of 1 Gb connections can't handle that volume of data.
You don't need to send every node position, you need to do send the beamlenghts only after the beam has changed a certain percentage and you need to send over the vehicle position. On the other end it will receive the new position and rotation and which beam to bend and how long.
That's a good optimization I didn't really think of. So only suspension and drivetrain components will need to be constantly simulated. Chassis and body parts only need to be updated in the event of, say, a crash.
I understand the fact that the game, is very graphics intense. so can accept that multi might not be possible. Honestly i'd love to get friends together and crawl Crawl central all day, but at least we don't have dick players wrecking everyone without recourse
This is the kind of system I can imagine for LAN multiplayer. You wouldn't be able to run the multiplayer on anything 100 Mbit, but for those with Gigabit NICs and setups it would work. Online, again, is impossible unless multiplayer had completely gutted physics.
I agree that having no crashes would kill the idea of the game for most folks. I have been trying to engage people in conversation about solutions to that very problem. --- Post updated --- I appreciate that someone appears to have read my original post and saw that it wasn't a hollow rant about a lack of multiplayer. Thank you Daniel --- Post updated --- Great ideas. If i get your meaning thought, would it not be best to leave all the simulation to the client that owns the vehicle and just have the vehicle state updated over the network? Obviously the position and orientation of the vehicle (once calculated client side) is the thing that needs most frequent updating to sell the look of another vehicle being present in the game session. Other, less crucial aspects of the vehicle state would be updated less periodically or as you suggested, on a particular event trigger. Perhaps a priority list of important aspects to be updated, in descending order, would look something like: *Position/orientation - Highest update frequency *Wheels and Environment effects (Tracks and skid marks made etc.) - High update frequency *Beam length changes - Event based (Effectively low) If the unsimulated version of client 2's vehicle mesh on client 1 was to be manipulated with a basic position/orientation update over the network, say... by client 2 sending information from 2 key nodes (front and rear axle?), client 1 could extrapolate the position of all other nodes, relative to the two nodes that have been updated. This would mean (according to your maths) the network updates that are the most crucial (position/orientation of the vehicle) would be reduced to 48bytes. 4kb per second for the 100ms server refresh. That could be manageable right?
Also, if the dev says no, the dev says no. Creating so many threads for this is NOT gonna change the dev's responce. So stop creating threads for this. There will be NO MULTIPLAYER! Again, if you want multiplayer in the same type of game, play Rigs of Rods!
As far as I understand, It was stated that it wasn't planned and that it would be a significant challenge considering the physics simulation in game. That is not "There will be NO MULTIPLAYER!" To discuss and pose solutions to the challenges is, at the very least a health exercise in problem solving, and at most, the inspiration someone might require to actually implement such a thing. I truly don't understand the folks that want to shut down Ideas like this. It's not like it gets in the way of your life... Forums threads are pretty easy to ignore if your not interested in the subject. Just don't click on it. You are using your time and effort here, which indicates that you care about what we are saying, but since it's not in support I must ask this. What, in what we are saying, is so important that if left without resistance would cause you harm? or in slightly less specific terms, Why do you care so much as to dissuade people from even talking about the idea? Your actions speak for themselves so there must be a reason.
You guys are majorly over complicating this Have you looked at replay files? They are TINY for what kind of data is being put into them. The devs have the capability to get vehicle data, in realtime, into those files. Imagine streaming that through the internet. Doesn't seem like a big deal now, does it? Except we have "refnodes", which give us the following functions: Code: obj:getPosition() obj:getVelocity() obj:getRotation() Which , if you only want position / velocity / rotation. These will give you that. It's not confirmed nor denied.
Ok maybe I could contribute at least a bit to the topic. You may could also use the multisession system. How? You could transfer only the control inputs to the server and then they get globally executed on all clients like virtual controllers. The client who sends the data does not directly execute the inputs, rather the game waits like for the others clients for the server. In a nutshell all clients should be synced. Benifits? You only need to transmit and receive a handful data. All the calculation is done by each individual client. Notice: This is only a new idea, not a complete applicable conzept! There are also a lot of things to look out for too, like different framerates and so on... The point is, at least for my opinion, to give new ideas for a multiplayer, rather than to work out how we can apply other multiplayer architectures on BeamNG. Always remember: nothing is impossible!
That's great but if optimization can be done, why not do it? I did imagine the data wouldn't be hard to get. Can anyone point me in the direction of some references for the language used in this game... is it lua? --- Post updated --- If I understand you correctly, Input is the one thing that you need to feel snappy. I feel like having input sent over the network before being executed and waiting for the round trip for results to show, is just going to feel sluggish. I believe there is a Hybrid method used in some games which shows the user the local executed effects of controller input and then the Server periodically checks if both client and server "Agree" as to where the player is and what they are doing. This solves the input lag issue, (atleast to a good standard). I was proposing that the client be more in control of the game state on this occasion. That comes with an obvious downside of hackers easily being able to define what is going on and the server not being able to say otherwise. Would there be some kind of possibility of a basic continuity check, similar to a block chain ledger? If (check state is drastically different from last check state) { Interpolate possible new state from last check state; } That kind of thing? But I suppose I am getting ahead of myself here. Perhaps a working concept of over network control before network continuity is considered to that extent
