As the titled states, I had built several stations and landing pads with light guidance systems when approaching a landing area. For some reason none of them work now whilst you're sitting in the captain chair or any other cockpit....? I'm not sure if this is a bug or is intentional (for some unfathomable reason). Anybody knows?
Senors don't react to CV movement. Don't know why. But CV and BA sensors will react to SV, HV or just simply walking around. But once you jump in that CV control seat, well, then nothing.
It's not a bug. It's a limitation of the game currently and it's unknown if it'll ever change in the future. Hummel and others have commented many times on the subject, but here's a link to a comment from Hummel about sensors not being able to detect a player in a seat. https://empyriononline.com/threads/alpha-8-5-anniversary-update.43630/page-7#post-269325 Here's two from Pantera speaking about sensors not being capable of detecting CV's. https://empyriononline.com/threads/cvs-no-longer-trigger-base-motion-senors.48042/#post-298280 https://empyriononline.com/threads/bug-reports-alpha-7-3.28284/page-3#post-193796 There are MANY more, somewhere, but I don't feel like digging today. There was one point in time where a particular member kept reporting it with every single update/hotfix even though they were told multiple times it was a limitation. There was a lot more explanation somewhere in the replies to those reports, but I can't find them now.
A workaround for the moment would be to invert the detection, i.e. turn off the landing lights only when a player was in range of a set of motion sensors on the base (which would activate as soon as the player left the cockpit).
It seems a weird limitation to me, since the map and radar have no issues tracking our locations and HVs and SVs and even motorcycles register with sensors.
@IndigoWyrd As far as I understand it the cv is the parent in the tree, and a base is as well (same reason cv can't dock to base) while sv and hv is children to these grids. Parents category don't interact well on the same level but it doesn't effect how the map or other Ai sees the cv/base.
Makes sense-ish. I think CV’s should be able to dock properly at bases. Why else give them landing gear. If this is a matter of trees, my thought would be: Base = Parent CV = Child SV = “Grand” Child HV = “Step” Child I know ultimately it ties back in to Unity’s sometimes quirky grid system, I just have to think there should be some way to make the whole system work as intended.
It's a matter of the docking code being written inflexibly. Now, admittedly, I'm not familiar with how Unity handles things like this, but I'd be very surprised if there wasn't a general way to stick two objects together. The hard part, I'd imagine, is to make sure the combined object has the right set of properties and control (if applicable) over the objects that it's composed of.
Ah! Good to know they might bring it back in the future! Thank you for the detail links, curious I couldn't find them myself in the search before I made this post... Yes of course, thank you, but it's already configured that way i.e. Green lights are inverted to indicate safe approach and they (should) turn red when the ship is in its final position...
Sorry for the late reply, been away from Empyrion waiting for these new updates to sort themselves out. To answer you question, no I have not. Would they work for ships? I could go in and try it myself, but I would have to update the game and I rather wait for now...
Until we get the circuit Delay element working reliably, how are players in cockputs that dont get detected meant to get home if the door closes too quickly. I have to hop out of cockpit. This used to work perfectly fine with the SV cockpit, so I am confused as to how this is a "limitation". /edit I just tested it with an HV, so this feels like it works in SV and HV's but the code handling CV's is not well understood by the coders, kind of issue? I know that's angling, but the community is a little in te dark, myself especially with the way there is not good way of implementign a delay. I could use a SR circuit and a motion sensor, but the motion sensor solution would require 2 sensors and overlap and an XOR I guess? does this sound right?
Post it as a bug anyway - the annoyance factor of repeating is justified. Lets face it - its annoying to us, so share the pain. That is still a bug - bad design choice resulting in flawed behaviour is still a bug. I suspect it might simply be the size of the CV that is the problem due to the way the handle it. There is some comment about the player becoming part of the ship when in a cockpit seat and ceasing to exist as a separate entity. I have a suspicion that they track the position of a CV from it center of mass (or even original pivot point, or the tag offset point they seem to use), so quite possibly you just cant get the CV's into sensor range. On top of that, they do seem to be in the habbit of hacking at the code to ensure that stuff that should probably behave the same everywhere doesn't, so someone probably hacked in something to completely disable it as a result of CVs generally being too big for it to matter given the way it is done.
It's not a bug though. It's a game limitation that can't be changed right now. The reasoning was already explained in post #7. CV's and bases are classified as parent structures and that's why they don't interact with sensors. It's not a "bad design choice", it's simply a limitation that has to exist for the time being until other game mechanics/systems can be reworked. That's IF it's ever changed. It may end up not being possible or worthwhile for the devs to change it. They were able to manipulate the parent/child structure statuses recently in order to allow the "any to any" docking with 11.0, so who knows, this may be possible to change the sensors the same way sooner than later.... Here's the reasoning again since you missed it above. ↓
I never stated any such thing. You may not realize this, but there are times that things have to be done a certain way until other systems and features in the game can be finished. Then they can later on go back and finish things they way they want. On top of that there are also certain things that have to be done certain ways until parts of Unity itself get updated (if they get updated). So I doubt it's that the devs intend it to be "broken" in this case. It's more likely that they gave us what they could until they eventually get around to fixing the other core mechanic that is holding things up. In this case it's the parent/child relationship limitation that has already been explained in this thread and multiple others. I'm not trying to be argumentative with you. I'm just passing on the info that has been told to us in the past.
Is there a workaround? I mean is it unreasonable to ask that when approaching a set of doors in any class of ship, that the doors will be able to open automatically. I'm not saying it's a bug. I'm saying it's a behaviour that a player expects. Alternately to provide a remote control, which is what I have been trying to accomplish elegantly, to no avail. So keen to know if there are workarounds.
There is a issue with colliders that cause this for the CV afaik. We don't have a ETA when this will be approached as of typing this maybe around the time the colliders get reworked which is planned. Currently the only way to get a 'Door' to open for a CV is to have a Signal setup on the other CV or BA setup to open & close the hangar door. F.ex on the CV/BA that has the hangar door you need to open the control panel & on the 'Main' window in the Signals column create a signal call it 'Hangars' f.ex then switch to the 'Signal logic' window & setup the hangar door with the signal you just created. Now when you are close to the structure open the registry, find the CV/BA that has the hangar door setup, select it & click on the 'Control panel' option then use the switch to open the door remotely without leaving the cockpit of the CV you are in.
