With all the bugs they have in Star Citizen this is one thing they handle very well. Just implement it the same way.
Having NPCs walk around the ship looks very unlikely to be implemented. Not even the enemy AI can walk around in a static base without getting stuck on every corner (eg no pathfinding). Even though he game has those nice large 2x2x2 meter block-grids, which would be perfect for calculating paths (without having to dynamically build complex things like navmeshs). Besides: walking through the duration of a warp sequence would be a subpar gamedesign. Either the warp sequence is to short to make walking around have a purpose. Or its too long, annoying players who just want to arrive at their destination. The most robust solution to allow waling on CVs (in Multiplayer) while moving is some kind of autopilot mode, where the ship flies to a destination in a predicable manner. But without the randomness of sudden payer-maneuvers. (So every client can predict accurately how the CV is moving at any given time while in the autopilot mode). But again, I think the whole character controller for movement in the game was designed with walking on static terrain (as 99% of games use it), not within a moving reference frame. And the Unity physics engine has limits too. There is no concept of having separate moving reference frames. Thus two object moving together with the same speed could behave differently towards each other than two objects standing still relative to the world. Could be a source of all kinds of bugs and players glitching though colliders. The problem of moving within a moving ship cant be compared to other games. In Star Citizen, the player cannot just rip out the wall of a ship and rebuild it in a another way. Its using static predesigned ships. And it planned in this feature right from the beginning. A completely different scenario altogether.
I heard that they could get walking in ships "working" but that the player could not add or remove blocks while the ship was in motion and that due to that and other things they decided it wasn't worth it to implement at this time. I could be wrong about that. Personally I'd be fine with walking on ships as long as it let you interact with objects (containers, constructors, etc), even if you couldn't add or remove blocks from your ship.
The only problem i see with modding while still in early access (and even in some cases where a game hit release status) keeping modders interested in maintaining their mods. If you allow modding during alpha / early access you can be about damn sure that most of the mods that come up don't work properly, get outdated before the game is "finished" or even break things with your game so you are unable to continue playing the game. And i actually like mods for games. In some cases it makes a game bearable or even playable *cough* ARK-single player *cough*. The downside is when mods are no longer supported or updated. Another problem is that things that are available as a mod, most likely don't find their way (not even optional) into the main game where they belong. I am talking basics, like mechanics *cough* SE, ARK *cough*. Not total conversions or decos or other real good mods. Some things just don't belong into a mod, but rather into the base game itself. There where it is maintained to make sure it stays useable while the modder already went off to another project. Don't get me wrong, there are some real good modders out there that craft real jewels. You just have to search real good for the ones with modders willing to keep them updated and good, between a huge pile of data junk made by "kids" without thought (even adult kids, making unbalanced BC, broken mechanics, broken files and worst => files that break stuff, in worst cases your game you invested hours into already). TLR I like mods, i just rather do not want to see them now. And not for the most basic stuff that should be in the base game. Walking on moving ships is one of those that belongs into the base game itself, and not into a mod.
Oh i forgot one thing: Some people argue that those things are only useful for multiplayer and big scale battles, with people manning ships and guns/stations. That is simply not true. Walking on moving ships will help alot in SP too. You just don't notice all those the small things that make a huge difference. Just imagine you are aproaching a POI, take out the turrets, a few drones stop by and you just want to get out on uneven terrain.... and you do NOT get the massage "the vessel has to come to a complete stop for you to get out of the pilot seat" constantly. Just let it slide down a path you chose to come to an autostop while you get out in HV with tha beautyful build and well layout interior, grab your gear from a box (if not on the character), open the door and jump out. Those are only small things that will make a huge difference, in many many many situations and vessels, without even the need to build/teardown/replace blocks. It will make a huge difference in gameplay without this need already. Small things matter, always. Its all about the details. ;-)
Not to mention the potential for running a ship more like a real (Star Trek) captain. With an NPC bridge crew that handles the particulars of maneuvering and shooting, you could walk around the bridge checking on stations and issuing orders (maneuver patterns, targets to attack, etc.). Got boarded during a skirmish and your security personnel just can't seem to hit anything? Grab a laser rifle and head down to the engineering deck to stop them from taking out your generators or warp drive, while your bridge crew continues maneuvering and exchanging fire with the attacking ship(s).
No wonder i seem to not like you..... Star Trek *yuck* No seriously, though i am not a big fan of Star Trek, the posibilities you pictured are pretty much an enhancement. Even for singleplayer (ok, that boarding party needs a looooot of AI work for pathfinding an unknow sturcture). But even without this mechanic there are many many many more little details that make a huge difference in terms of gameplay. Changeing stations (when they are different ones for special tasks). Moving through space at slow speed while manning the longrange scanners for anything valuable or threads. Slowly approaching a abandoned ship for a slow autostop wihle walking over to the turret control to multitool it down. All kind of things would be soooooo much better besides combat related things. As i said, best part is to not have to wait until the ship fully stops is a huge improvement. ;-)
Ah, perhaps running around your ship repairing the warp drive while navigating an asteroid field with a giant cruiser on your tail is more your style? But, in any case, I agree that there's all sorts of smaller-scale QoL improvements that this feature would enable.
Yeah.. I'm all for the dev team doing anything in the world to make this game the best ever... but I agree with the skepticism. As someone who's been so involved with this software for so long what do you think the answers to these timeless questions are: Is there enough money to pay them to do that still? Is there enough potential profit to make that part of the venture worth while?
This feature, although would be nice, is utterly useless if its bugged to death, SE does not handle this very well either, Ive been shot through walls and all sorts, its really very hard to get to work right, and if you imagine a battle with 10 players on 2 ships pulling hard turns, just crunching the numbers for the positional data for each player is going to spike the CPU on the server and client, there is no way possible for Unity to predict what a high ping player will do and a high ping effects this feature massively. If it was implemented, our ships would not be changeable while in flight, so effectively you just halved the amount of things you can actually do while in flight, kinda defeats the purpose a bit there. Weapons like rail guns, and hit collision, what a mess that would be. So the devs have a choice, walk in a ship, loose half of the game due to the inability to change anything while in flight, or put smarter AI into the game. Its more a matter of whats the most useful and profitable and practical. Walking in ships would be cool, no question, I just think its going to cost to much vs what we could have instead.
There's def. a *lot* of things that can go wrong if done in the traditional sense for sure.. And it also makes every new feature way more costly to create (in a sense).. Hence why I previously suggested an alternative approach, where you make the interior a seperate instance from the actual thing, and just make things pass-through to the inner/outer version, depending where it happened. Sure, it's a cheaty way to do it, as it doesn't actually move, but if you make the exterior move, depending on what you'd see from the 'moving object', it would effectively be the same result, just way more ressource-friendly, and considerably easier to implement, without really having to rework anything currently in place.
This has been suggested before. I actually exclude "not real physics" and "realism" because gameplay is always superior to realism in a game. But is also makes things more complicated and opens questions. Like what happens in a hull breach, what if a very powerfull projectile goes actually through the whole vessel? And most important with free building game: how and where do you define "in and out of instance"? I actually think if you can define parent object and a child object. The child movement and physics is always in relation to the parent object, regardless how the parent object moves within the world or a certain playfield. That way you prevent the anoying events @piddlefoot described in SE. Which is only occuring becaise the devs needed to make "as physically accurate as possible" for the sake of realism while sacrifising fun and gameplay. Yes to cheat and break physics, to enhance gameplay, ease of use and fun. But it needs to be an also practical and (relative) bugsafe way to do.
What about freezing and unfreezing players depending on if cruise control is on or off ? what I mean is what if you were free to move in the vessel when it's moving in a straight line and as soon as you disengage cruise control or take control of the vessel (hitting WASD) the players just freeze where they are and become part of the ship, basically it would be exactly like now but insteading of being in a seat, you just stand still where you are.
You know, the simplest solution (code wise) would be introducing a few special conditions: #1 the player movement-controller is a simplified version when the ship is moving (magnetic boots or whatever as explanation) #2 the floor that can be moved on must be marked (special block material, or painting, something that can only be applied to propper floor blocks) #1: resolves the issues with the physics not being developed for having two moving reference frames, and things like rotations. The player movement controller is then a very simple relative movement (relative to the ships origin), without fancy physics collision detection, accelerations and jumps. #2: resolves the trouble of the movement controller acting in a dynamic environment (player designed voxel ship). Only properly marked "cruise floors" can be walked on. (flat blocks, angled staircases, elevators). For the custom movement controller this is then a simple reference surface within it can move the player. Those surfaces ensure that there is not object that the player can collide with (removing the need for collision detection). In this scenario the player could even move around when another player is moving the ship. The players local position is always displayed in relation to the currently known ships position, and its relative position to it. other player clients are placed in the same way (in relative term, not absolute world coordinates). The position of the ship is known to all clients currently already in MP. Further, the game should not allow using handheld weapons, as they interact potentially with the area outside the ship, or drop objects onto the floor. And restrict interaction to manipulating objects within the ship (containers, contructors, gunturrets...) For singleplayer it only makes sense when having an autocruise obviously... The transition between "cruise" and "normal": when entering cruise, the player must be on a "cruise floor". Same mechanic as having to sit in a seat. Moving out of cruise mode: the ship is standing still, the physical position of the player (normal movement controller) is then set to the position of the custom controller.
Its like the idea many people had in SE regarding this issue about player get smashed into walls. Solution, magnetic boots. Sorry, but that is stupid crap. Why do i need a game mechanic to counter a mechanic which is brought in to act like real physics which causes problems in the first place? When the solution is simply f*** realism and make the game fictional. The physics interacting with a object (vessel A) do NOT have to work the same way with everything moving within said object, which has its own physics. In the same way no gravity generator would be needed. Who else would care why you can walk around in a ship in space, except a hand full of realism fans? Is it realistic? No. Is that bad? No. It actually is good if not everything is effected by real physics. If it lets you move in a moving, accelerating, turning, spinning and rolling ship, than it actually is good. If you exclude realworld physics from certain things, some problems are solved which normally would need extra mechanics and gameplay features to counter them.... unnecessarily, i should add.
Thanks ... I have absolutely no idea what you're talking about here. Except it has nothing to do with the game physics but rather the engine's limitations (Unity) it's not bad because it's not realistic, it's bad because it can't be done. Anyway I haven't said or even thought about physics or realism or SE or anything else you brought up when I made my post, it was just a simple idea, so I don't really understand why you went off on a tangent here.
Not your idea in particular. I was still thinking about what they did in SE. Not wanting to be rude to you, i was meaning the bright idea of other devs trying to find a solution to a problem they caused themselves. I was talking about the wish or plan to make everything "duuuh realistic" using real world physics is what caused problems with walking in moving ships in the firstplace, which they countered by implementing a gamemechanic (magnetic boots) instead of getting rid of "realistic physics behavior" and installing their own behavior into the game. Well i have seen this and that. One side says it isn't possible, the other says it is. Well, it is kind of a solution like the magnetic boots in SE => a workaround. The problem is that the game needs the coordinates of a vessel on all three axis of a playfield (3 dimensionally room) currently is needing the same for every entity on it. Physics apply to the vessel so, you know mass and velocity in one direction goes on.... and so forth. Problem with moving objects within a moving object is everthing has a start and a destination in every moment of calculation. This causes calculations to fail and player to glitch at worst and players smacking into the walls when the ships turns at best. To prevent both it would be best to take the vessel and give its own coordinate grid. So only the calcutaltions for the vessels need to be done on the playfield grid, while every person on board is moving on the vessels coordinates system of the ship, ignoring the physics calculation effecting the vessel. Like a playfield in playfield in realtime. The problem is of course: what happens to objects/players traversing from one to the other and, of course, is that technically possible. If its notvpossibke to separate the two, i fear we are stuck to stick to the seats, converting the players to parts of the ship. The key is to separate the calculations of movement of multiple objects from each other. In order to not have the system to "guess" in which direction the pilot is turning while also predicting and calculating the movement of all other objects at the same time.
Even if it is possible it would be a huge performance hit because of all the calculations that have to take place and even then it would fail like 50% of the time and players will clip through the hull and get stranded in space. Well I also was on board with Exacute proposition until you and others pointed out its shortcomings and issues, and that's why I submited my idea of freezing\unfreezing players. If the the issue is that there are too many variables to take into consideration (ship speed, accelereation, rotation ...) then why not eliminate most of them, and players can only walk inside the ship if it's moving at cuise speed and in a straight line, it's like in real airplanes, you can't walk in a plane when it's taking off or landing but when it's moving at cruise speed you can get up and go take a **** if you want. It is indeed a workaround but it's exactly what this thread is about (or has become) because the real "walking inside moving ships" as we intend it will never happen, it's just an easier and performance friendly way to do it (well at least I think it is).
It does leave some open questions indeed: My approach, if I were to do it, would be to effectively make a 'shape' around the ship - Smallest possible, while containing all blocks. - Or if gravity gets some love, whatever is directly affected by *this ships* gravity, is inside this instance. If less than 100% gravity, it would be subtracted in movement (Like.. if the ship moves, it moves the player inside the instance slightly, based on how much 'not affected' by the gravity said player is). This is slightly more costly to do, but makes it a way more flexible system, and also makes gravity play more of a role. If the player is 'inside', the player moves on a non-moving version of the ship. (Essentially another playfield). The exterior is simply defined as a 'camera view' from the actual vessel. This would display all incoming missiles, lasers, ships, asteroids, etc. without actually rendering them twice. When another entity enters the instance itself, Objects with their own gravity excluded, they get transfered to the instance aswell. (Such as missiles, etc) Ideally, in the 'actual playfield', the ship isn't really there, but rather a physical outline of it, that is basically a render of the other playfield. What this mean in practice: -Ideally, all damage-calculations would be done on this other playfield (Which means it is effectively in its own thread) -The 'object' on the actual playfield, doesn't 'cause lag', as it is effectively just a 'fixed-render', without having to do updates to the blocks, etc. -- (I would have its actual appearence be dependent on a 'camera' for each player outside the instance, so it is effectively a 2d image, but would look like the actual thing, as the camera is moved on the instance, dependent on the players location, relative to it) Dependent on how it is done, it could make space-combat really smooth, while keeping all the flexibility of movement, building, repairing etc, and potentially even opening up for doing more detailed 'damage-calculations', as it wouldn't block the 'main thread' (For the playfield, that is).
