Arch3rAc3

[Edited] Apparently only devs can change the bug priority now.

Ok, guys, the bug has already been reported to the tracker. If you can, go ahead and upvote it ( symbol on the right). https://bugs.kerbalspaceprogram.com/issues/19597?issue_count=77&issue_position=2&next_issue_id=19314&prev_issue_id=19972

This just started happening to me. Here's the clip: http://xboxclips.com/Arch3rAc3/71aa8d07-1fde-482e-9bd2-c0de88e415c1 Screenshot of what happens when I try recovering the craft: http://xboxclips.com/Arch3rAc3/screenshots/e8ffc3a1-00fe-4816-a884-6f270e28e8c5

The station is long gone, I just ended up deleting it because it was unplayable. I can't tell exactlyt how many parts it had, but that module I'm docking in the video is the 1st of 4 modules (I made a Power one, cabins, science and fuel or something else). The project looked pretty cool, I managed to deploy all antennas and solar panels in specific angles that they wouldn't collide with other parts of the station and would fit very nicely. Unfortunately, I couldn't even use the cursor to click on objects since it would just jump all around the screen. It was probably jumping between 5 and 15 FPS.

Sorry, what you do you "turned up to max"? Maybe I didn't quite get what the option is then, since I believed it would slow down real life time so the game could better process the physics, no? There simply is no time slow down in game on consoles, only FPS drop. Instead of it going into some kind of slow motion, it prefers to run at normal speed at 10fps for example, as if the max Delta physics was at minimum.

Ah, I was afraid to hear that. But not allowing parts to be merged to reduce the physical units count from the beginning of the game development would only lead to the situation we have now, so I was hoping that the devs had thought about this, not allowing the game to be so limited - if I find out about a mod that can change this, though, my hopes will be going up. As for the Physics Delta calculation, I do get it, it's not a solution, but a workaround. It would sure make it a lot easier to dock, make burns and click on parts while everything is shaking and cursor is lagging, so it's good enough for now. I can't see why the devs would not include this in the console version as well... starting to get tired of being frustrated with the console version of this game over and over again haha.

Here's a video example I recorded. The station is 2x larger and in orbit of the moon now (it was a nightmare getting it there). http://xboxclips.com/Arch3rAc3/9c32dcdb-b57e-4526-b59f-ae05483d4866 Thanks, just did it!

Hey. I'm having a massive FPS drop near space stations or planetary bases since KSP wants to calculate every single unit, making the game unplayable (docking at 10fps with only the first docking port unlocked was a nightmare!) I was thinking about some solutions, and 2 possible solutions came to mind, although the 1st is a more definitive one: Disable physics calculation for every single object. We simply don't need the game calculating everything in a base or station. So if I already have a base built or a station in orbit and stable for x seconds, the game should just stop calculating everything but the main parts (maybe this could be activated once we rename the ship and make it a station or a base, each having it's own parameters to disable physics calculation); Bring Max physics delta-time per frame back. Why is this not available in the console version of the game? We need more performance options in the game setting. For the ones that don't know what this is, it basically slows time down so the computer can better calculate the physics. For example, if the physics calculation is pretty heavy on the CPU and frames start to drop, the game will basically slow down time (so 1 second in game takes 10 seconds in real life). The problem with this is that it would take more time for things to happen, but the experience would be way smoother (no more trying to click on a tiny ship part at 10fps during emergencies with the cursor controlled by the analogue stick axis).

Nice to see an update on it, although I'm a bit worried if it is going to fix the issue completely. Yes, it won't trigger the trim accidentally while holding the modifier, but will you be able to trim properly yet? As stated in my post, there's the problem of not being able to trim the 3 different movement axis in succession without breaking the previous trim you done, and also the minor problem with the orange and pink markers not being so reliable for proper trimming. A system like the one in War Thunder would be perfect. Anyhow, at least they are making a step towards fixing the problem.

Two months and a couple of days later. No reaction from the Devs, isn't it lovely? Apparently console problems are not as interesting as PC problems.

Hey. I'm having a massive FPS drop near space stations or planetary bases since KSP wants to calculate every single unit, making the game unplayable (docking at 10fps with only the first docking port unlocked was a nightmare!) I was thinking about some solutions, and 2 possible solutions came to mind, although the 1st is a more definitive one: Disable physics calculation for every single object. We simply don't need the game calculating everything in a base or station. So if I already have a base built or a station in orbit and stable for x seconds, the game should just stop calculating everything but the main parts (maybe this could be activated once we rename the ship and make it a station or a base, each having it's own parameters to disable physics calculation); Bring Max physics delta-time per frame back. Why is this not available in the console version of the game? We need more performance options in the game setting. For the ones that don't know what this is, it basically slows time down so the computer can better calculate the physics. For example, if the physics calculation is pretty heavy on the CPU and frames start to drop, the game will basically slow down time (so 1 second in game takes 10 seconds in real life). The problem with this is that it would take more time for things to happen, but the experience would be way smoother (no more trying to click on a tiny ship part at 10fps during emergencies with the cursor controlled by the analogue stick axis).

Awesome! I'll have to fiddle a bit with the interstage nodes to really understand how they work, but I got a pretty good idea from what you guys said. Thank you all!

Hello I was hoping the manual would explain and talk thoroughly about fairings, but it was barely able to say what a fairing was. So, to start with, there's the "sides" options. The problem with this for me is that I can drag the bar, not having only whole numbers to choose from (for example: I can choose to have 4.09 sides, what got me pretty confused). Then there's Ejection Force. I think it's pretty self-explanatory, but is there any usefulness in changing the force? Now for Clamshell Deploy, Truss Structure and Interstage Nodes, I have absolutely no idea of what they're for or their uses. I'd be very glad if someone could explain at least this for me with pratical examples. Thanks.

Although this thread is from January, I did feel more like replying here than starting a new thread. I do agree with the OP that many of these mods are essencial (with some exceptions to this list). Many of these features should have been in the base game to be fair, specially to career mode, making the game more immersive with the current features. To start, I don't believe we need any overhaul or huge mods, like Galileo's Planet Pack or even Mechjeb, but we sure need mods to help us calculate Delta-V and give us more info about our rockets, such as Kerbal Engineer (which seriously should have been in the base game to start it, it's odd - to say the least - that KSP stock fails so badly at giving us data about the vehicles we make). For BDArmory, although it is one of the most impressive mods I have ever seen, I absolutely do NOT think it should be implemented in the console version. Remember that our current systems are already having trouble running KSP stock by itself, and for BDArmory we also require a increase in physics activation distance, which is given by another mod. So this would only bring more trouble, bugs and crashes. One could try implementing it if mods turned out to be something like Fallout 4 did for the console versions, but I don't plan on installing BDA to KSP until I get a better PC. K.A.S would be so useful and immersive when building planetary bases together with K.I.S. One could even make some refueling/repair stations. This is something which I thought the base game would also offer, but I ended up finding out it was a mod. Imagine the uses for our engineers then. I barely have any uses for them with KSP Stock. Also, talking about immersiveness and more uses to thing, the telescopes would be a pretty nice addition. Getting science from performing observations and then unlocking more info about "extrakerbian" bodies in the R&D would be pretty cool. Some mechanics in KSP Stock seem just dull, whsh we had more things to do with them, and these mods could add a lot of interesting features for a career mode. And to finish, one mod that wasn't mentioned here but that I'd really love to have is the Ferram Aerospace Research. One problem is the physics handling causing too much of a performance issue on our consoles. But I do think, nonetheless, that we need some kind of a wind tunnel simulation - like FAR offers - when building crafts, even if with stock aerodynamic physics (just like FAR offers in the SPH - video below). It breaks my immersion so much by having to revert flights after encountering a problem with them, since CoM, CoT and CoL are simply not enough. To connect this to career mode, would be nice having only CoM, CoT and CoL with the basic hangar, and then being allowed to use more features, such as the graphs, with an upgraded hangar.

Will it be coming to the console version of the game?

Guys, please, I'll ask and suggest changes again about the controls, but getting into a bit more details now. As this hasn't even been touched or mentioned with the last fixes, and not even in the youtube video about control presets (where nothing was talked) it made me not sure if devs are so unware of this or if they just don't see this as a problem. But I do hope you call their/your attention with this question/topic, where I'll be trying to clarify the annoying problems that I'm having here (problems which can be very stressing when one is trying to play career mode with a hard preset and the controls seem to want to kill your kerbals every second). Firstly. Can we please, please, toggle an option for fine throttle control without modifiers in the Radial preset? Radial is much more intuitive than Cursor in many aspects, but not being able to properly land a ship, to fly a plane or even to drive/taxi planes (as I don't have the science for building proper rovers yet) around the KSC with precise throttle controls because every time you press LB/L1 to move the throttle the craft also trims automatically if you happen to be moving a control surface is a seriously huge bummer! I wonder why nobody talks about this. Secondly, can we have some proper functional trimming? There are two problems with the current trim system: Unlike in the pc version where you can move each movement axis (yaw, roll, pitch) trims separately if I'm not mistaken, in the console version you can only lazely set all trim tabs at once. So I can't fix my plane which is pitching up by it's own first, and then later try to fix it's slow roll to the right since I'll mess with the first pitch trim by trying to trim it again for the roll..... This is really annoying when you're doing long distance atmospheric flights while trying to use time acceleration because you can never trim the aircraft properly and every small correction you try doing while at 4x accelartion will cause a huge flight path change, overstressing and possible death of kerbals. This then opens up to the 2nd problem: If I try setting half a pitch up trim (the 4th horizontal line in the pitch indicator, right beside the H from pitch) starting from a no trim situation, I can simply push the joystick halfway forwards while using the orange arrow as a reference, and press the trim button once this arrow is over the line. But then let's say I still need a little bit more trim for the craft to stop pitching up on it's own, about a single line up in the indicator, I won't be able to use the orange pitch arrow indicator as a reference for the trim anymore! If I push up enough so my orange pitch arrow indicator is one line over the current trim pink arrow (right where I want my new trim to be) and then I press the trim button, it won't set the trim where the orange arrow was, but way above it, because the game still seems to take in account how much I'm pulling the physical joystick stick instead of the position of the orange arrow. I mostly end up having to reset trim and then watching my Dihedral high wing plane pitching up wildly at over 200m/s. We also have the rather annoying trim button conflicting with multiple other functions. You can't fine tune throttle while turning because you'll end up trimming the craft. You can't time accelerate while turning because you'll end up trimming the craft. You cannot quickly open the map while flying and maintaining a slight pressure on the craft because you'll end up trimming the craft - or then you can try opening the map through the radial and it will end up cancelling your stick pressure because the radial also happens to use the same left stick you use for controlling the craft to select the options, instead of using the right camera controlling stick. Lovely! Thinking about, what I'd suggest was having the LB + View/Select (Xbox/PS4) combination for getting into trim mode. Now in trim mode (with a green message on top of the screen telling you are in this mode) every "camera movement" you do with the right stick would actually create a cumulative effect on trimming. For example, pulling the right stick a tiny bit out of it's deadzone would cause the craft to slowly start trimming up until letting go of the stick. The more you'd pull it, the faster it would trim down, until it gets to -100% of trim or you let go of the stick. This way, I would not have to stop actually flying the craft to trim it, since I'd would have fingers on both sticks at the same time. With proper coordination, one could notice that for the longer he pulls the right stick, the more he'd release the pressure on the left stick, until the craft is slowly and accurately trimmed - not to mention that this would also fix the unintentional trimming, as you'd only get into trimming mode if you really wanted. As for the yaw/roll, both would be done with the right stick X-axis. You could switch between the two by pressing RB + Y, similarly to how you switch Roll <-> Yaw when flying with the cursor preset by pressing LB + Y (L1 + △ on PS4) . If you read it to the end, thanks! I'd really like to know what other people think of this, checking if more people are also being annoyed by the same problems, and I'd also like really to see what Devs think of it. Cheers.

Hello. I just encountered a serious bug. I've made a small craft for the observation missions and, so that I won't waste too much money, decided to place some parachutes on it's first stage. After landing, I took Jeb out for EVA so I could get some science on Kerbin surface and while he was on the crew cabin ladder, I switched craft so I could check if the first stage was landing ok. After it did, I tried switching back but it said there were no crafts close enough, so I recovered the main stage and selected the crew cabin through the tracking station. After getting back on the craft, for my surprise, I noticed Jeb was nowhere to be found! So I recovered the craft itself and there was also no crew in the after-recovery screen, only parts and science. Jeb is also not in the Astronaut Building and my reputation went negative, leading me to believe he's now dead. I'm playing the career with some of the hardest settings on, forcing no quicksave/load and no crew respawn, but everything was going well so far. Losing a Kerbal in this stage of the career with these settings is game breaking. I also tried using the debug console (which should be used to fix something like this without forcing me to restart my whole career) but then it says the achievements will be disabled Why should I even have a debug tool then? I can see this problem may impact even more the game later on if I happen to have any Kerbals performing EVA while switching back to Kerbin or another craft. If I'm not mistaken, this bug (or a similar bug) has already been fixed on the PC, no? Update: I just checked the astronaut building again, and it says Jeb was K.I.A. Wish it would tell me what killed him though, that would provide more info on the bug (maybe he's been teleported and smashed, stretched or something else).

There's also the in game tutorials, pretty handful. If you also like reading, the game manual is pretty good and fun to read, it's one of the apps on the right side of the screen.

Hm, seems odd, but, maybe? This is KSP after all xD. I haven't got to experience any game breaking bug so far, but that's probably because I have barely put any hours into the game. I just don't feel like playing until I can resume my career mode by being able to buy parts from the R&D. I made, though, the whole tutorial missions and a couple of the scenario ones, and also about 1 hour into career with Adv. Tweakables turned ON.

That's for trimming. You're fixing it by trimming to the left, but it doesn't make much sense for me when a left trim allow you to pitch up. Try holding the left bumper and clicking on the left analogue (LS/L3). This should reset all trim. Also, check if the trim is centered on the controls surface indicator, bottom left of the screen. Check for any blue arrows.

If you are sure the craft is not trimmed - and it also happens with every craft - you might have to just report it like this. Try giving the most information possible, though. This seems like a new bug.

What should go? If the problem is he trimming the aircraft (without knowing) because he's holding LB/L1 to control the throttle while trying to turn at the same time, yes, as I've already reported here: https://bugs.kerbalspaceprogram.com/issues/17242 If the problem is something else - which I was trying to figure out - then most likely, no. He saying that the craft doesn't pitch up is just vague at most. The problem/bug that must be fixed lies in the cause, not in the consequence, that's why I wouldn't want him to flood the bugtracker by simply saying "Can't pitch up". There's more he can do, as I mentioned in my first reply here, to rule out the problem to be fixed. (What he could do, assuming he checked to make sure it was the trim causing the craft not to pitch up, is to access this link and upvote the report to show Squad staff more people are being affected by this key conflict and might make use of a quick toggle option to switch between having or not having to use a modifier [LB/L1] to fine control the throttle. So, to clarify, one wouldn't have to hold LB to control the throttle slowly, and therefore wouldn't accidentally trim the craft in flight).

You keep misinterpreting me over and over again. Having the conflict with the trim key - as I've reported on both links already (which apparently you haven't even checked) - IS A BUG! I said myself it was and you keep saying "You say "feature"[...],". No, I don't say "feature", I said the conflict is a "BUG"... Now, having the trim working as a trim should be working is not a bug. Play Flight Simulator X (or any other flight simulator for that matter) for example and trim your aircraft all the way up (for a pitch down). It will be harder to pitch up pulling on the stick, obviously, because aero forces are, basically, pushing the plane attitude downwards. Having the trim working is not a bug! Having a key conflict on the other hand, assuming THIS is what is going on with DunaManiac game and not ANYthing else - which I was trying to figure out in my initial comment - IS A BUG. Not too hard, eh? (Edit - if this unecessary argument keeps going on, I'm afraid we will be moving away from the thread in question and I'll refuse to reply back to you. I'm trying to figure out if Duna is having that problem due to anything else other than the already reported trim conflict bug, because if so, there may be another - yet unknown - bug with the code, and not having to explain to you why the trim actually trimming the aircraft is not a bug).

I believe you missed my point. I absolutely favor the reports of every bug present in the game. If there are 1000 bugs, they should all be reported. But let's be sure it's not a problem on the user end first. I wanted him to check everything to make sure where the problem lies. If he just says that he can't pitch up in the bug tracker, it won't help much. There are many reasons why he might not be able to pitch up, and I'm trying to help by ruling it out. Secondly, I never said the trim with the modifier is not a bug. I've actually mentioned otherwise, as I've already report this conflict in the bug tracker: https://bugs.kerbalspaceprogram.com/issues/17242 and in the forums #3 here ^ This trim conflict might be causing people to trim their craft while trying to control the throttle and attitude at the same time. But not being able to pitch up with full down trim is not a bug, it's a feature. It would be a bug if he could pitch up alright. Hopefully, made myself more clear now.

I believe the status will jump from 0 or 10% to 100% when the update is about to come out - really hope it's not at 0 / 10% yet after all this time. I'm not sure the reason for this though. Maybe there is not much of a point to update the "fix percentage" until they are not sure it's fixed and it's working a 100%. Also, for more complex problems, they may have fixed some of it but not all of it, so it's not possible to say how much % was fixed, since some parts of this problem may take longer than others to be fixed and tested. For example, this specific issue: it has been fixed, although the fix progress bar hasn't been updated and probably won't be until the patch is about to come out. Anyhow, I'd like as well some more communication from Squad, mentioning what they could get fixed and being honest on what might not be working properly or was difficult to test thoroughly yet.