[1.3] kOS Scriptable Autopilot System v1.1.3.0

[erendrake]

That would explain a lot. Does that mean there currently is no way of getting sensor data? That throws a spanner in my ascent script work

I tried getting it via the rightclick menu method, but that yields exactly the same result - and I guess that is the cause of the problem in the first place.

The root issue is that the value that the ModuleEnviroSensor uses is a string. I guess we would have to teach kerboscript how to coerce types

- - - Updated - - -

I'm not fond of the idea either. I'm just thinking of ways to solve the "detect that no manual control happened" condition for a contract, without penalizing you for accidentally tapping a key.

I had the idea of a flag you could set on the craft that was "lock controls" to disable direct input from the user. that would be easy enough to build and watch to insure the user had no control?

[Dunbaratu]

Yeah it's really really annoying, because the ability exists for it to have been implemented to split out the string display from the actual number under the hood (i.e. a thermometer saying "120C" would have the number 120, with the field's unit label set to "C"). I know this because I did that for LaserDist - when it says something like "1,200,102m" in the display, the number is actually just an integer 1200102, and the conversion of that into a display string happens in a side routine. But sadly, it looks like the ModuleEnviroSensor was never implemented that way.

The ugly thing is that it's not JUST a matter of parsing the string to an int. We also have to know about units because the same sensor could switch units (i..e it would have to be smart enough to know that 4.5km is a bigger number than 50m despite the fact that 4.5 < 50).

[Camacha]

The root issue is that the value that the ModuleEnviroSensor uses is a string.

I feared as much. A matter of a simple problem needing a complex solution, so it seems.

I had the idea of a flag you could set on the craft that was "lock controls" to disable direct input from the user. that would be easy enough to build and watch to insure the user had no control?

I envisioned something like a slider in either the kOS menu or the console - I prefer the menu. Slide to unlock

Oh, speaking of the menu - I am still having issues with it not showing, even in a fresh installation. KSP just says No target and never or rarely shows the actual menu. If I have a spare hour I will try to make a short video that shows the behaviour.

[undercoveryankee]

Let's brainstorm. Contract Ideas from YOU

If we added kOS contracts to the game for career mode, what contract conditions would be good?

I'd prefer "do something that kOS is the obvious way to do" over "do something with manual controls locked out" as much as possible. None of the stock contracts really care what approach you take if you get the specified payload to the specified place.

[Dunbaratu]

I'd prefer "do something that kOS is the obvious way to do" over "do something with manual controls locked out" as much as possible. None of the stock contracts really care what approach you take if you get the specified payload to the specified place.

I waffle back and forth on this one. On the one hand I like that approach, but on the other hand there's a lot of stock contracts that by all rights SHOULD be the sort that would need computer control and the only reason you can accomplish them manually is because the KSP simulation doesn't track signal delay. By all rights "try to land an unmanned probe on Duna" should be just like "try to maintain altitude within 5m error" - without explicitly saying it, it would be nearly impossible without a computer to help. But maybe that's more in remotetech's baliwick rather than ours.

But I think where the most 'help' is needed in the contracts is really for the low-level building blocks that go into making the autopilot software - the early stuff. What I'd like to see is to allow you to, say, practice your landing software on Kerbin with a small test craft, with a chance of getting some of that money back that you spent on launching a test vehicle and trying it again and again until it worked. For things like that, it's almost mandatory that there be a test for "make sure you're not doing it manually" - because otherwise they're trivially easy to do.

This is why I put it out for public comment. I'm really indecisive about it. I can see the arguments both ways.

- - - Updated - - -

I envisioned something like a slider in either the kOS menu or the console - I prefer the menu. Slide to unlock

The controls are fed to the vessel as a whole, not just to one of its parts. So we'd need a rule for what it means for one SCS part on a vessel set to lock and the other set to unlock.

[undercoveryankee]

I waffle back and forth on this one. On the one hand I like that approach, but on the other hand there's a lot of stock contracts that by all rights SHOULD be the sort that would need computer control and the only reason you can accomplish them manually is because the KSP simulation doesn't track signal delay. By all rights "try to land an unmanned probe on Duna" should be just like "try to maintain altitude within 5m error" - without explicitly saying it, it would be nearly impossible without a computer to help. But maybe that's more in remotetech's baliwick rather than ours.

I'd love to see probe-landing contracts that appeared only if

1. RemoteTech is present,
   
2. RemoteTech signal delay is enabled, and
   
3. kOS is available.
   

And it would need a check that the lander doesn't have a MechJeb module on it as configured for landing.

But I think where the most 'help' is needed in the contracts is really for the low-level building blocks that go into making the autopilot software - the early stuff. What I'd like to see is to allow you to, say, practice your landing software on Kerbin with a small test craft, with a chance of getting some of that money back that you spent on launching a test vehicle and trying it again and again until it worked. For things like that, it's almost mandatory that there be a test for "make sure you're not doing it manually" - because otherwise they're trivially easy to do.

Contracts where part of the reward is the reward, and the other part is a library of scripts you'll be able to draw on for future missions. That could be a great teaching tool for doing things with kOS.

The controls are fed to the vessel as a whole, not just to one of its parts. So we'd need a rule for what it means for one SCS part on a vessel set to lock and the other set to unlock.

I'd lean toward "when you change the state on one SCS part, look for any others on the vessel and automatically change them to match." You might still find a way for a conflict to exist for a frame at a time, but the conflict resolution rule doesn't have to be as user-visible. What happens if two SCSes try to "LOCK STEERING" to different directions at the same time?

[madlemur]

Here's a thought (that might require some experimentation): Create kOS probes that have no tech requirements. Have contracts be to test them. If there's no tech requirements, they never get unlocked for career game use, but you should still be able to force them into availability for the contract. "Test our highly experimental Self-Piloting, Autonomous, Zaftig Zan (SPAZZ) by programming and executing a mission from the KSC to ______ with the following conditions: ..." Bonus points if you can "break" the probe part modules to prevent communications/control of the core. Also, max crew size of 0.

[CaptainKipard]

Have you guys thought about talking to TeacherGaming about kOS to go with KerbalEDU?

[kcs123]

- making kOS integrated within each command module could solve several problems with detection if some craft is debris or valid plane/rocket - similar how Dennis6492 have embedded MechJeb2 in each command module. You will no longer need separate part just for functional kOS, saving some memory for other mods too. Whoever use kOS mod will most probably want it on each craft, like I still depend a lot on MJ (using it mostly for maneuver node creation, MJ don't like FAR much ), so having it automaticaly embedded in each command module makes craft design less tedious when you need to save kOS part from aerodynamic forces or high temperatures on deadly reentry.

Here is how module manager config for embedding MJ looks like, maybe you can use similar way for kOS. Advantage is that it doesn't change any parts, so any craft is still functional if you remove kOS from your game, except that kOS script will no longer be available and whenever kOS is updated, it will be updated for each craft in game. Dennis have also included locking/unlocking MJ modules as player have unlocked science technology, don't know if that is needed for kOS

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final
{    
    MODULE
	{
	name = MechJebCore
		MechJebLocalSettings 
		{
			MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
			MechJebModuleSmartASS { unlockTechs = flightControl }
			MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
			MechJebModuleNodeEditor { unlockTechs = advFlightControl }
			MechJebModuleTranslatron { unlockTechs = advFlightControl }
			MechJebModuleWarpHelper { unlockTechs = advFlightControl }
			MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
			MechJebModuleThrustWindow { unlockTechs = advFlightControl }
			MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
			MechJebModuleRoverWindow { unlockTechs = fieldScience }
			MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
			MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
			MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
			MechJebModuleDockingGuidance { unlockTechs = advUnmanned }
			MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
			MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
		}
	}
}

- that solves one part of problem, to solve unwanted control input, kOS shuld have command like "LockPilotInput/UnlockPilotInput". Contract could be considered as fullfilled only if lock pilot controls is not toggled until all contract condition is accomplished.

- As Cpt.Kipard mentioned, it will be good to talk with people working on KerbalEDU. Beginners contracts should be in a manner to teach new players how to write simple programs. Once some simple contracts are fullfiled, it should not be longer available on contract board, just like reach 10 km altidute contract is no longer available once you go above that limit. That will solve abusing simple contracts for grinding more and more money.

Most of kOS users already have some basic knowlage in programing and found kOS as valuable mod, for beginners contracts should have some simple tasks that will be doors in secrets of programing. Advanced users could find this kind of contracts tedious, but for them could be another featured contracts that will teach them on kOS specific commands/syntax - how to reach certain craft values, what is available to read, what can be modified and what not, etc.

There could be contract that offers complete scripts, but with errors in it, so player have to find errors, correct them and build suitable craft that will make that kOS script usable.

So, to some degreee, contracts could be used as going trough kOS documentation, but not trough reading those, but rather to find it inside game. More fun to learn stuff from playing.

Hope that this helps in decisions.

[amiavamp]

As a caveat to my answers, I haven't written my rendezvous script yet (having only just started playing with kOS in the past few days), but have been delving into the maths for my arbitrary-plane-orbit matching script (to fulfill the 'place x satellite' contracts).

I assume you are talking about total deltaV, because the deltaV needed at the node at the start of the burn is the difference between the initial velocity at the burn position, and the velocity of the transfer orbit at the burn position.

1. As with an awful lot of the maths involved, the answer is "It doesn't have to be a circular orbit, but it makes things much much simpler"

2. You can get the true anomaly from the orbital parameters, and translate between the two orbits (a lot easier if you match planes first).

3. This sounds right - for a circular orbit, where the SMajorA == r. I'd assume it's possible for eccentrics, but you are no longer orbiting at the central point so it might be harder. Since you need the initial and final radii to calculate the velocities anyway, probably just easier (and less error prone) to use a_xf = (r_i+r_f)/2 (remembering to account for body radius).

4. As you have probably seen a reference to before - http://www.braeunig.us/space/ is a useful resource for this sort of thing, particularly http://www.braeunig.us/space/orbmech.htm (frustratingly spare on certain details, but certainly the best repository I have come across online thus far). Equations 4.43-4.45 are probably what you are looking for here, but again - with a circular orbit it is much simpler - the velocity and altitude are constant across the entire orbit. It might be worth getting the script working in the simplest case (circular) first, then elaborating it.

5. You only need to use iterative et al methods to go from mean -> eccentric anomaly, which you don't need to do because you have the true anomaly available. The above reference only gives the cosine part, which isn't enough to get a full value (arccos only gives the result in one quadrant). Following https://en.wikipedia.org/wiki/Eccentric_anomaly#From_the_true_anomaly, you can get the eccentric anomaly E from E = ARCTAN2(SIN(E),COS(E))

6. Don't completely understand the question, but if you have a maneuver node set up you can pull it's vector from kOS? Or, the blue handles that hang off the node? They are radial burns, so 90 degrees to prograde, in the plane of the orbit.

7. Hey, if you didn't want to really follow http://xkcd.com/1356/, then you would have just installed mechjeb and been done with it!

The difficulty is that I don't have access to parameters such as true anomaly at the start and end locations of the transfer - although, I believe the true/mean/eccentric anomalies at the end point would be 180 degrees since it is an apoapsis. The only parameters that I have to start with are the apoapsis and periapsis of my orbit and that of my target. Everything else must be calculated from this. Many of the equations that I've seen require knowing either the velocity or radius at a given point, but those are the values that I am searching for. A lot of textbook questions that I've seen seem to assume that the orbits in a coplanar transfer are circular, or that the person doing the transfer knows what their start and end altitudes are before beginning.

I've now finally gotten to the point where the hohmann transfer itself is calculated to correctly have its apoapsis tangent to the target's orbit even at a long distance, at least for circular orbits. However, now the issue is that I can't get it to actually intercept the target. It seems that the script doesn't properly compensate for the fact that the target is orbiting at a different speed than myself. When the time to burn is calculated to be negative, my orbital period is added to make it wait another orbit. However, the target is not at the same location when I complete an orbit. I'm really not sure how to tackle this issue. Kerbal Engineer Redux seems to be able to calculate the total phase angle to the target including the number of orbits needed with 360 degrees as the denominator even though 1 degree on this readout is less than 1 degree on the interceptor's orbit.

EDIT: Scratch that, I have fixed the issue of waiting for the correct time. The calculations are still woefully inaccurate, though. The intercept is typically about 80+ km off if the orbits aren't very close together. I'm about to scrap this idea if I can't get any closer.

I have a few more questions to anyone willing to answer:

Can kOS read the "target" velocity information as it appears above the navball when clicking the velocity indicator there? If not, how would I go about creating a script that zeroes one's velocity relative to another vessel?

Edited December 31, 2014 by amiavamp

[VentZer0]

Is there a ETA for the update release? I really need the ship:facing:starboard stuff *_*

[Camacha]

Is there a ETA for the update release? I really need the ship:facing:starboard stuff *_*

Do you mean the things in the video Steven posted? Those are available already in the beta release

[Dunbaratu]

Can kOS read the "target" velocity information as it appears above the navball when clicking the velocity indicator there? If not, how would I go about creating a script that zeroes one's velocity relative to another vessel?

I thought about it but deliberately left it out because it's JUST a vector subtraction, and it's a better teaching tool to make people understand how to do vector subtraction and how useful it is for translation to new "origins".

All you have to do is subtract myship:velocity:orbit from othership:velocity:orbit to get the relative velocity vector between the two.

I can't speak for erendrake here but I'm reluctant to add something like a target:relvelocity just because I see the ability to make TARGET have special abilities that other ships don't get to have as really being in the realm of manual piloting to help give visual aids to the pilot. To the autopilot, why give TARGET any special abilities that the other VESSEL("some name")'s don't get to have too? Just make it part of the generic interface you can use on ANY vessel. There may be a use for VESSEL:RELVELFROM(otherVessel), but that would *really* just be subtracting one vessel's velocity from the other.

- - - Updated - - -

Have you guys thought about talking to TeacherGaming about kOS to go with KerbalEDU?

While it would really be cool... at the same time I don't know if kerboscript is a good enough language for that purpose. Maybe it could become such, but at the moment the fact that you can't even write a callable function sort of limits how much it can be used to teach children about good programming practices.

[VentZer0]

Do you mean the things in the video Steven posted? Those are available already in the beta release

oh YESSSSSSSSSSSSSSSSS *_*

btw is there progress on local variables?

Edited December 31, 2014 by VentZer0

[Camacha]

While it would really be cool... at the same time I don't know if kerboscript is a good enough language for that purpose. Maybe it could become such, but at the moment the fact that you can't even write a callable function sort of limits how much it can be used to teach children about good programming practices.

I would not undersell what you already have Though I do agree that some of the peculiarities might be troublesome for newcomers, it certainly is a very powerful learning tool. Programming often is somewhat dry if you are just getting started, but combining it with an environment like KSP can make it very exciting indeed.

I locked myself inside for an entire summer just to program broken versions of Block Breaker and Pong in Qbasic. If I would have had something like this, who knows how long I would have gone without seeing the sun

[erendrake]

I would not undersell what you already have Though I do agree that some of the peculiarities might be troublesome for newcomers, it certainly is a very powerful learning tool. Programming often is somewhat dry if you are just getting started, but combining it with an environment like KSP can make it very exciting indeed.

I locked myself inside for an entire summer just to program broken versions of Block Breaker and Pong in Qbasic. If I would have had something like this, who knows how long I would have gone without seeing the sun

I agree, while it is not a perfect language it could be useful for teaching many programming basics. If teaching proper programming was a goal, ruby wouldn't be so common in education. /flameon

[Dunbaratu]

oh YESSSSSSSSSSSSSSSSS *_*

btw is there progress on local variables?

Local to what? I've thought that local variables sort of need function calls first.

- - - Updated - - -

I agree, while it is not a perfect language it could be useful for teaching many programming basics. If teaching proper programming was a goal, ruby wouldn't be so common in education. /flameon

Well, that's a good point. I remember when college courses were taught in mostly Pascal (that will date me). And that was a terrible language. The problem is that while Pascal made it hard to write bad code, it ALSO made it hard to write good code. The exact reasons why are off topic here. (This is where I just deleted two paragraphs of verbose crud here before posting.)

It might be worth thinking about, that's true. One thing that KerbalEDU would make me do is change my thinking about what the nextmost important topic for me to work on would be.

Up until now I've thought that once 0.90 is fully squared away the next enhancement to kOS I should devote time to should be the remotable terminal, which also brings with it keyboard input/output (they're sort of tied together into the same code).

But if kerboscript were to become an educational tool, then maybe proper function calls really should come next.

But yeah, the more I think about it, one of the big problems with trying to teach kids to program is how early textbook examples are all doing something really really boring to a kid. No kid gives a darn about averaging numbers, or finding the areas of circles, or balancing a checkbook. But I started learning on my dad's Commodore 64 in the basement in the 1980's (again, dating myself here) and one of the first major things I made was a BASIC program to do a little Zork-like text adventure. Granted it wasn't a very good text adventure, but it caused me to learn some programming design patterns that I didn't even realize HAD already been well described and had been given names (i.e. I first made the rooms map as a giant 2D array where most of the locations were dummy (i.e. to go north from room(4,5) you end up at room(4,4), decrementing the second index of the array). But this was really inefficient and ate up all the memory fast as I grew the adventure and made the map bigger and bigger. Most elements of the array were dummies representing "there is no room here" (this was in early basic, where you really can't have null placeholders). So I reworked it into a set of parallel 1-D arrays, one called "N", one called "E", one called "S" and so on. If S(4)=7 what that means is going south from room 4 will land you in room 7. E(5)=-1 meant that you can't go east from room 5. I had no idea that what I'd just done was actually a design pattern that had a name and was called "implementing the edges of an N-way graph packed inside parallel arrays." I also didn't know that implementing an array of structures, in a language that doesn't really have structures, by instead making a lot of parallel arrays each to hold one of the fields of the "structure" is also what I was doing, and was a known technique. I'd never heard of 'nodes and edges' and I'd never heard of a 'struct'. My 12 year old brain was just trying to make the game work and it looked like a way that might work, and I had naively thought I'd just come up with something brand new all on my own.

As I think back on that.... I am starting to think that it could be pretty cool for a grade school to be teaching some basic programming by having the kids do something FUN with it like fly a Kerbal Space rocket.

"Tricking" a kid into learning while doing something fun is a great idea, and yeah, having kids play around with a problem for a while trying to find their own solution before you hand them one makes it stick a LOT better. You'll remember the teaching better if it was dealing with an area you were just trying to think your way through on your own. Then you better understand why the solution is doing what it's doing.

Edited December 31, 2014 by Steven Mading

[VentZer0]

Local to what? I've thought that local variables sort of need function calls first.

Local to the vessel, I had to crafts using the same programm, executed an volume 1 from each craft and their behavior at points were VERY weird

You answered my next question already, there is no way I can have 2 scripts running on the same craft at the same time, right?

Or what happens if I have a 'run xyz.' in my program that executes a special portion of code and then what happens when it ends, does it continue with the program it was called from ?

[Dunbaratu]

Local to the vessel, I had to crafts using the same programm, executed an volume 1 from each craft and their behavior at points were VERY weird

Variables already should be local to the vessel. If you found a case where a script running on one vessel causes a change to a variable on a different vessel, then that's a really major bug. The only exception to this is the CONFIG: variables, which are written out to kOS/Plugins/PluginData/kOS/config.xml and affect the entire plugin. Every OTHER variable should only exist on the one vessel that's running it (more so, it should only exist on the one SCS part that's running it. Two kOS computers on the same vessel should have their own distinct set of variables from each other).

You answered my next question already, there is no way I can have 2 scripts running on the same craft at the same time, right?

You could if you put two SCS parts on the same vessel. I have not yet tried to see what happens if you try to put both of them in control of their shared vessel, and give them opposing commands (like having one LOCK STEERING TO PROGRADE while the other one does a LOCK STEERING TO RETROGRADE.) I have no idea what that would do. I never tried it. I'm thinking most likely both would try to tell KSP how to set the ship controls, and KSP would end up obeying whichever set of controls it was told about last, effectively ignoring whatever the first one said to do.

Or what happens if I have a 'run xyz.' in my program that executes a special portion of code and then what happens when it ends, does it continue with the program it was called from ?

One program can call another program (you can use the RUN command from inside a program). And that's a LITTLE bit like having function calls...uh.. sort of. All variables OTHER than the parameters passed to the RUN command are global, though, which is the thing I thought you were talking about.

[Entropius]

I'm attempting to setup all my mods for KSP 0.90. And in the process, I've noticed a glitch that I think might be due to kOS (0.15.4) but I'm not totally certain.

I load or quickload a vessel in orbit, and (sometimes) the ship seems to split in 2. A look at the log says there's a structural failure between "CX-4181 Scriptable Control System" and some other part (sometimes a solar panel, sometimes a fuel tank). The ESC menu to go back to the KSC can appear, but often fails to actually do anything when buttons are clicked. And the log seems to have a lot of NullReferenceException spam at some point.

Since the kOS Scriptable Control system seems to be the constant in the structural failures that preceded all this, I'm guessing kOS was the cause. Further fueling my suspicion that it's kOS was the fact that when I removed any kOS parts from the craft, I didn't have a single incident. I'm curious if anybody can prove or disprove it though. Logs are available here: https://www.dropbox.com/sh/jlyvawfapoglucz/AACv8Sk52qi1gZmYDqqA7NBKa?dl=0

[Dunbaratu]

I'm attempting to setup all my mods for KSP 0.90. And in the process, I've noticed a glitch that I think might be due to kOS (0.15.4) but I'm not totally certain.

I load or quickload a vessel in orbit, and (sometimes) the ship seems to split in 2. A look at the log says there's a structural failure between "CX-4181 Scriptable Control System" and some other part (sometimes a solar panel, sometimes a fuel tank). The ESC menu to go back to the KSC can appear, but often fails to actually do anything when buttons are clicked. And the log seems to have a lot of NullReferenceException spam at some point.

Since the kOS Scriptable Control system seems to be the constant in the structural failures that preceded all this, I'm guessing kOS was the cause. Further fueling my suspicion that it's kOS was the fact that when I removed any kOS parts from the craft, I didn't have a single incident. I'm curious if anybody can prove or disprove it though. Logs are available here: https://www.dropbox.com/sh/jlyvawfapoglucz/AACv8Sk52qi1gZmYDqqA7NBKa?dl=0

I've suspected for a while now that there's something off about the SCS part model's coordinates. I've noticed that when I attach two of them stacked together, there's visual texture "garble" at the spot where they join, as if their join point was actually being overlapped.

The problem is that when we took over from Kevin Laity when he went missing, the only thing that was checked into the GPL3'd source code was the EXPORTED model file for the SCS part, not its original Unity source file. This makes it a bit hard to pull it into the unity editor and have a look at it. (It's a bit like trying to fix a bug in a mod when all you have is the compiled DLL file and not the source CSharp files.)

(Basically, KSP uses its own homebrewed model files that it *exports* from Unity and has you put into you plugins. This is generated by a tool SQUAD provides to modders called their "PartTools" unity exension. If all you have is the result of that export, and not the original files unity read, then I'm not sure how to actually look into the problem.)

It may be the case that solving it will require just ditching the current part model entirely and making new ones from scratch. My problem is that this gets into an area I know very little about. My training is on the programming end of things, not the graphic design end of things.

[Snoman314]

I'm attempting to setup all my mods for KSP 0.90. And in the process, I've noticed a glitch that I think might be due to kOS (0.15.4) but I'm not totally certain.

I load or quickload a vessel in orbit, and (sometimes) the ship seems to split in 2. A look at the log says there's a structural failure between "CX-4181 Scriptable Control System" and some other part (sometimes a solar panel, sometimes a fuel tank). The ESC menu to go back to the KSC can appear, but often fails to actually do anything when buttons are clicked. And the log seems to have a lot of NullReferenceException spam at some point.

Since the kOS Scriptable Control system seems to be the constant in the structural failures that preceded all this, I'm guessing kOS was the cause. Further fueling my suspicion that it's kOS was the fact that when I removed any kOS parts from the craft, I didn't have a single incident. I'm curious if anybody can prove or disprove it though. Logs are available here: https://www.dropbox.com/sh/jlyvawfapoglucz/AACv8Sk52qi1gZmYDqqA7NBKa?dl=0

Yeah it's totally messed up for me as well. The scs parts fall off the rocket on the launchpad, but still remain part of the rocket. It's really weird. I've just added kOS modules to all capsules and abandoned the kOS parts.

- - - Updated - - -

It may be the case that solving it will require just ditching the current part model entirely and making new ones from scratch. My problem is that this gets into an area I know very little about. My training is on the programming end of things, not the graphic design end of things.

That brings up the tantalising prospect of new parts in the future, that get upgrades as the tech tree develops. I hope you find a modeller to help out!

[VentZer0]

Variables already should be local to the vessel. If you found a case where a script running on one vessel causes a change to a variable on a different vessel, then that's a really major bug. The only exception to this is the CONFIG: variables, which are written out to kOS/Plugins/PluginData/kOS/config.xml and affect the entire plugin. Every OTHER variable should only exist on the one vessel that's running it (more so, it should only exist on the one SCS part that's running it. Two kOS computers on the same vessel should have their own distinct set of variables from each other).

You could if you put two SCS parts on the same vessel. I have not yet tried to see what happens if you try to put both of them in control of their shared vessel, and give them opposing commands (like having one LOCK STEERING TO PROGRADE while the other one does a LOCK STEERING TO RETROGRADE.) I have no idea what that would do. I never tried it. I'm thinking most likely both would try to tell KSP how to set the ship controls, and KSP would end up obeying whichever set of controls it was told about last, effectively ignoring whatever the first one said to do.

One program can call another program (you can use the RUN command from inside a program). And that's a LITTLE bit like having function calls...uh.. sort of. All variables OTHER than the parameters passed to the RUN command are global, though, which is the thing I thought you were talking about.

I see, so the individual SCS parts act as if they are an independent system? One variable called the same thing running on 2 different SCS parts will not interfere? Good then I should have no problems in theory.

In the context of using run/function calls what do you mean with global here, global for the SCS meaning a variable set in the main program and a variableset within the run/function called the same, will override the first one for this SCS part or all of them in universe?

[Dunbaratu]

In the context of using run/function calls what do you mean with global here, global for the SCS meaning a variable set in the main program and a variableset within the run/function called the same

Yes that.

If program 1 does "SET X TO 5." and then runs program 2, and program 2 does a "SET X TO 10" then, there was only ever 1 "X", and Program 2 just changed Program 1's X from 5 to 10. I mean global in that sense.

However, is there is ALSO a variable X on a completely different SCS part, then it shouldn't be affected.

[Entropius]

I've suspected for a while now that there's something off about the SCS part model's coordinates. I've noticed that when I attach two of them stacked together, there's visual texture "garble" at the spot where they join, as if their join point was actually being overlapped.

Based on the description of the "garble", maybe what you're seeing is Z-fighting?

The problem is that when we took over from Kevin Laity when he went missing, the only thing that was checked into the GPL3'd source code was the EXPORTED model file for the SCS part, not its original Unity source file. This makes it a bit hard to pull it into the unity editor and have a look at it. (It's a bit like trying to fix a bug in a mod when all you have is the compiled DLL file and not the source CSharp files.)

I personally doubt the model is the problem since I'd like to think that if old part models were causing new problems, we'd see it happening among more part-mods. And more importantly, why didn't the part simply explode? (rather than causing NullReferenceExceptions and non-working GUI buttons?) I'm fearful that the structural failure may be a symptom of something deeper.

But nonetheless, if we don't have the original raw files for creating a part, I'm inclined to say we need a new part model anyway, if for no other reason than ensuring complete control over all parts of kOS. (I've always felt the 2.5 m part should be a bit thinner anyway…)

It may be the case that solving it will require just ditching the current part model entirely and making new ones from scratch. My problem is that this gets into an area I know very little about. My training is on the programming end of things, not the graphic design end of things.

While I'm skeptical that'll be the solution, I hope it will be. A quick-n-dirty way to try this may be to make a MM config that replaces the SCS part model with the stock 2.5 m probe core model. If that works, then keep it that way until we can cook up a new custom model. I'm sure if we put out a call for modelers, somebody will oblige.