S1gmoid

Just so we're on the same page, it's not "create node, hit NODE, move node, vessel points in wrong direction". It's "create node, adjust node, hit NODE, vessel points in wrong direction". So when I'm "inputting" the node into the flight computer, it's already in its final state. It just feels weird, because normally the burn direction may change with adjusting the delta-V values on the node, and that gets sent correctly. It's just dragging the node from its original position that messes things up.

It might need some additional thought and testing around manned modules. Ie. does it make a manned module remote controllable. If it does, we should add electric charge consumption for game balance. If it doesn't, does it cause anything weird to happen. I'm still new to ModuleManager, maybe there is a way to tell it to only modify unmanned command modules. By the way, I noticed a bug in the flight computer. If you move a maneuver node after placing it, the flight computer still sets the original heading (which is usually quite wrong) when you hit "NODE". I've already started looking into the persistent computer commands thing, so I'll look around for the cause of this, but if any dev or contributor already knows what causes it and where to look, I'd love some guidance.

I'm not sure I understand what you are trying to do. A Vector3 that contain Euler rotations, or a Vector3 that contains a unit vector in 3-space?

Thanks, that should be helpful! There are two things I'm thinking of trying my hand at in relation to unloaded vessels. One is persisting the flight computer data from RT2 when the vessel is unloaded, and potentially create a warning when there is an upcoming event... Currently RT2 calls Dispose() on the flight computer class upon unload... The bigger one is a "better de-orbiting" functionality that would simulate atmospheric braking on unloaded orbiting vessels. I wanted to get rid of this piece of debris, went to great length to push it into a crash trajectory (verified with the Trajectories mod), only to watch it come straight back up from a periapsis of 40000 meters. So I decided this definitely needs some doing. I'm looking into possible codesharing with Trajectories, as I guess the logic is similar.

Hey This really is quite cool, though I guess it will take some practice, I have already managed to build planes that actually fly... Now all that's missing is procedural lifting bodies and I could build a Me 163 Komet. BTW since this pretty much obsoletes all other wings, I quickly put this config together to hide them, and make the Aero tab navigable again: // Squad: // tailfin @PART[tailfin] { %techRequired = Unresearchable %category = -1 } // sweptWing @PART[sweptWing] { %techRequired = Unresearchable %category = -1 } // SP+ : //connector1 @PART[wingConnector] { %techRequired = Unresearchable %category = -1 } //connector2 @PART[wingConnector2] { %techRequired = Unresearchable %category = -1 } //connector3 @PART[wingConnector3] { %techRequired = Unresearchable %category = -1 } //connector4 @PART[wingConnector4] { %techRequired = Unresearchable %category = -1 } //connector5 @PART[wingConnector5] { %techRequired = Unresearchable %category = -1 } //delta_small @PART[delta_small] { %techRequired = Unresearchable %category = -1 } //connector5 @PART[deltaWing] { %techRequired = Unresearchable %category = -1 } //elevon1 @PART[StandardCtrlSrf] { %techRequired = Unresearchable %category = -1 } //elevon2 @PART[elevon2] { %techRequired = Unresearchable %category = -1 } //elevon3 @PART[elevon3] { %techRequired = Unresearchable %category = -1 } //elevon4 @PART[smallCtrlSrf] { %techRequired = Unresearchable %category = -1 } //elevon5 @PART[elevon5] { %techRequired = Unresearchable %category = -1 } //strake @PART[wingStrake] { %techRequired = Unresearchable %category = -1 } //structural1 @PART[structuralWing] { %techRequired = Unresearchable %category = -1 } //structural2 @PART[structuralWing2] { %techRequired = Unresearchable %category = -1 } //structural3 @PART[structuralWing3] { %techRequired = Unresearchable %category = -1 } //structural4 @PART[structuralWing4] { %techRequired = Unresearchable %category = -1 } //swept1 @PART[sweptWing1] { %techRequired = Unresearchable %category = -1 } //swept2 @PART[sweptWing2] { %techRequired = Unresearchable %category = -1 }

Wow thanks. That really explains it. So data for a vessel needs to be stored into the protovessel when it is unloaded. Do protovessels have some kind of regular update function that is called on them, or are they just passive structures moved around until they are reloaded?

How is a vessel represented in warp / on rails?

Since you didn't mention any C#, or even JAVA or C++, I suggest you start by learning C# (.NET or Mono). From there on, I'm still out on a search for bits of information about KSP modding, and I practically dream in C# these days.

Hey. I've tried to understand KSP modding by reading mod code, but I feel I've reached a local ditch and I definitely need some background knowledge to proceed further. Mainly, what I'm looking for is an explanation of the main state machines of KSP, how a vessel gets loaded, put on rails, taken off rails, unloaded. What is preserved and what is deleted. How rails are stored and when and how can they be affected. The tutorials I've found so far seem to be very basic... and for example right now, for the life of me I cannot make heads or tails from this (from RemoteTech2): private void OnVesselOnRails(Vessel v) { if (v.parts.Count == 0) { RegisterProto(v); } } WHAT?! I mean, WHAT? Why am I cheking if there are any parts? Why am I only doing something if there aren't? What does it mean if parts.Count is 0, and what if it isn't? I'm looking for answers to this and a lot of similar questions.

One of my favorite mission types.

I haven't used 0.24.2 for too long, but my observation is that 0.25 is generally less stable, plugins or no. Still nothing as bad as to ruin my day, maybe a crash in every 5-6 hours played, so far no savefile corruption.

Ignored by the stock physics simulation. They are still represented, with their movement modeled through a simplistic orbital model ("on rails"), and can be accessed. There are mods out there that mess with on-rails objects. But that isn't even necessary I think. We'd only need to set the correct orientation upon load (ie. start of simulation). The real hard part is modifying the physics engine to actually keep the station tidally locked. Actually, there is already an ongoing attempt at doing n-body physics through replacing the stock gravitational model...

Actually, for me, outsourced R&D fixed the game. While I enjoy the progression and mission-driven feel of the career mode, I don't care much about the way science is implemented in the game. It's slow, tedious, and not fun one bit. With outsourced R&D and the soon-to-be-integrated Fine Print mod, I can now advance through completing meaningful contracts like setting altitude records, putting sattelites on given orbits, etc. Progress comes from advancing as a space program, as opposed to clicking on everything lots of times. There's a lot to be rebalanced in the game, from the tech tree to, yes, outsourced R&D. It could be less efficient. But for a change, I'm actually enjoying career mode again. Before trying this, I was about to move to Sandbox indefinitely.

None of us are. But for me, one of the main fun factors of the game is its educational aspect.

I already have that, it's the build experience that has me bogged for now. Though flying is also significantly harder than either X-Plane or Flightgear (both dedicated flight simulators, X-Plane with an FAA certificate for training), I'm still figuring out if it's the controls or my planes just suck. Anyway, I'm surprised you managed to launch that beast in the photo (if it's the FAR bundled big spaceplane), when I tried it, it pitched back onto its engines, nose in the air, and didn't budge an inch even at maximum thrust... (maybe it's AJE's fault...)

Okay sorry, I don't want to sound like a troll, but you are hard to read, and it's not particularly your English - it's quite good actually. It's your lack of structure and complete disregard of capital letters and punctuation. So here's what we're asking you to do... Instead of this... ...you could write like this: See what we mean?

I have "Mind Kerman", with a whopping ZERO stupidity.

I've been reading a lot of KSP mod codebase today, so I guess I'll look into it, and get back to you. Just persisting the state shouldn't be too much trouble, I guess. As for vessel switching and roundabout approaches... yea no matter what we do, unless we can run multiple instances of the Unity/KSP physics engine, I'm afraid this might still be the best solution. And while in the software industry, "it's not possible" usually means "it would require me to actively think for more than 10 minutes", there seems to be an awful hard consensus in the modding community and in Squad that this is not something that can be done while using Unity. I guess a simplified maneuver execution system could be implemented on rails... One that just takes the thrust vector and delta-v, and adjusts the orbit data accordingly (if the vessel has enough delta-v to execute the maneuver of course).

I'm on OSX too, and I have also encountered a few freezes, though quite far inbetween. But yes, my feeling is that it got less stable since 0.24, I hear they updated the Unity version. I hope it will be stabilized soon, Mac users are too often left out to hang in questions like stabilization.

Thanks. I already have FAR and AJE installed. Procedural wings looks cool, but it seems I need to wait until it gets updated for the newest FAR version. Does it include procedural control surfaces too? I'll definitely check it out. (BTW for the life of me I cannot understand why everything tries to attach in weird angles to wings... From landing gears through lights to control surfaces, everything wants to attach in the absolutely most weird way possible.)

Thanks all for the insight.

Is it just me, or are stock control surfaces completely broken? From what I gather, KSP just included a spaceplane mod, and still, building planes feels like trying to build something by fitting LEGO and Playmobile blocks together (actual experience from when I was a kid). I absolutely love the way you can build rockets in KSP... however, I've recently started experimenting with planes, and it's the total opposite. The control surfaces all feel like they were never meant to go on these wings. They are bulky, the wrong length, do not snap (or rather, snap the wrong way), and in the end, do precious little in actually controlling the plane (in my limited experience - ymmv). Honestly, it would be really cool if there were wings with built-in control surfaces. Or generally just some better wing+control surface solution. Any pointers?

Is there a generally accepted way to hide / disable certain parts via ModuleManager?

Hm... makes sense. I am completely new to Unity... anyway, from my previous experience I'd say that since we're talking about a game, normally I'd want to stay synchronized to the main loop anyway so I can update in time for each Vsync... for truly "parallel running" logic (though I'd be hard pressed to name any right now), I guess it might be best to utilize these synchronization points as uplinks and downlinks, ie. update UIs and gather data for the long-running thread...

I've been thinking today about how RT2 exacerbates the problems with KSP not being able to fully simulate multiple vessels at the same time. Stock KSP is all manual control, so you don't really feel the limitations... however, with RT2, imagine having an orbit around the sun, and wanting to execute a burn delayed by months after the last radio connection... The ideal solution I've come up with would need RT2 to persist delayed commands for all vessels, and integrate with Kerbal Alarm Clock to switch to those vessels to execute the actions. The only problem that can happen in this case is when this happens, you are in a critical moment with another vehicle, which would become unloaded / crash if you switched away from it. For that, I think a time-rewind mechanism similar to FMRS would be cool, to execute the actions after you're back at Space Center...