Meh...you can have that analogy if you want. I have bumped into a few things that really irritated me, but nothing "roach in the beef" worthy. But all of our personal degrees of acceptability are different. A roach on the floor for you could be a hair on my glass for me.
That's fair - as you say, people have different tolerances for stuff. FWIW, I did limit my complaints on the dislikes thread to a few specific categories since a lot of stuff isn't really THAT hard to deal with. Just to further beat the dead analogy though, a hair on the glass can be easily remedied - get a new glass and it's sorted. Something like roaches (and mind you, I chose a type of bug very intentionally for this) are more insidious and harder to get rid of. To me, just as an example, dealing with structural integrity is "hair on the glass." It's a pain in the ass, but it's (mostly) easily worked around. To pull it back to THIS topic, being able to move on a flying capship is something that multiplayer users are most likely reminded of every time they have to move their spacecraft - everyone has to shuffle their way into a seat, or they end up... I actually don't know. Chunky salsa? Just randomly left in space? I know the latter happens if someone logs off while in a seat. Either way, it seems like this particular issue especially is a bit beyond "hair on the glass" since people are continually reminded of it.
But, to me, it is a hair on the glass...because I don't play multi-player. So...its technically a hair on someone elses glass that I wasnt around to even see. But I totally get what yall are saying. I have bumped into some pretty gnarly bugs in my time...i.e. ship not warping...but I did...so I ended up in a totally different system just floating in space. Enemy capital ships skipping around. And some other minor things like trees growing through POIs and the like. I also admit that I have a higher tolerance than some for just moving on and not letting a flaw in the game ruin everything else I do enjoy about it. None of it has been "game breaking" for me. Some have broken immersion in that moment, sure, and left me irritated. But I am used to games that are far more one dimensional. Some are excellent building games, some are excellent space combat games, some are excellent FPS, and some are superb survival games. But I havent really found one that attempts to do all of the above and pull it of remotely as effectively as EGS. Granted, I am not the most prolific gamer out here, so who knows what I may be missing.
At this point (ignoring any roaches,) I guess that I've found enough hairs that I've become tired of returning the glass for a clean one. I don't know if this means I've been playing for longer than you, or I just have a lower tolerance.
Meh, doesnt matter either way really. If you arent having fun, move on to something else. Lifes too short to play games we dont enjoy.
That's what I have done. I just got sick of the minute crosshair and not being able to see where I'm shooting in the heat of battle, so gone back to seeing what the Minecraft End update was like. I still like watching people play Empyrion on Youtube and I like the people on here so will stick round.
Sure you can walk in ships in Space Engineers and in EGS you can't. But, for me, Empyrion succeeds in many other areas where in Space Engineers you have a rudimentary implementation or no implementation at all. I'd rather not have something implemented which changes collision system so drastically unless is for the best and... unless is feasible by Eleon and don't take the focus on more important features and bugfixes. Many games don't even have ship boarding and get away with that just fine. If they think it's feasible by the team and would also improve the existing collision detection than yes. Otherwise they could just prevent people from pressing F by accident while ship is moving?
I feel like if they can't allow people to walk around on a ship, then at least make more activities to do while sitting. Consoles for boosting weapon power, managing shield regeneration, etc. I feel like at the minimum some kind of damage control console to sit at. Hell, even remote controlling drone fighters of some kind would be fine. The point I'm making it that if they can't let people get up and walk around on a moving ship for technical reasons, then give them something interesting to do.
Not gonna lie... this is a big thing to me. I understand it would be completely irrelevant for most SP gamers. It could have a little bit of relevance for traveling long distance in space and wanting to get up and do ship modifications/upgrades, but it's not really particularly important. For multiplayer, the inability to have entities inside of other entities (players inside ships, ships inside ships) be able to move around, dock/undock, etc... is really frustrating. I results in a lot of waiting around and even occasional frustrating and death. It is actually, IMO, one of the biggest reason that multiplayer peters out really hard when you start getting into CVs. They're boring for everybody but the person captaining. You can't use the flight time to go make modifications to your ships. To the CV itself. You can technically craft stuff by using the control panel... but even that is frustratingly hindered because only 1 person can access the control panel or a constructor at a time. Not to mention... there's only ever so much stuff you need to craft. CVs need more stuff for other players to do. A 'CV upgrade' patch could easily be a whole patch by itself, and there's plenty of content ideas out there. From giving players improved controls for managing turrets (say... a weapons control system that allows you to directly tell turrets what they should be targeting. I don't mean 'target turrets' I mean 'Shoot this specific turret/engine/block'), to drones (small engineering drones that could be used to place blocks and repair damage similar to a player drone), to 'slave SVs' that can be launched directly out of the CV and be replaced automatically by a built in factory. That's just stuff that I thought about on the fly. CVs are awesome conceptually... and yet they feel so incredibly limited in practice.
To get a NPC or player to walk around on a ship, why not first group that player to the ship as a child object. That way, whenever the parent object (the ship) moves, so does the player. They probably do this with the seats. But the trick is to determine when the grouping and ungrouping should occur. I am thinking that they should implement gravity boots for this, where the player can choose to switch on. Doing this would fix that problem. Theoretically, everything else, including collisions should fall into place.
I think that this is done through physicalized volume grids, when you are inside the volume, you are child of the object owning this volume, and in a hierarchical way. The counter part is that this imply more workload in general, anyway they already check the collisions, but I do not know the performance hit that this would to have over EGS, maybe they do not have it due to this. Anyway, I am not here from the very start of the game, but by reading the forums I have the feeling that being able to move your character on moving ships was in there at the start, may be people being here from the start of the game would confirm this.
Not necessarily. You could actually have something that would be meaningful for both MP and SP... Just like you say, definitely more "stuff to do" for the CV passengers/crew are needed. You can currently have NPC crew in your ships as cosmetic decoration. What if they actually could do something meaningful *and* then that same function would be available for a human crew member to handle as well? That would give you one feature that solves 2 problems both in MP and SP. Borrowing from your stock sci-fi tv series there could be: Helm: The player controlling the movement of the ship. A real human both in MP and SP. Tactical: Assigns targets and priorizations for automatic turrets. If human (MP) then gets controls for clicking targets (ships, POIs, drones, etc.), for rearranging block type target priorization, activate / deactivate weapon types etc. If NPC (SP) then you (the player) can create target priorization lists beforehand and assign those to your ship toolbar (i.e. simulating you giving a targeting command). Maybe NPC crew member would also give you some kind of bonus effect on accuracy and/or damage? Engineering: If human (MP) gets controls for "fiddling" with thrusters, weapons, warp engine, and shields i.e. your classic sci-fi drama "overdrive something at the cost of something else". Result is a boost in something but with a cost in somewhere else, or maybe a *risk* of a cost in somewhere else to create some excitement. If NPC then maybe be allowed to choose a bonus to something by accepting a handicap somewhere else? Captain: A human (MP only). Well, someone has to give the commands, eh? (So, yes, an optional role but can be meaningful. Just needs some role playing...) Gunner: If a human (MP), takes direct control of a single turret. If NPC then also is assigned a turret and that turret gets some kind of bonus.
The same is true in SP when you are drifting along at a poxy 100ms from one side of a system to another getting bored out of your skull... Hell - I just wish I could set a destination waypoint and the ship would just switch the pilot mode when it eventually gets there. At least in SE we have a local jump drive to simply jump forward a few km or jump to a waypoint, or I can set auto-pilot (which kind of works in space).
This kind of topic may be fun for those having wild dreams, but on the developer side of things I would say : just try to make something - anything - behave "as intended" both with code and graphics, in any game engine. Just try it. Then try adding stuff and change things half-way through. Just saying "they are developers so they should be able to do this and that" is just pure ignorance. Just start learning something regarding computers, coding, anything related to such things, and you will see how far from reality we may be when looking at the surface of things. Players can already "move inside a moving ship" according to semi-realistic physics, but nobody would like it if collisions would be "real" because we would all get killed the moment the ship turns on a dime and players get thrown on walls. So there has to be a special set of rules ON TOP of the "make ships have accurate internal collision" ON TOP of having pseudo-accurate external collision for combat purpose. The amount of complexity and the strain it will put on 75% of the playerbase's computer is simply not worth it. Like Hummel asked once : what do you want to do when "walking on the moving ship" that you can't do from the control panel ? Naaaa. I want my feature, I have the right to ask, and if they don't make it they are incompetent thieves". I'm really happy not to be Eleon, and each and every time I use Unity I feel bad for them. Then I come to the forums, and I felle even worse... .
I asked about being able to walk around moving ships during one of their livestreams for Alpha 11 or 12. One of the devs responded that it is definitely something they are looking into but requires them to get some other tech online if I'm not mistaken. Don't give up hope yet. Many people thought the green borders would never go away due to limitations yet here we are...
Haha. We don't see the green borders anymore, but there's nothing to do past that limit anyway, so it's only cosmetic and the "limitations" were simply "shifted". For players and ships to collide during motion, my guess is that ships only have "exterior" colliders for now (to some extent) and that the (voxel) system they use was not made to detect and generate colliders inside the shell of the ship. They are surely using some kind of raytracing method to determine the "outer shell" of ships, but doing so on the interior, with many closed rooms and obstacles, might require too much juice to be done with a reasonable amount of "fidelity" in realtime, even on beefy machines.
The weird thing about this all is that I know that the interiors of ships do in fact have proper collision even when closed and starting to move. If you move them slow enough, players will stay inside of them. I trust that there's a reason for the difficulty in making this work, but there's a huge part of me that is super curious and wants to know what the reason is. It feels like you should be able to child the players to the ship in order to make all ship physics apply to them and get the desired functionality... so I want to know what the actual issue is. As for "What can you do walking around a ship that you can't do from the control panel?" that very much feels like a question that is only asked by people who play SP. Because they get the best of both worlds for the most part. The answer here basically boils down to 'Anything that you would do that requires you to move around a base". This is probably most notably building/modifying/upgrading crafts, but also includes the same for the ship your inside. It also prevents such scenario events such as having a ship being attacked and boarded (also prevents the same options in PvP, though I don't play PvP and thus it's less personally important).
The way I "understand" it is that ship = player once it is seated in the cockpit (see with triggers and sensors : they only detect the ship when the player is in "control"). And that makes sense too if we understand that the "player controls" will always belong to the player, the "ship" is not a separate entity regarding controls and view (the cameras, 1st and 3rd person). How can the other players be "parented" (children) to another player, even indirectly ? This looks like a case of circular inheritance that can't work, and the player-to-ship relation would have to be changed for something like this to be possible.
What you describe is actually a really common thing in what I'm going to call 'vehicle oriented' games and it's important to make a distinction between what is meant by the player and the player's character. When you connect to a server (or start up a single player game) Empyrion most likely creates an object that functionally represents you, the player, not your character, you. It will have references to your character once you create it, but there is an object that represents you or your connection to the server. It separately creates your character and links your connection to that character in some persistent fashion so that your character can be found easily in the future. It then assigns you control over your character, essentially placing your in your character's body. When you take control over a vehicle, it stores your character in some fashion (possibly serializes and deletes the actual object, possibly stores it in some form of storage out of game, possibly makes it a child to the vehicle, I can't really make a good guess here because there are too many good possibilities) and then assigns control of the vehicle to you, replacing your character. Essentially at this point you are the vehicle. But vehicles can still have child objects. In fact, while there is some root game object (because that's how unity works, and every other game engine that I've dealt with) that represents the ship, it probably already has dozens of child objects that track different kinds of data, scripts, etc... Whatever creates the issue here, it's unlikely to be any kind of circular inheritance. It is likely some weird physics issue/edge case that makes players unable to work properly.
Just to be more technically correct... The ship (or any structure for that matter) is just an abstract data structure. What you see as the ship are just its child objects (blocks) and the game already handles moving those child objects around with no trouble. Also docked vessels and player seated in passenger seats are move along with their parent (mostly) seamlessly. Yep. === Edit === Now that I think about it, the issue may just be that they coded the player movement system to work directly with the playfield coordinates and can't figure out how to translate their 'global movement' code into 'movement relative to a parent object'. In other words they really need better programmers to sort out player movement.
