Dunbaratu

Then you misunderstand my complaint. I'm not complaining about the unrealism of the wobbliness. I'm stating that "realism" is an invalid reason to claim that struts should remain as debris when an unrealistic aspect of the game is the reason the struts are even there in the first place.

In 32-bit code, doubles multiplication take extra clock cycles to calculate because they are calculated in two halves.. In 64-bit code they do not as the entire calculation happens at once in parallel in a single instruction.

Looking forward to it. I don't use mechjeb because it's an autopilot that was handed fully formed from heaven, given as a gift to my space program without my people having to do any work on figuring out how to make it. I'm not against autopilots, but I'm against autopilots someone ELSE wrote. I want the making of the autopilot to be part of my own challenge.

But the reason you need to do the thing that causes this to occur is that the developers designed the separators to be way too springy. When they have to withstand the forces of compression of a launch, the craft 'banana-wobbles' all over the place. The reason there's struts attached to the separators is to remove the flexibility in the connection between separator and the things its immediately adjacent to on either side of it. I don't call that a higher degree of realism. If rocket engineers discover that the separators they have used previously aren't going to be stiff enough for their new rocket design, they design a new separator - they don't use the existing one and add a bunch of wires to the outside of it that will become debris, which when we play the game is our only option.

Hmm. Well that's annoying. Because attaching struts from the adjacent parts to the separators is often necessary to stiffen them and stop the rocket from banana-wobbling on liftoff. If I have to stop doing that because my save file gets all cluttered with 'strut' debris instead of 'real' debris, then it becomes a lot harder to design rockets. (Because I *want* the problem of dealing with my debris, I don't want to be spawning 8 new bits of tiny strut debris with each launch as that will "circulate out" all the older debris since I have to limit the debris amount or it clogs the CPU time.)

I didn't see this on the already-suggested list, so I figured I'd mention it. It's a really simple thing: Time and time again we've all seen the post made by a player new to the game asking why their spaceship controls suddenly stopped working partway into the flight. The new player is confused, doesn't know what's happening, and every experienced player immediately knows to suggest "check your battery power level" as the first likely culprit. This is because we've all made this mistake at least once when first playing the game and remember our own confusion over not knowing what was going on and why it was "bugged" all of a sudden. So.... why not have an on-screen bit of text that appears when the game cancels an attempt by the player to perform a maneuver in which the cancellation is due to having no electrical power? It could be shown to the user in the same way as the little status message that says "cannot switch vessels while throttled up". Suggestions: "Cannot perform action. Out of electricity." "No electrical power available." "Not enough electrical power remaining." That way you still preserve that feeling of being a newbie making the "fun" first mistake of not putting rechargers on your ship (or not putting batteries on your ship), (which I think should be preserved as that is especially "Kerbalistic" to make that error once). But at the same time the first time a person makes the mistake they will immediately know what happened and why, without asking the same exact question yet again, "why did my controls stop working?".

A "hinge" that makes designs where the ship unfolds itself after launch possible.

The artwork for many parts is very similar, making it hard to tell which part is attached to the ship, and right now there's no way to tell. I propose either a tooltip popup with the part name when your mouse hovers over a part in the VAB that's ON your craft, or highlighting the relevant button over in the parts bin panel on the left when you hover the mouse over the part on the craft. Thus you can better tell if the part on the ship is THIS solar panel pack, or THAT one.. or if you have THIS engine or THAT one, etc. It's easy to claim that you should know what parts you put on the ship yourself, but if you save the game and come back to the design later, it could have been many days since you attached the part - plenty of time to forget.

But what you described is nowhere near complex enough to really program it. You need loops and branches. not just a list of unconditionally executed steps in sequence. As far as a dev console you can type into, no that's really easy to implement because it's just a standard-issue textbox widget that pretty much every gui toolkit comes with as a stock thing.

I wish that was true but it's not. Observe these screenshots: http://steamcommunity.com/sharedfiles/filedetails/?id=169658752 http://steamcommunity.com/sharedfiles/filedetails/?id=169659567 http://steamcommunity.com/sharedfiles/filedetails/?id=169659615 Here's a relevant example taken from the save file. Note that it's a debris vessel containing ONLY a strut and nothing else. My save has many of these. I can switch to them in the Tracking Station. VESSEL { pid = 2d4130b299c241508b93f4f98d2547ca name = Mun Goer 11 Debris type = Debris sit = ORBITING landed = False landedAt = splashed = False met = 3982.39184041321 lct = 85786812.3125162 root = 0 lat = -0.658813079901887 lon = 108.747547071118 alt = 138544.959881233 hgt = -1 nrm = 0.9004264,0.4326085,0.04563023 rot = 0.4730048,-0.5035616,0.5304846,0.491201 CoM = 0,0,0 stg = 0 prst = False ref = 0 cPch = 0 cHdg = 0 cMod = -1 ORBIT { SMA = 1101729.06506562 ECC = 0.367577347283327 INC = 1.0012453474191 LPE = 183.286812689452 LAN = 264.181807114909 MNA = 0.234916951893357 EPH = 85786890.9299516 REF = 1 OBJ = 1 } PART { name = strutConnector uid = 567817880 mid = 2941269206 parent = 0 position = 0,0,0 rotation = 0,0,0,1 mirror = 1,1,1 istg = 0 dstg = 0 sqor = -1 sidx = -1 attm = 1 srfN = None, -1 mass = 0.05 temp = -40.19031 expt = 0 state = 0 connected = False attached = False flag = dunbaratu/Flags/kspflag rTrf = strutConnector EVENTS { } ACTIONS { } } ACTIONGROUPS { Stage = False, 85786794.2325199 Gear = True, 0 Light = False, 0 RCS = False, 0 SAS = False, 85786782.6525224 Brakes = False, 0 Abort = False, 0 Custom01 = False, 0 Custom02 = False, 0 Custom03 = False, 0 Custom04 = False, 0 Custom05 = False, 0 Custom06 = False, 0 Custom07 = False, 0 Custom08 = False, 0 Custom09 = False, 0 Custom10 = False, 0 } }

Error cascades and gets bigger with each calculation. It doesn't take a lot for +/- 0.00001 to turn into +/- 0.0001 to turn into +/- 0.001 to turn into +/- 0.01 to turn into +/- 0.1 to turn into +/- 1.0 to turn into +/- 10.0 and so on. And it doesn't take difficult math, just repetitive math - the sort of things computers are VERY fast at doing.

I've twice now had people claim that strut remnants don't remain as persistent debris. But they DO. Here's a few screenshots of debris that exists IN the tracking center - I switched to them and took the screenshots. Each of these is a strut nub - I had to zoom in really close to get a good picture of them. I actually have lots more of these in my campaign save but I digured I'd just show screenshots of a few of them. http://steamcommunity.com/sharedfiles/filedetails/?id=169658752 http://steamcommunity.com/sharedfiles/filedetails/?id=169659567 http://steamcommunity.com/sharedfiles/filedetails/?id=169659615 Here's a relevant example taken from the save file. Note that it's a debris vessel containing ONLY a strut and nothing else. My save has several of these. VESSEL { pid = 2d4130b299c241508b93f4f98d2547ca name = Mun Goer 11 Debris type = Debris sit = ORBITING landed = False landedAt = splashed = False met = 3982.39184041321 lct = 85786812.3125162 root = 0 lat = -0.658813079901887 lon = 108.747547071118 alt = 138544.959881233 hgt = -1 nrm = 0.9004264,0.4326085,0.04563023 rot = 0.4730048,-0.5035616,0.5304846,0.491201 CoM = 0,0,0 stg = 0 prst = False ref = 0 cPch = 0 cHdg = 0 cMod = -1 ORBIT { SMA = 1101729.06506562 ECC = 0.367577347283327 INC = 1.0012453474191 LPE = 183.286812689452 LAN = 264.181807114909 MNA = 0.234916951893357 EPH = 85786890.9299516 REF = 1 OBJ = 1 } PART { name = strutConnector uid = 567817880 mid = 2941269206 parent = 0 position = 0,0,0 rotation = 0,0,0,1 mirror = 1,1,1 istg = 0 dstg = 0 sqor = -1 sidx = -1 attm = 1 srfN = None, -1 mass = 0.05 temp = -40.19031 expt = 0 state = 0 connected = False attached = False flag = dunbaratu/Flags/kspflag rTrf = strutConnector EVENTS { } ACTIONS { } } ACTIONGROUPS { Stage = False, 85786794.2325199 Gear = True, 0 Light = False, 0 RCS = False, 0 SAS = False, 85786782.6525224 Brakes = False, 0 Abort = False, 0 Custom01 = False, 0 Custom02 = False, 0 Custom03 = False, 0 Custom04 = False, 0 Custom05 = False, 0 Custom06 = False, 0 Custom07 = False, 0 Custom08 = False, 0 Custom09 = False, 0 Custom10 = False, 0 } }

Technically true, but I guess what I wrote isn't what I meant. Change it to plural. "Anything other than the current crafts are on rails anyway." The point is I was replying to someone who was trying to claim that this idea is going to have a problem because "you can theoretically have hundreds of ships with tens of thousands of parts flying around at the same time and this makes things difficult:". I doubt the "hundreds of ships" in that comment were all meant to be within 2.5 km of you. It was a comment claiming that there would be a problem because of ALL the ships in your campaign save. Thus my comment about how most of them would be on rails and thus this concern isn't valid.

RemoteTech would be a thing I'd use iff it had a good enough programming system that let me write code for the craft to follow for things like landings. That would feel appropriate for robotic missions. I don't know if I do or don't like the idea of it being standard though. Not all players of the game want to be programmers.

Yes, yes yes yes. And implementing would simply be a matter of saving "controllingPart: ...." and "targetThing: ...." as two settings saved per vessel. Each vessel would remember what those two settings were set to the previous time it was the primary vessel.

Is there a way to be certain how long it takes for the save to complete before you hit alt-F4? Killing the program in mid-save would have horrible consequences.

Do keep in mind though, that anything that's done for this needs to be done in a fashion that is deterministic and also rather course-grain (i.e. a part has maybe just 3 states: destroyed, damaged, and unscathed) rather than having some sort of slow continuous degradation of hit points. This is because one of the developers' design goals is absolute determinism. If it was humanly possible to exactly duplicate your own inputs with ultimate precision, then you'd get the exact same flight results each time you re-attempt the same flight the same way from the same starting circumstances. (in other words the only variation should come from the fact that it's not humanly possible to exactly duplicate your circumstances . The only sort of thing similar to randomness that's allowed is the sort of near-randomness that can come from a deterministic yet chaotic mathematical system. i.e. when you roll a die, it's technically deterministic rather than random but it only seems random because there's too many sensitive variables for you to humanly track or control.)

If you rightclick an engine and select "deactivate" while the throttle is up, leave the throttle where it is, then rightclick the engine again and select "activate", the engine powers up again right to the same throttle setting. So why not handle this proposed change that way instead? Have 'x' leave the throttle where it is and just deactivate the engine, and then when re-activating with whatever hotkey that ends up being (I'm not talking here about that part of the debate), the engines reactivate rather than the throttle setting changing. The throttle setting actually remains exactly where it is and you can still move it up and down with shift/ctrl while the engine is off (Just like you do prior to launch, where you bring the throttle up before activating your first stage usually.) You can move the throttle lever while no engines are active and the new setting will take effect the moment an engine turns on. The only difficult part here coding-wise is you'd have to track whether an engine is active or not with two different settings, like so: An engine is active if and only if: Whatever previous variables the code used to decide this setting (The staging list, and the ability to manually rightclick the engine to toggle it) say it's true, AND The new setting, something like "globalEnginesActive" is also on. Thus if you turn off globalEnginesActive, but leave the other variables alone as they are now, the engines all stop but the game still remembers which ones they were that were active. Then when you turn globalEnginesActive on again, the ones that fit the previous criteria start running again. Then the idea is that "X" toggles globalEnginesActive and that's all it does.

Also, as another thing - if such a thing was implemented it would also open up the possibility of adding an interesting new challenge to the game, that being that direct control of unmanned computerized spacecraft has an imposed lightspeed delay and if you want to deal with manual control of it, it requires you to control the craft ahead of time if it's far away. The idea I have for the interface for this is that you basically just set up maneuver nodes using the normal maneuver node interface, and then just say "do those manuevers please when the time comes". That might sound like it makes things easier, but keep in mind that I'm envisioning that because of the lightspeed delay, this is the ONLY way you're allowed to control unmanned probes. The manual flying interface is reserved for manned craft only under this proposal. The only thing you can do with an unmanned probe is: 1 - Tell it to perform manuever nodes at least N minutes from now where N is the lightspeed delay based on its distance. 2 - Tell it to activate one of its action groups at time T (which must be at least N minutes from now or later). That way to make an unmanned probe do anything really interesting, like LAND, you'd have to program it to do so by script prepared ahead of time. This would also have the effect of making the increased risk of manned missions perhaps more worth it. "Yeah it's a heavier payload, but at least with a pilot I'll be able to control the craft in real time." This will make the tradeoff between "should I do this unmanned or manned" become a real decision for the player to make that matters.

First off, in the interest of not trying to sidetrack Squad into an enormous project beyond their staff's available time, I'd vote an emphatic "no" to the suggestions to make the language have an in-game GUI development environment. The game interface should just first concentrate on being able to parse the language and execute it, limiting the UI to just something where you paste a block of code text, or upload a text file of code. If there's time later, then making a fancy GUI or IDE to help can be nice but really, that's an enormous project of secondary importance to actually having the feature work at minimum. Also, the language should be something that already exists so that external already existing IDEs can be used by people. What Squad should provide is just a place to attach the code to a vessel design, and the API for the code to call into. I envision for attaching the code to the vessel, that it be a thing you attach not to the vessel as a whole, but to the command module. Thus you have programming that can differ depending on which command module is selected with "control from here". And it makes thematic sense that the script is part of what's "inside" the core's computers. I have to say that I like this idea because the primary thing I dislike about using Mechjeb's autopilot is that it's an autopilot that just arrived fully formed as a gift from heaven. MY space program didn't have a hand in making it, or learning trial-and-error style, what's wrong with it to correct it for next time. If there was to be some sort of piloting system, it needs to have that "Kerbal" feel to it, and that means I should have the joy of knowing that if I screwed up the programming, it can have hilariously disastrous effects.

There is a mod with a "docking camera" that simulates the idea of a camera affixed to the docking port itself, which is how they do it in real world space docking. But I agree that this really needs to be in the default core game. I envision it being simply another camera mode you toggle through with the "V" key, and it only appears when you have selected "control from here" on one of your docking ports, then that docking port is the one you get a view from.

Thank you. This will come in handy.

Usually my problem is the opposite. I have a very tiny mass ship and find that I want a mode that 'nerfs' rotational power even MORE so than capslock does. Even under capslock I tap a WASDQE key just once and I'm already spinning at about 1 rev per two seconds or so.

I too find this annoying, but at the same time I wonder if the *real* problem at the root of this isn't the need to switch screens twice, but rather how SLOW those switches are. Would you be as annoyed by this if the Space Center screen came up rather quickly, and then the Tracking Station screen came up rather quickly? Perhaps the real fix should be "improve the speed of switching to/from the Space Center".

Uhm... anything other than the current craft is "on rails" anyway - and calculating where the object is "on rails" is *already* just a matter of plugging in a time for "t" to see where the formula says it ends up at time T. Basically to make the replay idea work, you need to store data position at time T only for those craft you focussed on. But then the problem is when you want to replay an explosion. suddenly you have LOTS of individual debris parts in range.