Players can't work properly ? What does this mean ? That was my point. Like... other players ? See : They want to be able to move freely, which they already can - but they will ghost through walls. Making them "children" of the ship will prevent that, like when they are seated in passenger seats. How would you make them children of the ship but not moving with it ? If they are subjected to the game's physics, then they should be thrown against walls. If not, how would you set that up ? Another physics system inside the ship, so players can walk quietly while the ship can turn at high angular velocities ? Also, the physics engine may run up to 60 times per seconds, but that may not be enough to keep track of everything in real time. This means that a 200-meters ship can turn fast, and players standing at the stern or bow will be "positioned" inside the ship on one check, and outside the ship on the next update. How should the game prevent that ?
That was my point, I don't know. Something that I don't understand has to be going on with the physics system that prevents players from doing what they should in relation to colliders. Except you made it seem like 'because you are the vehicle, others characters can't exist within it's hierarchy below it. Or at least that's how I read it, it's possible I misunderstood. This is actually the beauty of hierarchical object existence. If a player is a child to the ship, all of their positioning is relative to the ship's position and rotation. So, if the player is at the bow of the ship and the ship within a single frame somehow manages to flip 180 degrees, the player is still at the bow of the ship. Their position is a vector based on the ship's point of origin and facing. It's not at all realistic, but it's actually how unity (and unreal) work and is in this instance, as with many others, extremely useful as it allows you to bypass many of these physics issues. Now... all of this assumes that the unity gameobjects are used in their 'standard' fashion. It's possible that they're not, for various reasons, and that (for example) the rotation vector of the unity gameobject that serves as the root of the ship remains unchanged and that the ship is rotated around using other methods.
That could absolutely be an issue, though if it is I doubt the solution is that they 'need better programmers', more just a matter of taking the time to sort it out. Which is why I'm here talking, it's really just trying to have polite discourse to keep the issue visible.
The ship is not independant : it is controlled by another player at the other end of the network. What is the usual impact of this kind of nested hierarchy in a game like Empyrion ? I'm not talking about standard gameobjects like player on a platform : I'm talking about many different players all switching their "parenting" relationship on and off (when is it effective ? who decides ?) while another player is actually sending his inputs through the parent.Now have collision detection in that, and make the hypothesis that the physics update and the "normal" update are not synched, which is surely the case since the player is evidently not a rigidbody. When and how is the "parenting" decided, if players can simply walk freely with AND without parenting ? They're automatically "parented" as soon as the ship starts moving, and de-parented when it stops ?
You mean like the performance impact? Functionally none. These kinds of things such an important & staple component of 3d physics and graphics that they're done with tremendous speed. It's how 3d objects are modeled, a base object and then child objects that have their position based on the parent. A torso of a player has a head connected, 2 upper arms, 2 upper legs. Each upper arm has a lower arm connected. Each lower arm has a palm, each palm has digits, etc... This relationship is how all of the parts of character models are kept together, how the game knows to also rotate the arm upside down and keep it in the right position when your character turns upside down, etc... When to switch the character from being a child to the ship or scene (or the terrain? I don't know what characters are currently children of obviously) is mostly academic. My personal feeling is that it's best to leave them as children to the ship so long as either A: They're in contact with the ship or B: They're within an 'interior' space of it, though that interior space calculation can be a pain as you don't necessarily want a single hole to stop a space from being considered interior. So calculating that fuzzy interior collider trigger isn't 'simple', but it's doable. Collision detection and handling the ship movement from player input is actually massively simplified in principle because if the ship is moving at 130 m/s within the game engine, the character's relative movement remains 0 because it's position is tracked relative to the ship. If the controlling player slows the ship down... the ship slows down and the characters (who are all child objects)... don't have anything special done with them. It's just the nature of the parent-child heirarchy that they remain at their relative position within the ship. As for the physics and 'normal' update... I'm not quite certain where there's an issue here. You are indeed correct that unity (and thus presumably Empyrion) processes physics updates and normal updates differently (physics updates usually run at a very specific rate, where as the normal update will usually process as quickly as it can pump out frames and it is responsible for your frame rate), but all of the character positioning is entirely dependent on the physics updates. Don't get me wrong, I know that there's some element that I don't know. Rarely does a developer using an engine follow strictly the way that the engine is supposed to work. That's where I'm really curious in fact. I want to know what's going on that causes the issue. What quirk of the way that they've got physics working right now makes this super difficult.
I think the reason Eleon hasn't made this is due to the fact the game is subdivided into multiple playfields. It would be hard to determine the position of players within the ship especially when going from playfield to playfield is essentially teleporting with a loading screen. This is part of the reason why I believe they also coded size restrictions for structures, so they don't get so large they teleport out of the planet's playfield (and also due to the fact planets are really flat and have a literal invisible seam that loads to the opposite side). So until Eleon makes a single monoplayfield where the planets are actually round and everything is seamless, then it ain't gonna happen. My best guess is Eleon is capable of making moving ships, but they're not capable of making a seamless galaxy (especially since after making everything seamless you would have to change the way gravity works since it would no longer be playfield based). I would assume it's a gravity rework in particular, that would be necessary after this, that they know they would struggle with. P.S. Oh and they would most likely have to change how O2 works after planets become seamless with the rest of the galaxy as well.
I stopped reading right there. That's pure nonsense and you should know this. Stop writing stuff like you're addressing an idiot.
I've obviously done something that offends you and I apologize for that, it certainly was not my intention. If you want to continue having a conversation on the topic, I'm happy to do so, but otherwise I'm going to bow out of this. I certainly did not mean to upset.
I have been on this topic since the first thread that popped out some years ago. Lots have been said, I suggest you search a bit on the forums and you will see you are just repeating what has already been said before. I just don't feel like giving it another spin now. No offense, k ?
Then have the gravity generators considered to be inertial dampeners. That means all movement will be relative to the ship and no need to consider the impact that any change in vector of the of the ship has on the play. OTOH with gravity generator off erm... splat! Are you in thew ship or outside then simply becomes are you within a vessels active gravity/dampening field. Ideally the extents of those field should be adjustable (like the sensor fields). As for overlaps, well simply consider the nearest only.
Because the fields can extend outside a vessel, they will overlap and there's no reference for "nearest" in such a case. Plus, the player outside will be thrown "down" when getting close to the ship (ex. boarding party). I can see the exploit from here : a tiny CV with many grav gens on long arms that can be used to propel enemy players "down" in space by simply activating the grav gen when it's in range... no, but the jetpack prevents that. There's another forgotten component here : how does the jetpack behave in all this ? It completely detaches the player from the normal "reference location" even on a ship. Another clue that things are not so simple... I believe the grav gens have no effect while the ship is moving - this can be verified in enemy ships in god mode, then disable godmode when inside the ship. The bulk of the discussions on this topic - I repeated this so many times I lost count - always focus on one or two issues at a time, to show its feasability, and they never consider all the components of the problem as a whole, to see how things are far more complex than the oversimplifications proposed. Some players even submitted videos where they "parent" a player to a platform in Unity, with some random cube floating in the background and the default gray interface. That's limit insulting for anyone working on the game at Eleon, like if they were too dumb to be able to do a simple elevator. The reasons we don't have any kind of moving stuff is that Empyrion is a voxel building game, and all content is "inside" a voxel grid, even if not attached to it. Someone will jump in with another "isolated" exemple of solution, and this never ends. In solo play, not a problem, but that feature is mainly for multiplayer, so this is why network component is crucial, and always forgotten or minimized in arguments. Here, some stuff to read. https://thegamedev.guru/unity-performance/scene-hierarchy-optimization/ Also note how many times the network problem is either minimized or completely abstracted from these player "solutions". It's like Groundhog Day. Problems are reduced to a context where all "player decisions and movements" are "treated instantaneously and simultaneously" with no consideration whatsoever regarding ping and individual system's capacity. The server can wait to sync, but someone will be dropped in space somewhere. I guess this would require some visuals to be better understood. See someone here jump in with another convoluted band-aid fix for that. I'm off to more productive activities now. .
That's pretty much what they said when I asked in the stream I mentioned several posts ago. They were looking into getting moving stuff working and then they could work on people in moving ships.
