search

Nivekk / KOS

Fully programmable autopilot mod for KSP.
Other
80 stars 30 forks source link

Add scripting module to career mode tech tree #178

Open rnorris7756 opened 11 years ago

rnorris7756 commented 11 years ago

Since 0.22 has been out for a while I (and many other people) have been playing career mode. The KOS scripting module is currently not anywhere in the career mode tech tree. It would be nice to have it in career mode if that's feasible.

a1270 commented 11 years ago

It should be as simple as adding "TechRequired = NodeName" within PART{ } in part.cfg of the module. What NodeName should be is the tricky bit. MechJeb unlocks at flightControl which sounds reasonable to me.

Dunbaratu commented 11 years ago

Also, there has been talk about having more than one type of SCS at different technology levels to represent better computers with more power. Perhaps that should be put into the tech tree while the subject is being addressed: a slow one with small disks at first, then faster ones with bigger disks later. As far as the artwork for the different types of part - they can be identical 3D meshes but with different decal images for now and that would be fine to get the idea off the ground.

Nivekk commented 11 years ago

It's definately a tough call where to put this, I haven't touched the new career mode at all.

It feels like the R&D effort for planet Kerbin to come up with a programmable core would be a lot greater than that for a dumb probe core that presumably just works by remote control.

Having said that, it would suck if people had to wait a long time to use kOS, so I tend to agree with BiZZKeryear.

Dunbaratu commented 11 years ago

The Soviet space program was using "dumb" remote control from day 1 and they didn't have particularly good computers. The first man in space was just a passenger while all the control was done from the ground. (There were some crude on-board controls that were just functional enough to perform a seat-of-the-pants de-orbit burn, but they were just an emergency backup and not normally used. In fact the cosmonaut would have to type in an override security code to unlock the manual controls. They were only to be used if the remote control was malfunctioning.) Analog electronics are good enough to accomplish a simple "set the throttle to this setting and hold it there for this length of time and then turn it off." sort of command.

For gameplay reasons it might make sense to let it work where the first probe core appears, but the argument that it should be that way for realism reasons doesn't work.

palaslet commented 10 years ago

I agree with Dunbaratu. There should be more than one level of SCS. They could also have different performance. By putting tech-level specific "sleeps" in the code of expression evaluation and command execution, one would have to write programs that don't overload the CPU (ref. Apollo 11 - http://en.wikipedia.org/wiki/Apollo_Guidance_Computer#PGNCS_trouble). Possible tech levels might be:

  1. Auto control only. Set throttle, wait for a specific amount of time. set steering to vector (not targets, prograde etc.). So you'll need to either do some precalculation to get your timings correct or you'll need to do lots of trial and error.
  2. Possible to get vessel data. Speed, altitude etc. possible to act on vessel data with "wait until" etc. Severe performance restrictions on expressions, so they need to be simple (possibly at the cost of accuracy)
  3. Better expression performance. NODE capability. TARGET only on celestial bodies possible. data input from SENSORS (parts with modules of type "ModuleEnviroSensor". as of 0.22 this includes "Double-C Seismic Accelerometer", "PresMat Barometer", "GRAVMAX Negative Gravioli Detector" and "2HOT Thermometer")
  4. Best expression performance. Full functionality: TARGET data (targeted vessels data is restricted by antenna bandwidth, and not possible without antenna).

Note: The modules named "ModuleEnviroSensor" will have a "sensorType", This can be used to identify the data needed to be injected. So no need for actual interaction with other KSP parts to get the data.

MaHuJa commented 10 years ago

Or you could enable capabilities depending on the tech tree, like once you get tech X you can use linear rcs commands.

I'm not convinced that it's a good way to go, though.

Right now user scripts can be copied to a similar craft and it'll just work. When you suddenly have dependencies - which may only be checkable in mid-flight - you're adding frustrating hoops/barriers rather than fun challenges.

Contrast to: (once tech X has been researched, do/allow...)

Dunbaratu commented 10 years ago

I like the idea of a disk drive part that is nothing more than storage for other SCS modules to use. But the way the kOS code is structured at the moment I think disks are attached to CPU's. so you'd have to implement it as a part that includes a sort of "null" CPU that refuses to run anything.