Dear Community, as we all know BeamNG.drive is not ready for a real multiplayer because of the mass of data which has to be transported to another system. The complex system of where the beams are by this second, how much they have been bend/destroyed/ripped off and many other things don't allow a fast transfer from pc to pc. So i had an idea for a local machine based multiplayer. A bit different to the already existing one. On my pc there is running a GTX 1080ti, amd ryzen 7 3700X, with 3 monitors connected to the pc, I use all of them to play BeamNG. Of course that's not the setup everybody has. Since I found out that it's not a problem to run traffic with 10 additional cars stable on 25 or 30 FPS, it should be possible to create another Window that displays the view from another vehicle. We already know BeamNG supports multiple inputs. Is it already possible to connect a second controller? Placing one Window of BeamNG to the first screen, second to the second screen. Setting up these 2 cars and playing a local machine multiplayer. BeamNG is already pretty much flexible with positioning a window or resizing that window thanks to Windows10 (for people with only one screen). For future: Why not split up traffic cars for specified host cars, so that both players get the traffic or that the second window gets a temporary UI (with simple tools like maps, speedometer). PS: Please don't forget to rate this topic.
Its an interesting idea but at the moment its not a big priority for the developers, maybe around version 0.50 or 0.99 will be when Multiplayer happens But thinking about it again a few hours later, it would be good to see if this method could work but again issues with bugs and modded vehicles are the issue, thats the issue I see, modded vehicles what if the other person has that mod then what will happen?
Its a local machine based multiplayer. There is just one machine. One process. either the mod is installed or not. The multiplayer im describing here, is just another window with another view. BeamNG has already everything else for a local machine based multiplayer implemented.
With these words, I’m most likely to break your brain ... and the main feature of the game. But what if, completely disabling destructibility? This is in order to arrange a multiplayer race. Yes, we will not have the main feature, but there will be realistic behavior of the car, suspension, engine (which there are no similarities in other games).
I like this idea! I would prefer an open world with no contact between the players, only the environment. With gas stations, oil changes, jobs, delivery, impromptu highway racing, point to point racing, all that good stuff. That being said, last time I suggested this, The most common response I got was, "wHo WaNtS tO pLaY wItHoUt Da CwAsHeS!?
As far as I know, the gas station is not yet implemented in the simulator. However, data transfer “fuel level” does not require a lot of data to transfer between computers.
For a local multiplayer... what your essentially looking for is either an external app, or a built in app, that taps into the data stream of Beam and just rendered a seperate camera view? I mean.... technically that should work. I don't see why not. I just don't know if that would follow the same issues as trying to just add a second camera to the normal Torque engine or not. That is the real kicker here... One thing I do know is that LAN multiplayer is now "kinda" possible. Its buggy, but its a mod done by just a few guys... so honestly, it's pretty darn impressive and only likely to get better over time. Check out the thread here! https://www.beamng.com/threads/beam...p-formally-local-multiplayer-lua-based.63052/ Now one thing you could do is just run 2 instances of the game and have them communicate with each other. This would get around the camera bug as... well... only one camera per game instance... so suck on that camera issues? Communication between the two probably also wouldn't be the hardest thing in the world either as its on the same computer. The difficult thing would be to control both instances at the same time with different controllers... how you would get beyond that I am not entirely sure. Well.... that wouldn't actually accomplish anything with the way you described it. With the way BeamNG is done, you either have destruction, or you have nothing at all. So if you we want what you said in the second part of your statement to happen (realistic moving suspension, body, wheels, tires... all the fun stuff) then to have that happen you would, as a byproduct, naturally end up with functional damage. In BeamNG it's an odd case of you either get it all or nothing. Now... going on that same tangent... you CAN disable collisions between vehicles. RoR had this for YEARS and it actually worked really really well... this would probably be a thing that you could set up in individual servers though I would guess. Well... That actually wouldn't matter at all. If your car runs out of gas, your computer is the one that needs to keep track of that. If your friends car ran out of gas, their computer would have to keep track of that. The byproduct is that your car would stop moving and thus the other person could surmise that... aha... they ran out of gas. No extra information transfer necessary there. Remember... all you are transferring when doing multiplayer in a racing game is just positions (and RPM for the engine so your computer knows what sounds to make) but that's it. Plus all of it would be based of the locations of the reference nodes. So yeah... no fuel data necessary.
So you need to turn off collisions between players, this is an even more ingenious solution. It doesn’t matter how reliably the enemy’s damage is displayed, the main thing is that you will see it.
Oh yeah, you will see it all right. To get collisions to work in multiplayer, you are essentially using the same JBeam of a vehicle that you already have in your computer as a reference point for where to place the collision tris on your side. What is transferred is the reference node positions, and then the rest of the node positions in reference to the reference nodes. So... as long as you have all the node names, you then could go into the JBeam of the same vehicle and bring out where all the tris connect to... then boom... collisions calculated on your computer. (it's much more complicated than that as I have described in other threads, but this is the simple gist of it) If you turn off the collisons for that server, essentially all you are doing is turning off the step where it puts all of those collision tris on their vehicle on your computer. Basically nothing else would change though. You "could" do it the SUPER simple way by transferring data of just the reference nodes and then placing all the mesh's about that... but in doing so, nothing on your friends vehicle will move. If would just be a sold mesh randomly moving about... the wheels wouldn't turn, the suspension wouldn't move, the tires wouldn't steer... nothing. It would just be a solid vehicle just floating about randomly... so having said that, you can now understand why transfering the nodes is necessary... and thus why it's kinda an all or nothing deal.
But is it possible to force the wheels to spin? After all, this does not turn off physics (as I understand it)?
I mean.... Yes? But you would need to add a system to animate it. Then you would want the suspension to work, so you would need to start animating all of them.... by the time you are done you have fully programed a normal racing game's vehicle mesh animations into your game anyways just to make things look vaguely convincing... thus the issue with doing it that way. The best way is to compress the node coordinates via something like the replay system, transmit that to the other computer, unpack and interpret that, and then display the vehicle that way. That is the only way that multiplayer between computers is going to end up working... So everyone get to working on data compression... that's where the real magic is gonna happen!
And if you turn off the broadcasting of the state of some parts, for example, transmit only the state of the wheels, suspensions and engine parameters, and did the second computer come up with the rest itself?
I mean... you could do that I suppose... but let's look at what would be needed and what could be left out. So we would need the body/frame... kinda important seeing as it holds the reference nodes. So if we don't transmit that, then the computer will have no idea where anything is... so that's a must. A couple fenders shouldn't hurt at this point, so we will take the fenders/hood/trunk/bumpers as well. Now we will take the suspension components... basically everything if you want them to function properly. Then we will take the wheels. So what all did we leave out of that? Little things like the gas tank,engine (need transmission for drive shaft to work, but that's just 1 node), lights if they have a structure, radiator... basically all the fiddly bits or the "details" of the structure. They don't really contribute to the animation of everything too much. Now... because of the way that BeamNG works... what you would essentially be doing is loading up their car on your computer with some parts removed from the part picker. There would be a bit more necessary stuff than that required on their end (so that their computer would know not to send the extra data), but that's essentially what is going on here. Unfortunately, if we do it like that, due to the nature in which beam works, the models that would normally be on a vehicle would also be removed. They are normally loaded and placed via the JBeam and are then guided by the Node/Beam structure as to where to go. Without that Node structure guiding the models, there is nowhere for them to load into... plus... since the game is now skipping over those JBeams, it isn't even going to have the knowledge to know that it should have loaded those models in the first place as they defined to exist in those JBeams that we are now skipping over. Naturally there are ways around this, but unless you are leaving out LARGE chunks of the car... you might as well just transmite the whole thing. We left out the engine.... most vehicles that's 8 nodes. We left out the radiator... some vehicles that's as few as 2 nodes. We left out the gas tank, again... probably another 8 nodes. Everything else we left out would probably amount to another 20 nodes. So let's say we managed to leave out 35 nodes from the D Series. Great... thats 35 less nodes than we had to transmite before! That will save a ton of bandwidth! Well.... remember... I think your average D series had like... 500+ nodes? So while yes, we did save some bandwidth... was it worth implementing all that extra code to just take out a couple parts? Ehhh... in my opinion, not really. If after 10 vehicles being transmitted we only save a pigeons worth of bandwidth... we could also just wait a year or two for the average internet connection speed to increase by that much... not much of a plus. You could take it further though... it is 100 percent possible. Take that older MP mod that was floating around here a while ago. That mod didn't teleport any node coordinates other than the reference nodes I think, so it was just a static model of the vehicle at those coordinates and rotation. The byproduct? Nothing was animated, but hey... multiplayer is multiplayer no matter how much it sucks right? As a combination of the two of these... you could... in theory... create a "Multiplayer" node group in the vehicle which would then be used to manually tell the JBeam which nodes to transmit and which nodes to leave out. This could then be leveraged to only include the most necessary nodes Reference Nodes Outermost nodes of the body Wheels and tires (would probably need a MultiplayerFLW, MultiplayerFRW, ect kind of designation independently to make this work) Nodes for the tops of the shocks/springs and also the hubs/tie rods/mount points for the A arms or the whole axle Then, this Multiplayer node group (plus the other ones for the wheels... or perhaps wheels are just always transmitted) are the only nodes that are sent from the original computer to the other computer. Doing this could potentially cut the data in half. On the other end, the receiving computer would know what parts are to be loaded (as the data for the vehicle configuration would probably be the first thing sent when the connection is established) as there are no parts missing. This would then allow it to load all the models as it is reading the full JBeam. The difference here is that it would use the "Multiplayer" node group as the one single flexbody node group for the entire vehicle rather then using all the much smaller flexbody groups. This would practically be necessary since there are SO MANY nodes missing at this point. This, in theory, could cut the bandwidth in half (or more), still allow for full deformation (although it would remain to be seen how odd looking it would end up), and allow for 100% custom configurations of vehicles displaying all the proper models and still being fully animated. It's like a "super" compromise. The downside is that you would HAVE to go through every JBeam of every vehicle and personally hand pick every node that you wished to transmit. That would, no doubt, suck. But it would be possible to do...
thats the reason i got beam, suspension, offroad, etc. is cool but i wouldnt of got the game if thats it
I don't know what my post has to do with why you got the game. You know I'm speaking strictly in terms of multiplayer, right? not singleplayer mode? As a contact based multiplayer mode (over the internet, not same PC) is in a sense literally impossible?
...and thats the moment why i said: Just adding the second window wouldn't do much work. Because we already have all necessary features. Except the second window. In my opinion the transfer of data for a PCtoPC multiplayer is just impossible. As our comrade already said, the transfer would be just endless. possible but not playable. Imagine your opponent(your mate) crashes his car. Every beam position has to be transferred ( a mass of data), because if not the client could not simulate your opponents car in the newer (crashed) status. If the pc cannot simulate the behavior of your mates car it would be pretty much laggy. The key behind a super flow moving opponent car in multiplayer if transmitted data does not reach you (packet loss) is simulating the possible behavior of the opponent car. you can watch this phenomenon in GTA IV where the cars (if data loss is a bit higher than usual) that it simulates the possible position. and no. i disagree with this. i dont need to play beamng without destruction. you could have taken every other racing or freeroam game under these circumstances. having that said: i stay to my idea of a second window.
I have not seen a single so realistic race. But another main feature is the ability to assemble your car from scratch (I do not mean a replica).
