Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Unable to dock at New Hope (City), New Hope #4611
"ver 20190203 on: Windows"
Possibly related to #3077, but with an actual immediate test case.
Log entries show that other ships have successfully docked with New Hope city before:
but none seem to be present.
This is a brand new character, so no biggie. I'm at a Set Speed 0 hover over the New Hope city, with an 8-ton cargo of goods due for delivery to the city, but communications with the city are not functioning and autopilot will simply refuse to respond to the context menu in any way.
I note that at least one starport pad is partially subterranean, and yet the standard warnings about moving starports to avoid clipping did not catch New Hope (city) at all (only Gandhi's Revenge and Itzalean):
Manually landing on a pad (yes, with gear down =P) does nothing other than cause hull damage (the hull already carries some proof of that). Manual landing on the surface instead "works" -- the craft will successfully land -- but doesn't allow access to the starport comms either.
@jtgibson01 First of all, the file should already be a gzipped file encoded with CBOR - this appears to be what you have uploaded. Thanks you for providing it; I'll boot it up and do some investigation as soon as I get a chance.
Regarding terrain, what is your terrain detail setting set to? It's a known issue that low-detail settings for terrain can cause stations to clip through the ground due to the lower resolution of the terrain mesh. That'd be the first thing to try.
Secondly, the log doesn't print undocking messages for ships, so it's very likely that those ships have simply taken off already - check your log for that ship ID in a message saying
Finally - have you tried holding right-click over the spaceport name and simply selecting "request docking permission"? Attempting to land on a pad without permission will simply damage your ship due to collision, as you've seen.
hmm, if there are nightly builds, then they live only on appveryor, right? So a "well kept secret", since there are no links pointing to them, as far as I know.
Looking at appveyor, I think it's failing to put the executable somewhere?
There's a permalink you can use that will always give you the latest build from master:
But it looks like the AppVeyor service is down right now, the artifact server returns error 500. At this point we can only wait until it's fixed.
For this issue: the latest "nighty" build we have is from 9 days ago, which is already better than testing with a 5-months-old build. It can be downloaded here:
@Web-eWorks Sorry for the delay in getting back to you. Been a busy week with a midterm in my immigration law class.
I'm absolutely positive I ran gzip on top of the savefile's existing gzip container (which I was already aware of), because I still have both files -- the naked binary file and the one with the .gz extension. =) It compressed it down from 306 KB to 244 KB.
All my settings are set to Very High.
As noted in my description, I did indeed try the right-click context menu for docking permission -- which as I understand it normally engages the docking autopilot anyway. (As an aside, has an FFE-like docking penalty been considered where it is possible to land without acquiring clearance first, handling the necessary collision detection and docking process rather than letting collision damage through? That would be more intuitive for most players new to the genre.)
@pcercuei Having just tried it out, I still get the problem with the provided 20190528 build artifact.
@jtgibson01 the autopilot menu has two different options: "request docking permission" and "autopilot: dock with station". The first will simply grant clearance for you to manually land, while the second engages the autopilot in addition to getting clearance.
I'll take a look at the savefile again; I wasn't getting pioneer to load it when I tested.