Project Community based station construction and stationkeeping
- Thread starter Majid
- Start date
Face
Well-known member
I see. OMP also uses this concept, although those clients are called "containers" there.
I don't understand that. Is the server module actually a persister module? Or is it a server? If the later, wouldn't I be in my own universe if connected to a local server?
Playbacks are not reflecting the actual multiplayer session experience, because Orbiter interpolates the sample points of recordings to make it look smoothly.
This sounds even more like you are replicating OMP with HTML protocol instead of UDP :lol:. Not that I'd mind the competition, though.
I tried the exact same things before settling for absolute coordinates compensated from lag calculation based on PTP-synchronized timestamps. It is also important to send the MJD stamp of the state-vector datagram to calculate the actual difference regarding the current frame's MJD. Then use a simple RK4 or the like to propagate that forward. You might get huge lags with the HTML transmission, but at least the positions should be less jittery on orbit, then.
I'd also recommend trying to do what Orbiter does with playbacks: not instantly set the new position, but gradually change acceleration to "nudge" the object into its new position. That way you might have strange "swimmy" optics, but it will not jitter so much. I'm currently implementing that in OMP and it looks very promising.
Looking forward to trying my hands on it...
---------- Post added at 14:10 ---------- Previous post was at 14:07 ----------
No. The problem was the jitter, not the lag per se. It was solved a long time ago, though.
---------- Post added at 14:16 ---------- Previous post was at 14:10 ----------
I see, so it means the server module is actually a persister client module, right?
The playback actually gives you the precise experience the user sees. I am not trying to mislead anyone, this is literally the experience you get except for some additional jumpiness caused by the playback system. The playback system was in no way a help in this demonstration. The interpolation you talk about is done manually. This implementation doesn't suffer the issue with positioning being off due to Earth's rotation because some things like the acceleration and the mjd is transmitted and the client uses the Orbiter core to propagate the state vectors forward using euler integration.
It's a surprisingly smooth experience. You don't experience the same position offset that you see in OMP on Earth unless you change the Earth's config file to kill the rotation. Notice when the dg is taking off. You have 1 second updates, so between the updates, the dg goes spinning crazy because the control surfaces aren't being transmitted. But when I took off, it starts being smooth. Under heavy G load, you'll see the vessel "skip" between the 1 second updates. But once the acceleration delta across the 1 second interval is minimal, you see smooth flight. Turns out Orbiter is really stable across clients (in my testing so far) to the point where unless there is hard variable acceleration between the 1 second updates, Orbiter does the work in between well enough that the result is smoothness. On Earth, on the moon, in Orbit. The issue with in Orbit flight is that the update interval is not high enough and there is no averaging at all taking place. But the positioning is so good that even with 60 seconds delta in updates you are close enough to the target that if you turn your head, you might miss it.
The take off could use some work... Orbiter's new touchdown point system is more dynamic and it's harder to get a good landing. So vessels with their gears up very sadly plop on the ground as orbiter updates their position every second to some minimal altitude (due to the landing gear being down on the actual client vessel), and then simulates the fall for the < 1 second update time.
Last edited:
Face
Well-known member
I think you misunderstand me. Orbiter's playback system works by interpolating state vector samples. That's just the way it is. Therefore it is not reflecting multiplayer experiences accurately. I don't say that you are misleading anyone, just stating facts.
I fully believe you that the 1 minute period between each state vector sampling is smooth, because that's just the local Orbiter engine doing its work. Of course that is smooth. The interesting point is where a state vector comes in... this potentially jumping event is smoothed out by Orbiter's playback system. Thus I'm not going to look at playbacks, but wait for the real thing to try out. Given that you've uploaded the thing to OHM already, it shouldn't take too long until I can try it, anyway.
Just FYI: the setup with stopped earth rotation is long gone on Ren's OMP server. The problem back then was jittering due to the use of NTP instead of PTP synchronization.
I released it last night to keep up with the tradition of releasing things on tuesday. I am sad it's not up yet. Sadly I am at work, otherwise I would have uploaded the 3 dlls here.
In non-orbital flight, when a state vector comes in, orbiter's engine is smooth enough that there is no noticeable difference in position. No jitter, no nothing. It's 100% smooth until there is an acceleration difference across the 1 second interval. If you are flying level in a DG at 250 m/s, it'd be difficult to tell whether the position is being transmitted remotely or from local orbiter. If you are hovering over a pad or coming in for a landing, it's smooth.
In orbital flight when the state vector comes in, the delta in position is tiny enough that you can do dockings with vessels that aren't accelerating very quickly under powered flight (since state vectors are only transmitted once every minute). But with things like the ISS, you can absolutely dock.
I tested this by using the scn editor to copy my state vectors to the ISS, burning away from it, then coming back and docking to it. Also, I watched the playback a couple times after recording it on an installation without the plugins installed to make sure things were working as intended, and what I see in the playback resembles pretty much exactly what I saw in game.
Last edited:
Face
Well-known member
Give it some time, unfortunately it coincided with the server downtime. I guess Xyon was quite busy.
Once up, I'll definitely give it a try.
---------- Post added at 16:30 ---------- Previous post was at 16:24 ----------
Well, that could perfectly be so. I know it, because in OMP I have seen this, too. However, I also know how Orbiter's playback works, and I have often seen it swallowing jumps of OMP sessions, so forgive me if I don't trust playbacks as demonstration tools. Nothing will beat the hands-on experience in that regards IMHO.
Yes this time, for now anyway, no registration required! It'll get a unique persister ID for you automatically and from there you'll be able to do your testing by just persisting your vessel in the world, and doing the same with another orbiter installation with the add-on installed.
Just make sure that you use a separate orbiter installation, as the client uses the persisterId file located in the root orbiter directory and if you use the same installation there'll be issues....
Right now, if you log out the last state of your vessel is saved on the server but the position isn't propagated. I just haven't gotten to it, but the plan is to simply move the vessels on log out to a permanent persister that's running on a server while the user is away and use that to propagate the state vectors.
Face
Well-known member
OK. But that would be 2 clients, right? I'd still need network access to contact the server. I guess the server is not included in the distribution, is it?
No it is not. The server is in javascript/nodejs and is running under a $10/month digital ocean droplet.
I don't expect everyone to run nodejs on their windows installations. But the server code is easy to install and run, uses npm and the only dependency is express so it's easy to distribute/run locally.
Also, you just need http/internet connection on the client machine to run it. The code currently hardcodes the server domain: orbiter.world
Face
Well-known member
No it is not. The server is in javascript/nodejs and is running under a $10/month digital ocean droplet.
I don't expect everyone to run nodejs on their windows installations. But the server code is easy to install and run, uses npm and the only dependency is express so it's easy to distribute/run locally.
Also, you just need http/internet connection on the client machine to run it. The code currently hardcodes the server domain: orbiter.world
I see there is an HTML server there. Can you upload the development snapshot there instead of having to wait for OHM approval? I guess that would also come handy in development for updates and such, similar to what we've done here for OMP: http://omp.ddns.net/software .
I'll do that on my lunch break. Just as an FYI, that *is* the HTTP server being used. It also happens to serve some outdated/incomplete static content that needs to be removed for the time being...
In fact, you can get the state vectors currently on the server by visiting: http://orbiter.world/tele
Last edited:
Face
Well-known member
That's cool. Are those vectors the one the clients use, too? If so, it should be really easy to implement some pull mechanism to get them to be displayed in OMP clients, too. That way, a single OMP client could work as kind of orbiter.world bridge.
Notice they aren't changing, I think my orbiter instance running on my laptop at home crashed. And these are the very same vectors the clients use. They call this url once every second, and they simply decide to update the positions of vessels in orbit every minute.
---------- Post added at 04:24 PM ---------- Previous post was at 03:51 PM ----------
I have uploaded the zip package here: http://orbiter.world/orbiter.online.zip and restarted Orbiter on my laptop.
---------- Post added at 04:47 PM ---------- Previous post was at 04:24 PM ----------
I have ambitions of integrating with OMP and using that as a kind of front-end.
Face
Well-known member
Do I have to run all 3 modules on a client?
---------- Post added at 19:06 ---------- Previous post was at 18:55 ----------
I've tried the client with all 3 modules active and get this after simulation start:
Disclaimer: I have Visual Studio 2015 installed.
EDIT: Tried it again, this time it starting syncing (MJD acceleration), then hang up with the same exception.
EDIT: Tried it several times now, every time the same... syncing, then exception... if I ignore it, CTD.
EDIT: Seems like this appears if the JSON content is invalid... and indeed it seems like http://orbiter.world/tele is somehow empty and perhaps invalid for the rapidjson parser? What's up?
EDIT: Now it is bad gateway.
Did I kill it?---------- Post added at 19:42 ---------- Previous post was at 19:06 ----------
For a while it did now show an {} empty JSON instead of the previous [{}] on, so it worked at first. But it took me a while to create a new DG and to hit the persist button. I then wanted to check the server, and got bad gateway again. Now it works, but has an [] as empty JSON. WTF?
---------- Post added at 19:43 ---------- Previous post was at 19:42 ----------
Now I get the exception again. Did you never test this with an empty list?
---------- Post added at 19:44 ---------- Previous post was at 19:43 ----------
Now it is back to {}, and it works again. Seems to be the winner, I'd say.
---------- Post added at 19:47 ---------- Previous post was at 19:44 ----------
Ok, I'm giving up. That thing seems to be a bit unstable, now it crashed so hard my cursor was stuck.
Last edited:
Hahah! I apologize, this was a rushed "release". It's probably a silly issue with serialization, I am using JavaScript after all
That's the source:
https://github.com/computerex/orbiter.online
I'll take a look after getting home and upload the fix.
That's the source:
https://github.com/computerex/orbiter.online
I'll take a look after getting home and upload the fix.
Face
Well-known member
Yeah. Got it to work, I think... now at least the persisted vessel shows up on the server. Now I'll try a second client.
---------- Post added at 19:58 ---------- Previous post was at 19:53 ----------
Well, sorry man, but this is currently unusable, I'd say. I can't get it to run longer than a minute or two without getting a hard CTD. Reminds me of the good old OMP days back then, what a flashback :lol: .
---------- Post added at 19:58 ---------- Previous post was at 19:53 ----------
Well, sorry man, but this is currently unusable, I'd say. I can't get it to run longer than a minute or two without getting a hard CTD. Reminds me of the good old OMP days back then, what a flashback :lol: .
I am surprised you can run it at all....
Face
Well-known member
At least I can confirm that the MJD synchronizer works, and that the server persister once sent the data to the server, and also kept it updated. Something happened, though, that when my vessel landed on Earth was loaded again after a restart, it showed Uranus as reference. It was almost like the server told me: "You want to know where your vessel is? Really? Well, look in urAnus, haha!" :rofl:
Face
Well-known member
Never tried that, I'd have to test it. Both arms use animations, and full animation support is very young in OMP. Theoretically it is possible, because if a DLL saves the animation states, they also get transmitted.
Is this just a casual off-topic question, or has it some connection to the topic that I've missed?
