[1.3] kOS Scriptable Autopilot System v1.1.3.0

[karamazovnew]

13 hours ago, hvacengi said:

Have you tried tuning the steering at all?

I doubt the issue is your code length, but without any context the error message doesn't really tell us anything.  Please provide a copy of the script, as well as the log file showing the error message.

Null references are most easily found by looking at the actual C# underlying stack trace, which is visible in the log.

Roger on everything. It does make sense, according to what I've seen so far. Anyway, I'm blaming FAR for this one, as even the stock autopilot now has problems with controlling a craft just with the fins. 

Tuning the steering? Yes, no effect. Raw controls working just fine. Code? Something very simple:

 

WAIT 2.
CLEARSCREEN.
STAGE.
SET now to time:seconds.
WAIT 5.
print ("Alter steering, should be 5.   "+ (time:seconds - now)).
LOCK STEERING TO HEADING(90,70).
SET now to time:seconds.
WAIT 10.
print ("Alter steering, should be 10.  "+ (time:seconds - now)).
LOCK STEERING TO HEADING(70,50).
WAIT 10.
print ("finished. "+ (time:seconds - now)).

SET SHIP:CONTROL:NEUTRALIZE to True.
SAS ON. 

Just a simple rocket with 4 AV-R8 fins. Mods? Just clean install with KOS, Module Manager and FAR. Here's how it goes...

- any rocket with authority such as reaction wheels or engine gimbals or stock fins.... all ok, working as expected in any combination and at any intensity (any reaction wheel power, engine gimbal angle).

- any rocket that also has FAR fins? It seems that if the vessel doesn't have any other good authority in one particular axis, the command on that axis varies wildly very very fast (much worse that stock autopilot), so fins don't get the chance to actually turn at all, they just wiggle fast at 1-2 degrees or so, basically maintaining the axis stable and preventing any turning. So as an example, a rocket without reaction wheels (all disabled) and just one gimbal engine will have good auto control on the pitch and yaw axes (stable commands)from the engine, the fins will not twitch on those axis, but the roll axis will twitch as long as the STEERING is LOCKED to anything. After a while, the roll starts to happen so then the other axis start to twitch as well, screwing up the gimbal on the engine. Basically, without a good Reaction wheel, the craft will simply not be able to stay straight.  The reason why this problem messed me up every time during launch was that I have a small mod that cuts all reaction wheels power to something like 5%. Otherwise I never would've noticed this bug and would've blamed more extreme examples on aero forces. The exact same rocket can work fine with stock reaction wheel, then freeze with my 1/20 reduction, all the time working just fine in space. 

Just for fun, I've copied the fins part and disabled FAR for it. Guess what... with 4 non-FAR and 4 FAR fins on the rocket, they all refused to work, with the FAR fins messing the others up. You need to see this for yourself, I don't think logs would help here.

Oh and of course, FAR Flight Assistant was off.

I'm ok with my current stock fins, they work just fine.And for my scripts, I'll just use a custom autopilot. I'll try again when I see Far fins are more stable in stock autopilot. No use now, really  . Anyway, since these mods are a must for Realism Overhaul, it's good to know in advance what to expect when I start that

Edited May 21, 2016 by karamazovnew

[Dunbaratu]

3 hours ago, karamazovnew said:

 

LOCK STEERING TO HEADING(70,50).
...
SAS ON. 

 

Why are you doing both of these at the same time?  Either you want kOS in control of steering or you want stock KSP's SAS in control of it, but trying to have both fighting each other at the same time isn't a good idea.  I always have a hard time using both at once.  The stock SAS tries to fight against what kOS is doing when stock SAS is being told to try to maintain heading and kOS is trying to change the heading.

[Cairol]

Love this mod. It's like a turtle in Minecraft FTB - a game in the game.

But why are those computer cores so unbalanced?
The small disk-like computer has only 5000 Space while the micro-HAL9000 thingie has 255000 with much less weight.
All have the same cost in survival despite being differently powerful.
The other larger cores are also almost equal in weight while having different capacities.

[karamazovnew]

6 hours ago, Steven Mading said:

Why are you doing both of these at the same time?  Either you want kOS in control of steering or you want stock KSP's SAS in control of it, but trying to have both fighting each other at the same time isn't a good idea.  I always have a hard time using both at once.  The stock SAS tries to fight against what kOS is doing when stock SAS is being told to try to maintain heading and kOS is trying to change the heading.

I know that, but It's just a quick boot test script... Anyway, I am not using them at the same time. The script is not a loop, just a few one-time commands with delay between them.

LOCK STEERING TO HEADING(70,50). 
WAIT 10.
SET SHIP:CONTROL:NEUTRALIZE to True. //sorry, I left out the beginning of script that first tested the controls on all axis, doesn't matter...

//at this point steering is still locked, but the script will end after the next line anwyay.

SAS ON. //last command in the script. So it's just like having an UNLOCK STEERING command just after it, because the controls are returned to the player anyway when the script ends after this line.

Before you ask, I did have an UNLOCK STEERING before it, I just replaced it with the last PRINT line since for the last tests where I liked to keep control and do manual "LOCK STEERING TO HEADING" commands in the terminal. Regardless of SAS on or off, results were the same, that thing was irrelevant for my tests.

And yes, my take-offs were at 50% engine power  small rocket, big engine. Didn't feel the need to include throttle controls

 

[ColKlonk]

23 hours ago, hvacengi said:

The original post was edited while I was replying:

Depending on what the error is, it may have already been fixed in either a more recent version, or in the pending develop branch.  You can still post the information (it might still be an issue) but there is a good chance that we will ask you to upgrade and test again.

All sorted... I thought it couldn't be that hard.

I cleaned up the texts, and made some minor changes and we're in orbit again :-)

 

It's probably one of two things or both :-

I had 2 blank functions, which I intend to fill in later, and these were included in the main routine loop.
 

Function functionName

{

}

I just added a local variable that does nothing

Function functionName

{
Local i_Tmp is 0.
}

.. and I had a function with only an Unlock all statement which i removed, and added the local statement as above.

Function functionName

{
  Unlock all.
}

 

These two things are the 'major' changes that I've done.. and all is fine now

Oh yes.. Sorry.. KOS version is v0.19.3 and KSP version is v1.05.

Would KOS v0.20.x work on KSP v1.05 - as I'm not moving until at least 3-6 months of KSP v1.1 patching is done.

Edited May 21, 2016 by ColKlonk

[leocrumb]

On 5/19/2016 at 4:03 PM, hvacengi said:

No, I mean that it isn't listed on the changelog or included in the v0.20.1 release because that release was strictly a maintenance release to address a few bugs, mostly specific to KSP 1.1.x.  The pull request including the feature has been merged, and will be included in our next major release.

FAR changes the aerodynamic properties of the game, and we currently do not directly support FAR.  All of our steering calculations are based on KSP's new `ITorqueProvider` interface, so FAR would need to replace the control surface module with it's own module providing FAR specific torque calculations in order for kOS to accurately control with it.  If they already do this, we may need to look into the accuracy of those readings.

Thx

[dewin]

15 hours ago, Cairol said:

Love this mod. It's like a turtle in Minecraft FTB - a game in the game.

But why are those computer cores so unbalanced?
The small disk-like computer has only 5000 Space while the micro-HAL9000 thingie has 255000 with much less weight.
All have the same cost in survival despite being differently powerful.
The other larger cores are also almost equal in weight while having different capacities.

Technology advances.  Your smartphone is both significantly lighter and has significantly more storage capacity than this.

(I'm still just dabbling at KOS, I assume KAL9000 doesn't unlock towards much later in the tech tree.)

[MAFman]

Hey, can someone help me create an autonavigation script for rovers? It's supposed to keep speed constant, drive toward waypoints, and (this is the hard part) set its own waypoints intelligently based on traversability and how close each option is to a user-defined target latlng().

Something like DRIVE_TO_GOAL(145.02873, -0.04968).

[Cairol]

4 hours ago, dewin said:

Technology advances.  Your smartphone is both significantly lighter and has significantly more storage capacity than this.

(I'm still just dabbling at KOS, I assume KAL9000 doesn't unlock towards much later in the tech tree.)

I don't play survival in KSP beause it's super grindy.
But if the KAL9000 is better in every aspect, it renders the other computers useless, once you have unlocked it in survival.
That's bad balancing. There should be a persistent advantage to use a less powerful, yet more bulkier and heavier computer.
Like much less cost than the tiny, powerful high-tech version the KAL9000 represents.

Edited May 22, 2016 by Cairol

[Drew Kerman]

4 hours ago, MAFman said:

Hey, can someone help me create an autonavigation script for rovers? It's supposed to keep speed constant, drive toward waypoints, and (this is the hard part) set its own waypoints intelligently based on traversability and how close each option is to a user-defined target latlng().

Something like DRIVE_TO_GOAL(145.02873, -0.04968).

https://github.com/Gaiiden/RoverDriver

Note this was written in pre v1.0 compatible kOS script but it's a start. Doesn't navigate itself tho, was designed to follow pre-plotted waypoints based off SCANsat terrain data once a planet was mapped

Edited May 22, 2016 by Gaiiden

[dewin]

7 hours ago, Cairol said:

I don't play survival in KSP beause it's super grindy.
But if the KAL9000 is better in every aspect, it renders the other computers useless, once you have unlocked it in survival.
That's bad balancing. There should be a persistent advantage to use a less powerful, yet more bulkier and heavier computer.
Like much less cost than the tiny, powerful high-tech version the KAL9000 represents.

Most of the rocket engines do have their unique role to fill, this is true -- though a handful of them are mostly a case of "This is your best option for X until you unlock Y".

But doing that with computers wouldn't make sense.  What would be the advantage of using a 1950s computer over a modern smartphone today?  Technology is rendered obsolete over time with various breakthroughs, so it makes sense that it should be that way in KSP as well.

[Kethevin]

I'm returned after a long delay and am trying to get up to speed on the changes.  I do have one question.   I had a global launch program where I entered data as I ran the program.  I now get an error when I try that. 

As an example, my first line was "Declare Parameter H,AP"  Where H was my desired Heading and AP the Apoapsis.  So I would initiate the program by typing run (program name) 90,150000.

Is that no longer possible?

EDIT: Ignore all that. I believe I found the answer here:

"In order to avoid the issue of having uninitialized variables in kerboscript, any declare statement requires the use of the initializer clause."

 

Edited May 23, 2016 by Kethevin
Found the answer.

[Dunbaratu]

On 5/23/2016 at 2:22 PM, Kethevin said:

I'm returned after a long delay and am trying to get up to speed on the changes.  I do have one question.   I had a global launch program where I entered data as I ran the program.  I now get an error when I try that. 

As an example, my first line was "Declare Parameter H,AP"  Where H was my desired Heading and AP the Apoapsis.  So I would initiate the program by typing run (program name) 90,150000.

Is that no longer possible?

EDIT: Ignore all that. I believe I found the answer here:

"In order to avoid the issue of having uninitialized variables in kerboscript, any declare statement requires the use of the initializer clause."

 

Not quite.  For parameters you are supposed to be able to leave it off because you provide the parameters when you call it.

run program_name( 90, 150000 ).

 

On 5/22/2016 at 3:55 AM, Cairol said:

I don't play survival in KSP beause it's super grindy.
But if the KAL9000 is better in every aspect, it renders the other computers useless, once you have unlocked it in survival.
That's bad balancing. There should be a persistent advantage to use a less powerful, yet more bulkier and heavier computer.
Like much less cost than the tiny, powerful high-tech version the KAL9000 represents.

There are plenty of things in KSP that there's little reason to use once you upgrade past them.  Like the Stayputnik probe core, or the reliant engine.

[Cairol]

Can you have multiple conditions in on "if" clause with "||" or "&&" or somtheing like that?
The documentation says nothig about it.

[Drew Kerman]

14 minutes ago, Cairol said:

Can you have multiple conditions in on "if" clause with "||" or "&&" or somtheing like that?
The documentation says nothig about it.

http://ksp-kos.github.io/KOS_DOC/language/flow.html?highlight=operators#boolean-operators

It should probably be mentioned in the If/Else section. Will add the suggestion to the docs issue on Github

Wait no, derp - these operators can be used by almost any of the flow statements in this section there's no point specifying it in the If/Else area.

Edited May 26, 2016 by Gaiiden

[Cairol]

How to rename an action group with AGX installed?
The documentation says, you can do that when the "Script Hook" is attached to an action group. But no example or command is given.

Or is it meant the other way round? That you can name a group in AGX and then reference it by name in the code instead og AGx?

[Karyn451]

On ‎22‎/‎05‎/‎2016 at 9:55 AM, Cairol said:

I don't play survival in KSP beause it's super grindy.
But if the KAL9000 is better in every aspect, it renders the other computers useless, once you have unlocked it in survival.
That's bad balancing. There should be a persistent advantage to use a less powerful, yet more bulkier and heavier computer.
Like much less cost than the tiny, powerful high-tech version the KAL9000 represents.

Your new interstellar generational colony ship may have the latest KAL9000 at its heart, but what about the space dock and refuelling station that was built before you unlocked the KAL9000?

When it comes to computer tech, there's generally never an advantage to using old technology else computers would never advance.  Unlike ,say, engines where an old, less powerful model may have an advantage due to size and/or weight, new computers can always outperform their old counterparts.

In sandbox, anything other than a KAL9000 is redundant,  but in career all your fleet will have less powerful systems unless you specifically replace/upgrade them.

 

What I'd like to see is the early tech cpu deliberately throttled in its processing speed, not just memory size. 

 

 

[Apurva Kawthalkar]

i am getting an error msg on the terminal

[Alchemist]

26 minutes ago, Apurva Kawthalkar said:

i am getting an error msg on the terminal

Everybody gets plenty of them. Could you, please, specify what are you trying to do and what's the message?

[dewin]

3 hours ago, Karyn451 said:

What I'd like to see is the early tech cpu deliberately throttled in its processing speed, not just memory size.

This is mentioned earlier in the thread as something the developers want to do as well.

Particularly when -- as it stands now -- processors have infinite RAM (so you can run huge amounts of library code as long as you're in range of the archive, once it's loaded and running it's not necessary to maintain comms).

[RocketSquid]

On 5/22/2016 at 4:55 AM, Cairol said:

I don't play survival in KSP beause it's super grindy.
But if the KAL9000 is better in every aspect, it renders the other computers useless, once you have unlocked it in survival.
That's bad balancing. There should be a persistent advantage to use a less powerful, yet more bulkier and heavier computer.
Like much less cost than the tiny, powerful high-tech version the KAL9000 represents.

The only real advantages would be cost and power draw. Mass is far more important than cost, but power draw could be significant.

[kcs123]

47 minutes ago, RocketSquid said:

The only real advantages would be cost and power draw. Mass is far more important than cost, but power draw could be significant.

Second this. I already metioned it in post few pages back. While different CPU speed will be nice touch, it will not change anything in game much, how kOS CPU will be used. Whole other important process in game is much slower than even slow CPU from 60's as kOS try to simulate will have more than enough CPU power for that to handle.

I think it is better for devs to spend their time elsewhwere than on this, but, hey, that's their free time, they can do whatever they want with it.
Sligtly offtopic, but kOS CPU reminds me a lot to real life counterpart - various PLCs and microcontrolers used in industry. Both share similar philosophy - read input ports, do some calculations, set output ports based on calculations in determinated timeframe.

[RocketSquid]

Also, I have a serious question: Is the planned vessel to vessel communication going to be integrated into the CPUs, attached to stock antennae, or part of a new set of parts?

[Dunbaratu]

4 hours ago, kcs123 said:

Second this. I already metioned it in post few pages back. While different CPU speed will be nice touch, it will not change anything in game much.

Actually it changes the very thing you talked about earlier - power.  Now the power draw is based on how many instructions have *actually been* executed in the update, rather than how many could have been had it used the whole timeslice.  In other words if you have a loop that does one command then does a wait 0, it won't draw nearly as much power as a busy loop that calculates pi over and over and never stops.  So IPU does affect power draw that way too.  Running a program at 50 IPU uses less power than running it at 2000 IPU, unless it has lots of waits so it was never really using that full 2000 IPU anyway.

We would like to do away with IPU as a global setting across the whole mod and instead make it a feature of the "hardware".  i.e. because you are using THIS model, your IPU is only 50, but because your later design used THAT model, your IPU was raised to 2000, etc.

The only question is whether or not we'd also want to simulate the idea that older computers draw more power for the same IPU.  An old clunky model pays more power to achive 1 Mhz than a modern phone does to achieve 1 Ghz.

 

 

55 minutes ago, RocketSquid said:

Also, I have a serious question: Is the planned vessel to vessel communication going to be integrated into the CPUs, attached to stock antennae, or part of a new set of parts?

It's roughly like this:

1. Player tries to send a message from one CPU to another vessel.

2. System checks for a connection using one of these two rules:

  2.a. If Remote Tech is installed, ask Remote Tech "can this vessel get a signal to that one?", which is provided by the Remote Tech API for other mods (like us) to use.

  2.b If Remote Tech is not installed, then just assume  the answer is always yes - you can reach the other vessel.

3. Once it decides it can reach the other vessel, the message goes in a holding queue, with the in-game timestamp on it for when it is meant to arrive (if RT, it uses RT delay, else it arrives instantly),

4. When the destination vessel tries to read the "next message", kOS won't show it anything in the holding queue that "isn't there yet" because its timestamp is in the future.  It only gets the next message who's wait has actually expired.

 

[hvacengi]

2 hours ago, dewin said:

This is mentioned earlier in the thread as something the developers want to do as well.

Particularly when -- as it stands now -- processors have infinite RAM (so you can run huge amounts of library code as long as you're in range of the archive, once it's loaded and running it's not necessary to maintain comms).

Memory limits are complicated with how program execution happens now.  All opcodes are loaded into the program context and don't get cleared until the next time that the program returns to the terminal (or is shutdown).  So without a means of releasing those programs, it isn't really fair to limit your memory.  As for the memory limit itself, that too is complicated.  Because we aren't actually having to address memory directly ourselves, we don't have easy access to information about memory consumption.  Probably the first blush would be a conceptual limit rather than an actual memory limit (count the number of opcodes and variables, for example).  Like our use of generic opcode instructions for IPU instead of using the actual underlying instructions or execution time (positionat counts the same as max, for example), it's just easier than trying to do it perfectly.  Which fits with the KSP mentality: close enough to be realistic and challenging without being so complicated that it isn't any fun.