This is hypothetical and a bit of a read. It's mainly a suggestion, at best, and a flawed idea, at worst. The Beam engine has a lot of data. That's why it eats memory for breakfast. so. How could one send so much data over the internet? Simple. Node Groups. Let's be honest. how much important data would be sent over the internet if we sent node actions individually? not a lot. the unimportant nodes would swamp the network. this is why I propose node groups. All the nodes of a vehicle (minus wheels, and what hasn't broken off) could be grouped together into a single set of coordinates and quaternian rotation (quaternian to prevent weird flight due to gimbal lock) the wheels would simply be parented with additive rotation for the axle axis, and maybe one coordinate axis. with so little data being thrown over the network, how would you match up crashes? the simple answer is, slowly. the engine could locally handle the fine details of impacts in immediacy, before the vehicle host (the computer in control of the vehicle) sends its own crash data, and the other computer's engine corrects where the nodes are. If any part falls off of a car (or door latches pop), the nodes of that part could be packaged into a 'separate' node group, either parented to the vehicle, or un-parented. This could be worked to cover all the hinged parts, and even to cover when, say, a mighty wing is held onto a car by one or two node connections. Now while this kind of coding would be difficult, I do think it is possible. I could be wrong, however, so, I ask the devs, why would this not be possible? thanks for reading, if you could tell me why this can't be worked into the engine, or if this would work, that would be brilliant.
There is no reason why it "wouldn't" work... technically it would... Just figuring out how to put it into practice and getting the hardware to keep up with it is the tricky part... same as most methods. The way they used to do it (I think) back in the RoR days is that they would use the Reference node positions to position the vehicle in 3D space. Then they would send all of the node Coordinates in reference to the Reference nodes. Might be a bit inefficient, but it got the job done. I like the idea of using Quaternions to prevent gimbal lock... Got into that stuff in College for a robot we were building using an Oculus Rift... Ended up with some interesting looking math for sure. Plus Quaternion rotational coordinates can be transmitted very quickly... well... probably as quickly as normal rotational coordinates now that I think about it, but my professor seemed to be in love with these things and always ranted and raved about how compressible the signal was. Now, you mention node groups? You might need to go a little further in depth for me to wrap my head around exactly how that would work? Would there be multiple references to the multiple groups or what?
Well, the short and the sweet of it is a node group is a bunch of nodes, where their (approximate) coordinates are saved locally, relative to the parent coordinate. It's like having a bottle full of water on both computers, where only the bottle location/rotation needs to be transmitted, and what the water does can be inferred locally. The same thing twice should (at least mostly) provide the same result.
Sooo... What we are talking about here... from a BeamNG perspective... is we do nothing more than transmit the location and rotation of the individual groups of a Jbeam (like say each wheel, the body, and the frame as a few) off of a set of nodes used as a reference for each group. Then the computer does all the necessary computation for the necessary vehicle, almost like it was on your computer to begin with? That could work... but I think we could take that one step further if we were to do it that way. If just the reference nodes location and rotation were transmitted via the network and nothing else, in theory, you could run the full simulation of the vehicle on your computer while it is basically being controlled via another computer. If the location of the reference nodes becomes off some compared to the vehicle's reference nodes on the other end, then the locations of every node can be adjusted simultaneously. If all nodes have their position adjusted at once, theoretically there should be no extra momentum that could be accidently built up and it should work. This could also be done with your idea as well, except your idea would end up being far more accurate to what was happening on another persons computer... example, if they lose a bumper, so would the one on your computer as it is being tracked individually. Now, if I have understood your idea correctly, the downsides of both of these examples is the fact that the computer is required to run full calculations on both vehicles on both computers to end up with realistic deformations. This would end up causing a drastic drop in frame rate rather quickly.
This is true, however, this isn't really a problem. It's not really different from playing with a bunch of AIs.
Right, but a lot of people who play this game don't have computers that can handle more than 4 or 5 cars... up until recently, the best I could do was 3... that would make multiplayer a rather rough experience for all of us more than likely if we were simulating every car on every computer.
You mention this However, this would not work for intervehicle collisions as one vehicles damage relies upon the other vehicle which will not work unless it has the stream of nodes and beams is so consistent that its acts as if the other car is being simulated by your own computer rather than someone else's. As ATV said, its not a matter of it not working, many ideas would work. Its a matter of getting it to work to a point that the process would be flawless and polished enough to roll out to the community.
I don't care about some minor flaws, plus inter-vehicular collisions would be fine, as they're handled locally. As I said, same strain on your PC as multiple AIs. --- Post updated --- I'm not asking to race with 24 other players... just 7 at most. Heck with clever trickery and node deactivation, if you will, you probably could make 24 players work.
Ok sir, keep thinking that. You are not the first one to propose the idea of multiplayer without the skills or knowledge to actually carry it out. @Funky7Monkey Feel free to contribute at any moment.
Just go quote something I've said. These ideas may be useful later on, when the engine has been adjusted to accommodate multiplayer. As it stands, the engine simply can't do online or LAN multiplayer.
I'm not asking to race with 24 other players... just 7 at most Oh sir... I'm not gonna pull apart the game engine... Not yet. I still have college work to do. believe me, if I could, I would, but do I even really have access to the SRC?
Yes and no. You have access to the engine through lua, and all of the lua is readable. The engine itself is completely closed source.
I already know it's not gonna be surface level, and, a LUA script... well, any non-compiled extension, really, is gonna eat memory or processor time for breakfast. this needs to be more into the core of the engine. On top of this, I'm mostly asking a question, it's not as much a suggestion. the question being, "Hey devs. why is this a good/bad idea?" --- Post updated --- that's mostly screen-sharing, and, frankly, that would be a massive pain. especially with the ONE SCREEN. It's not even split-screen.
I don't think it's a question worth asking right now. The physics engine simply can't do it right now. That's the reason we don't have multiplayer, not because BeamNG eats CPUs for breakfast, or RAM for lunch, or barfs all over GPUs for dinner. The engine doesn't have the needed functions to implement proper multiplayer.
I think in one instance both players were 200 km away, and one session they were 4 players (that's from reddit) to prove this look at the bottom most comment.
Yeah, those videos they are sharing isn't just the multi seat function. That is real multiplayer that someone added into the game as a mod, which, if I had to take a guess, is just sending the reference node positions and then superimposing the vehicles .dae over those reference nodes. That is how they used to do it back in RoR (sort of) and it worked really well. How exactly they also shared the node positions I am unsure as they also had the ability to not only display damage, but if you modified a .truck file and didn't change anything like the models or the skins, it would appear on the other person's computer as the modified truck and not the stock vehicle just moving around strangely. That means that they must have been sending node position data somehow otherwise that wouldn't work at all.
It very well may be that's what's going on, but in multiseat, isn't one computer doing all the calculations and the second player (over the internet) merely just sending their user inputs to control the second car while the original computer just streams the screen back over to the second player so they can see what they are doing? As far as I have been lead to believe that is how the multiseat behaves (I don't have an NVidia card to try this out with). For the original player hosting, there would be no lag and everything would be fully computed as if you were playing with an AI while for the second player there would be nothing except the amount of lag time between when you push a key to when something happens on screen. That definitely doesn't appear to be what is happening in these videos above. First clue is the fact that we have both perspectives from both vehicles. Unless I don't really understand how multiseat works (very strong possibility) you can't have that from multi seat because its as if you are both sitting at the same computer. Second clue is look at the amount of lag from both directions. If this were multiseat, one of these perspectives should have both cars perfectly simulated and have no positional lag whatsoever. This is clearly not the case as we can see there are huge differences in both screens and the cars jitter all over the place. Third clue is that there is no contact and also no transmitted damage. In both videos, both the main player and the second player damage their vehicles, yet the one that is jittering around doesn't transmit any damage or is even contactable. Heck, the wheels aren't even spinning, thus adding to me thinking it's just a superimposed .dae. This is technically true computer to computer, transmitted vehicle data, multiplayer... even if it is at the very best... crude at the moment. I bet that, with time, it will get much better though. Edit: Oh, I didn't even realize that @chris_lucas commented the second video. As far as I know, you're the one that made this mod right? If so, then how exactly does it work?
