Leopard

the re-release should have been a little over a year ago according to the initial release date

Try pressing B for more details about an upgrade ohh that closed the window... or paying credits to unlock parts ohh that doesn’t work either or expecting to accept a contract and not have it vanish, along with any others outstanding among many other problems in this bug ridden, badly tested pile of zeros and ones

looks like the "hit box" detection routine is mucked up

previous port yes, took a while, current version since buying of part in R&D is broken I've not bothered to put the time in

try buying an upgrade in R&D...

This is progress and a good sign, would prefer it to take a bit longer and be done right

A strange definition of the word "fixing" that I was previously unaware of

It crippled the last edition as well which suggests it’s a bit deeper than a conversion issue

Each to thier own I guess. prefered a game where the controls failed less often and the actual functions were there prefered usually playable but flaky over stuff simply not working in the first place in a game with memory loss issues

Not sure what the “great enhancement” is myself, if anything it’s considerably worse than the previous port

on past performance... We will get a patch thats claimed to address a few issues, but only really fixes one of them, and then only most of the time, this will arrive in a few months so don't hold your breath. then if you are lucky in 18 months we will get a further big release, maybe 1.3 about the time the PC is on 1.5.., this will break a whole range of further things and leave you wondering if/how it was tested

FTW on Eggbox had the x1-x4 available at all times, including in space accessible via the controller (on screen doesn't show buttons for it, but showed when it was active), x5 and higher only when not under acceleration in either direction. Main issue I had with it was one of the two controllers here has an iffy contact on one of the bumpers so often miss hit when trying to trigger it. It worked fine though, but would have benefitted from the ability to customise the controls (specifically a key thats is "return to x1 NOW!" that is only active under acceleration, and is a key that doesn't have a horrid effect normally

Had similar here, not just EVA Kerbals but entire space craft being recoverable. Its not 100% of the time, but something internally loses track of if you should be able to recover or not and then you can either recover everything or recover nothing (the former isn't game breaking as such, the later most certainly is) Combined with the other control issues I'd suggest a serious look needs to be taken at what appears to be a state engine inside the code (read somewhere the mod API is "stateful" which is a bad design anyway) as I think a lot of these issues are a result of something not updating a memory structure correctly somewhere

Same think I've been doing most nights for the last 18 months waiting for a working console edition of the game

sounds identical to the last port having the same issue, was "ok" if you avoided using any time warp, but touch that control and you're playing russian roulette with an automatic. tends to suggest it may be something in the way Unity is handled by consoles, or the way the time warp is managed by the core code relies on a bug somewhere to work right. Consoles tend to be a lot less fault tolerant and more locked down securely, if this is something like an unrelated pointer or whatever as the game changes from physics on to physics off and back leaving a memory structure corrupt or incomplete then the game tries to save, fails and drops you back where you were - rinse and repeat

just imagine how useful trim would be if there was a way to set it, but only when you wanted to, and only the amount you wanted to set it to...

If memory serves the issue with that is the certification process via MS & Sony, likely not helped by going back and forth as they are not the ones actually writing the code. A list of what was "known" at the time of release and the plan for it would be good, stuff thats in 1.2.2 but not in 1.3 - with a note that thats due to be fixed when 1.3 is rolled out is actually fine - then a focus on the control issues

Another sign of the "extensive testing" then

sounds like something, somehow, is linking a couple of game parameters to I guess an internal structure the game needs to save - and likely to avoid save "corruption" there is a check operation prior to the actual save which is then failing - so you can't save - game sees you haven't saved so keeps you where you are. That or the GUI code is hopelessly intertwined with the game logic code, but only a fool would even attempt that

appeared not to have caught basic functionality like buttons not working, that they confirmed very quickly when it was pointed out to them, almost as if none of the development team had ever tried to use them is what provides the scepticism about the test process. This just has the feel of a beta release, and an early one at that, where such basic issues get through, stuff like a save file falling over under certain obscure conditions or a problem that manifests itself when two 300+ part craft try to dock you could perhaps understand. but basic control functions not working? This is before you get into the issue of "press B for more info" and "press B to exit" on the same dialog, which suggests that specific dialog was never tested, but also suggests something somewhat lacking in the design specification stage

you want good feedback for bugs? include a bug/crash reporter within the game - this can then send the save and whatever internal state information the developers feel the need to include. this isn't a PC where there is a web browser thats easy to use a click away, its a console, without a keyboard, getting screen grabs off is a pain, data dumps essentially impossible - if you want reports in a consistent way have a form inside the program, running as a supervisory watchdog process - outside the game engine, and not using the same control engine and maybe, just maybe, you will get useful information back

tried again today, again all previously completed missions wiped and the one I was actually trying to do turned out to have vanished by the time I launched. they spent six months testing something, I'm guessing actually playing the way an end user plays didn't feature

Sorry I don't see basic functionality like on screen controls failing to respond as a "quirk", I see it as game breaking and a sign of an exceedingly poor QA process. QA is meant to try and break stuff, which is then fixed, not simply added to a list and ignored. You could argue some of the features the failed controls enable can be worked around, but the actual control failure itself is not acceptable and should have been discovered through the most basic of testing. Stuff like the way Trim is set/cleared making the game significantly more difficult than it has any need to be, the binary nature of the default throttle control could be considered "quirks", while they are an irritant, at least they actually work as intended, even if "as intended" is not "as desired" or "as expected" by players Other game play issues smack of poor design, and again poor testing with a very script based testing approach and not going off script. e.g. the ability to recover a craft in flight as opposed to just when landed back on Kerbin, or the way saves are not working correctly or reliably - which given this was a massive issue on the FTE port is unacceptable to still be present here. This new port, on its first release had one job, work better than the previous port, by just about every objective measure as a player it has failed in this job - the previous version was actually more playable, for longer, with fewer control failures

Sad this one is still here, this is the #1 that made the previous port utterly unplayable on eggbox.

In cursor mode it seems to be where it used to be, iirc left bumper then X and Y use it to speed up parachute landings