Can we get more sample .ks files?

[noiredd]

Can we get more sample .ks files?

[mikezm]

In the hangar, if you set the tag of the specific engine you want, you can then do:
say you tag the centre engine with the name "centreEng"

local centreEngine to ship:partsdubbedpattern("centreEng")[0]. // vessel:partsdubbedpattern() returns an array of all matching parts so if you have a unique tag name, you can assume you'll only need the first element in returned array. 

ship:partsdubbedpattern() will match against the name of the part or the tag assigned to the part in the hangar.

you can then do things like:

centreEngine:activate(). 
centreEngine:shutdown().

https://ksp-kos.github.io/KOS/structures/vessels/engine.html

Engines get handled in a specific way in kOS. If you need to, say, target a specific solar panel you can use the same ship:partsdubbedpattern() to find the part, then use:

local solarPanel to ship:partsdubbedpattern("SolarPanelTag")[0].
for mod in solarPanel:modules {
  local m to solarPanel:getmodule(mod).
  for event in m:alleventnames print event.
  for action in m:allactionnames print action.  
}

and to be safe when triggering an action:

local solarPanel to ship:partsdubbedpattern("SolarPanelTag")[0].
for mod in solarPanel:modules {
  local m to solarPanel:getmodule(mod).
  for action in m:allactionnames {
    if action:contains("extend") {
      m:doaction(action, true). 
    }
  }
}

Calling a standard action for a part requires that you have the exact action name. The method above lets you find any action that contain the word extend and will use the correct action without having to know exact text of the action.

caveat: I wrote this all up from memory so I apologize if I got some of the code incorrect but hopefully this helps you along

[mikezm]

You can also check out RAMP, which is what I use instead of PEGAS for a more stock KSP game.

The first two functions in here https://github.com/xeger/kos-ramp/blob/master/lib_parts.ks
partsDoEvent and partsDoAction get into a bit more detail about this.

[Indo-Scythian]

Thanks for the help. I was hoping to use "engineShutdown" in PEGAS itself as outlined in the tutorial, but it never goes into detail about it.

Do you have any other recommended accent guidance systems? I recently switched over from stock to RO and RSS.

[mikezm]

Sorry, man. I haven't looked too much for any alternative guidance systems meant for RO/RSS.

I've followed the PEGAS page for a while now, but don't use it for my game play. That said, I have "borrowed" a few PEGAS functions here and there but mostly for orbital maneuvering and calculations.

I do see what PEGAS is doing here for what you're looking to accomplish.

It looks like the code exposes a lexicon of functions in the global variable: availableCommands
at the bottom of this file: https://github.com/Noiredd/PEGAS/blob/d04a3901d3742c977dbb4bf992662e020c508d78/kOS/pegas_comm.ks

availableCommands["engineShutdown"] uses the delegate function: command_engineShutdown

GLOBAL availableCommands IS LEXICON(
	"setUpfgTime", command_setUpfgTime@,
	"engineShutdown", command_engineShutdown@,
	"setThrottle", command_setThrottle@
).

Going up to the function command_engineShutdown shows that the required parameter is a list of tags for the engines you want to activate/shutdown.

All told, it looks like you'd use the PEGAS function like this to deactivate an engine.

1. in the VAB, tag the engines(s) you want to address with the same tag name (right-click on the part and set the tag.)
2. define your list() in kOS:
   local engineList to list("CentreEngine"). - assuming you tag the engine in the VAB as 'CentreEngine'
3. Execute the PEGAS function like this:
   availableCommands["engineShutdown"](engineList).

In case you're not sure why it would done this way, kOS has some pretty serious problems when it comes to polluting the namespace. kOS is a scripting language and not a full fledged programming language. What that means is that all variable names a global in scope, which means you can accidentally use the same variable name multiple times if you're not careful.

In later versions of kOS, the devs addressed this with the @LAZYGLOBAL OFF. command you can add to any .ks file, but @lazyglobal is on by default.

Using a lexicon and with delegate functions is likely an attempt to protect against this type of potential problem.

CheersKevin has a great series on youtube for learning how to code with kOS. I'd strongly recommend it. Just be aware that the first 30 or so videos in the series predate some significant kOS changes. Namely the entire reason to use delegate functions. All told, it's a good foundation in the language and concepts for how to run missions.

https://www.youtube.com/user/gisikw

sorry if you know all this already. I kinda figured someone else might find this down the road someday and find the details helpful. I tend to stay away from writing my ks code in this manner, but I understand why it would be done.

[Noiredd]

My apologies for a very belated reply - as you probably noticed, I'm not actively involved with development of PEGAS right now. I will try to be more attentive of questions and issues in the future though.

Using the message facility, AFAIR, requires you to have two CPUs on board - unless it is possible for the vehicle to send the message to itself. If this can be done (I haven't written nor even used this portion of the code, only reviewed it, so I'm not sure), you could write your own timer to execute a command_engineShutdown message in order to shut some engine(s) down.

However, while it may or may not do what you want to do, this will only shutdown the engine without updating PEGAS internals. So if you're flying in a passive phase (not sure about UPFG), the remaining engines' burn time will not be adjusted for the reduced mass flow and you have to do this manually. The easiest way to handle this would be by defining a whole new stage with reduced thrust. You will have to do the mass flow math and compute the amount of fuel left in the tank at the time of the engine shutdown. This in turn means that you will have to know when will it happen before the launch (of course this can be hacked around by modifying VEHICLE on the fly, but that can prove tricky).

This is all a little hacky until something is done about #15 - if there was a general way to execute any function at any time, this would be as simple as defining a jettison event now. Unfortunately, I don't have the time to work on this nowadays -- maybe in the future, but for now I can't make any promises, I'm sorry.

[Noiredd]

I've been keeping this one open all this time to remind me about two things:

• to implement engine shutdown event, preferrably per-tag,
• to improve the documentation.

Today it seems like both goals have been accomplished. Engine shutdowns are possible since eff88cf (event itself), 19a4025 (UPFG compatibility) and 5e893d4 among others (major overhaul of the events system). The most recent changes also include improved docs, along with an expanded tutorial section with a more concrete design example d50a70c.

Thank you for those suggestions. I'm closing this now. If you have any more requests (features or docs) - please open a new one.