After 0.12 is out - should there be a goal for 0.13 ahead of time?

[ksp-kos]

After 0.12 is out - should there be a goal for 0.13 ahead of time?

[erendrake]

I cant agree more, one of my priorities is getting more regular, smaller, updates. This last one was big with the new parser and there was no avoiding it.

I think each update should have a theme, such. If we can agree as a team on a small group of features to work on i think we will have happier users and developers.

If we decided to do that I would like to put forward a few themes for the next patch.

• Docking Improvement - Docking might be possible today but i would like to make it much simpler. Maybe boil it down to the variables available in Navyfish's excellent Docking alignment mod
• Infernal Robotics Integration - Right now we can interact with IR with action groups but I think we could do better
• Dedicated Rangefinding parts - We only have altitude straight down from the current vessel. It would be really cool to have directional sensor parts to assist in better landings. We had a good discussion around here somewhere.
• Remote Tech antenna control - this one would actually be generating a pull request for the RemoteTech project as their API doesnt allow for mucking around with antenna targeting and activation. It might also give us reason to have some kind of bootstrapper setup so that a craft can do something automaticly on a restoration of power. This one is a bigger bite from the apple.

I am only listing these to start a conversation. We have nearly endless opportunities available to us and i welcome discussion.

[Dunbaratu]

Things I've been thinking about along those lines have been:

• Making subprograms behave like proper function calls:
  • * Allow return values from a "run" command.
  • * Allow a way to declare variables as local or global under user control.
  • * Make SET and LOCK use the exact same scoping rules as each other to avoid confusion. Make BOTH of them choosable as being either local or global. (Right now there's no choice - if it's a LOCK then it's local, and if it's a SET then its global.)
• Adding a 3-part generic FOR loop like for( init; check; incr ).
• Change the LIST() function call so that it takes a varying number of arguments, that can be used to init the list like so: SET FOO TO LIST( thing1, thing2, thing3, … ). Right now LIST() is already a function call that returns a list, but it is hardcoded to only be capable of returning empty lists.
• Better UI that programs can make use of to communicate to the user, including:
  • * handling keyboard input
  • * drawing "vectors in space" as per my older issue.
  • * Expose a few basic 2-D graphic primitives to the script like line/circle/rectangle, so people can write things that show graphs and simple diagrams onto the terminal window as if they were computer readouts coming from the autopilot.
• Multiple terminals for multiple CPU's (either one window with tabs or more than one window).
• Math tools to perform reference frame rotations for you (the matrix math is silly when the Unity API already does it natively and passes the matrix calculation down to the hardware if it's supported), and to convert Vectors/Directions between each other.

I'm not sure about the docking improvement. I'd like to try my hand at writing an intercept/docking script using the new SHIP:CONTROL after 0.12 is out so I can see how hard it is currently to do first. Right now it's not easy to do purely because of how hard it is to get SHIP:CONTROL to play nice and I put it off until the issue is fixed in 0.12. We always have to be careful to throttle back on "make it easy" so it doesn't turn into "we're writing the autopilot ourselves instead of the user doing it".

[marianoapp]

One feature I already developed is the support for threads that allows you to write something like

// supports a variable number of arguments
set myThread to thread(programName, arg1, arg2, ...)

That creates a thread that executes alongside the main program, and that you can control with suffixes like START and STOP. It's pretty useful to, for example, having a staging program running in the background. It may need some work but already works.

Beside that, I have a few things I would like to add:

• A "PRESERVE" or similar keyword that could be added to the ON and WHEN instructions so they can be triggered multiple times (this is really simple to add, actually).
• Some VAB/SPH editor stuff, like:
  • Naming volumes
  • Copying files
  • Naming parts (to retrieve later as PartValues). This would allow to control several aspects of the craft without needing action groups.

[Dunbaratu]

Other ideas from a video chat @erendrake and I just had:

• Testing suites
• "autoexec" style boot script on launchpad load - maybe by reading what the user types in the VAB's description field for the craft.
• Example scripts
• For @marianoapp's recurring "ON" and "WHEN" - idea: Make it so that by default they go away after executing once like they do now. But if during the body you execute "PRESERVE.", then that says "keep this hook around for the next time." So you decide on each time it triggers if you'd like it to trigger again. Like this:

WHEN thing_happens THEN {
  run dosomething.
  if trigger_should_still_exist_after_this {
    PRESERVE.
  }.  // else this when trigger will go away.
}.

• If you allow return values from a program, then you could also allow a subprogram to work as the object of a LOCK keyword, like so: LOCK MYVAR TO RUN MYPROGRAM( arg1, arg2 ).
• Control science modules directly (Tell it to take an experiment. Tell it to send results back by antenna.)
• Generic access to the rightclick GUI menu of a PART.
• Maybe read values of tweakables for parts.

Erendrake brought up the idea that while threads are really cool, exposing them directly to script writer may mean having to handle all syncronization with the API calls, and I was wondering if doing that might expose the (possibly newbie) programmer to concepts like how to make code thread-safe. And we may need to provide ways to mark atomic critical sections, given the kRISC virtual processor under kOS, the same problems as can happen in real world threading can happen here - where any user-land variable you try to use as a semaphore flag isn't good enough because a single statement in the high level language becomes several machine language statements that could be interrupted in the middle of them. So to provide the ability for threads to signal each other requires support from the OS to implement the flags for them to ensure they are always flipped atomically.

Trying to work on docking abilities as a next goal might be a good idea. I don't know the KSP API that well, but I'd be willing to work on the high level script user end of things trying to write a docking program with what's there now to try to discover where the hard parts are or what important features may be missing.

[marianoapp]

I agree with everything, and I just remembered that we are lacking proper career integration. Maybe limiting execution speed would be enough, but we'll have to do something about it.

Also, user defined functions, they would be really a game changer. And if we add the ability to import them from another program (like an "include") they would add a lot of flexibility to the language.

More on the development side:

• I would like to make the compiler more stateful, so it knows if an identifier is a variable and it wasn't initialized it could throw a warning, for example.
• The current suffix scheme is falling short because structures are behaving more like objects than structures, and we don't have methods. We got away with stuff like "SET myList:ADD to ..." but we're already pushing it.

There's also the subject of scoping. I would like to move towards a more scoped version of the language, providing all the required tools for that (like a RETURN instruction). I would like to hear your opinions about this.

[Dunbaratu]

How are you picturing user defined functions differing from programs with a return value? The only thing I can think of is that there can be more than one in the same file.

I too dislike the LIST add syntax, but only because it's doing a thing the user can't do themselves - make a method for an object.

I agree about scoping. But one issue to deal with is backward compatibility. In most languages the default scope is local. If you do that in kOS, however, you will break MANY people's scripts. Perhaps something like what happens in Perl can be used: In Perl, you can implicitly declare a variable by just using it for the first time. (like the SET command does in kOS). When you do that, the variable defaults to global scope. If you want a local scope variable, you have to declare it explicitly as local. Maybe that could be done in kOS - add the optional word "LOCAL" to the DECLARE command, like so:
DECLARE LOCAL LVAR.
DECLARE GLOBAL GVAR. # For backward compatibility, this is the default if not explicitly picked.

[erendrake]

real methods as something distinct from properties would be great and you are right, add is something i cheated in there and i am not happy with it as it is. not having a real methods will hold us back and i would love to see them included depending on the difficulty.

I am ironing out a few more bugs with steering and my regression of a fix by @marianoapp do either of you have an issue with releasing v12 once i get them done?

[marianoapp]

@erendrake No, I think we are pretty covered. Some of the remaining issues can wait until v12.1.

@Dunbaratu Functions could be private to the program and as such use/alter local variables. Also I wouldn't like to have a lot of tiny programs for every function I may write, too much clutter.
I think a global default could work, at least as the default behavior. I'm to lazy to be writing DECLARE LOCAL for every variable, so maybe a config option could be added to make the variables default to local scope.

About backward compatibility, do we have an idea of how big the kOS user base is? If we're talking about 50 people we have a lot more flexibility to break stuff than if they are 500.

[erendrake]

The only metric i have to go on are the download numbers. We have 2661 downloads of the mod from the spaceport. Reddit seems to be the most active user base we have right now.

I am actually open to breaking changes if we have a better default behavior and we can agree on it. It would be cool if we could help scripters with transitions with code snippits and such

[Dunbaratu]

@erendrake - I'm happy with releasing what's there now, especially as lots of people in the forum keep running into problems that are already fixed in this code but not released yet. Don't forget about the documentation being regenerated to go with it (Which I still don't understand how to do yet. I only just started reading the links you sent me a few hours ago). Also, if you regen the docs, then that gives you the ability to put links to the appropriate section in your release announcement for each bullet point, i.e.

• New list indexing allowing expressions [link to doc section about list indexing]
• New ELSE operator [link to doc section about IF/ELSE]

etc.

I've been trying to document anything that changed about the syntax, so looking over at KOS_DOC's commit log might be a good reminder of what to put in the release announcement blurb. Sorry about the number of commits - I didn't find the preview option in the web editor until much later on so originally I had to commit to render and see if the markdown code was right.

@marianoapp The point of the DECLARE LOCAL is that you can choose it differently per variable. Perhaps if its a config option it could be an option you turn on and off with a command, and it only affects the lines that occur from then on like so:

CONFIG:LOCAL ON.
SET X to 2.
SET Y to 3.
CONFIG:LOCAL OFF.
SET Z to 4.

In that example, if we assume X,Y, and Z were not already declared and this was their first usage, then X and Y would be local while Z is global.

It's weird that Reddit is the most active user base because the kos subreddit has very little traffic at all - something on the rate of about 1 post a week at most.

Also, you said 2661 downloads from the spaceport - are the downloads from the pre-releases mentioned in the development thread tracked? Given how long it's been since 0.11, it may be the case that more people are downloading that than the spaceport version.

[marianoapp]

I was thinking more along the lines of being able to set "CONFIG:LOCAL" to be always on, and then use the GLOBAL modifier whenever I wanted a global variable. That config would ship disabled as default so kOS behaves like it does now.

[Dunbaratu]

@marianoapp Oh, okay that makes sense too. Just as long as there is some type of escape mechanism.

I think we're in danger of getting too many specifics about individual implementation details here in this thread that should be just brainstorming what features to add, not the details of their implementation.

[Dunbaratu]

A few other ideas to add to the potential future list (not necessarily for 0.13 - maybe for farther in the future).

• Stop using the Plugins/PluginData/Archive and instead put things in some folder under either GameData/kOS or a user-supplied location of their own choosing. Things to consider for this:
  • It should contain a check that looks to see if the old location has files in it, and if so ask the user to move the files to the new location - so people following old advice on the internet or people who just upgraded don't wonder what's wrong that they can't see their files.
  • Perhaps there could be an in-game configuration for people to supply their own Archive location which could be anywhere, even somewhere outside of KSP entirely. (Useful for people who have more than one KSP installation because they run different sets of mods or run older versions of KSP - they could share scripts between different KSP installs if they could type in any arbitrary archive location.). That would aid in tests and debugging to - to install users' scripts to try them, without them clobbering similarly named scripts we already have.
  • It should not be moved to the savegame folder. The fact that scripts are shared between different campaigns is a good thing that should be kept.
• Even though the text editor is a pain to maintain, something to replace it should be added as it is vital to the newbie experience, and thus affects the mod's popularity. Perhaps we could have something that just opens up a stock built-in text widget so we don't have to code all the editing logic. Unity has a GUI.TextField widget that is designed for this sort of thing. I wouldn't be pretty (for one thing it would probably have to use one of KSP's built-in fonts which I think is just Arial only (not a fixed-width font)) but it would get the job done of having SOME sort of in-game way to look at and change a file.

[jberkman]

(i'm guessing this can probably be closed?)