erendrake
-
Posts
536 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by erendrake
-
-
public bool AGXTriggerAction(Vessel vsl, int grp) //basic toggle of an action group on a vessel.
I assume passing the Vessel object will work or does kOS use some other identifier?
Note this returns a bool, true if AGX is able to complete the command, false if not. I'm pretty sure just calling the method will also be fine if you don't want to use the bool that gets returned.
Vessel should work, using it depends on some reference equality because squad hasnt build custom equality comparision. The remotetech API uses vessel.rootpart.flightid and it works pretty well.
public bool AGXTriggerAction(Vessel vsl, int grp, bool force) //basic on/off of an action group.
Same logic as previous but add a bool as a 3rd parameter (true = force activate, false = force deactivate) for what to do.
This is what i imagine we would hook up to to make it behave the same way that action groups work now in kOS.
public bool AGXActionState(Vessel vsl, int grp) //Check action state on/off (true/false on returned bool)
This too
public List<BaseAction> AGXGetActions(Vessel vsl, int grp) //get list of actions assigned to the defined group
This one is the method I am most uncertain about, is a list of BaseAction's what makes sense for me to be returning?
I think that is a fine return value, a list of base actions is exactly what we use for finding the actions for parts and modules now.
Also planned would be using group names instead of group numbers, so:
public bool AGXTriggerAction(Vessel vsl, string grpName)
This would keep in mind kOS's intention that case does not matter and would match "lights" to the "Lights" group.
That sounds cool to me, it is going to take some work to give this to scripters but i like the idea. Also would the names match to one of the existing 250? or are they their own additional action groups?
Would you also extend the rest of the API to take a string as well as an int? im thinking about the force option, the getter, and the "get baseactions for this group".
edit: One other critical question I need answered, when is kOS available? Right now, AGX only runs during the editor and flight scenes. Do I need to add support for returning calls in other scenes?
We are currently available in the flight scene with thoughts of adding the editor eventually. Nothing else is needed for kOS right now
Does that answer all of your questions?
-
Alright, Action Group Extended dev here and apparently I have good timing seeing as I got mentioned a few posts ago.
I just pushed a new version that should (hopefully) move AGX to pretty much feature complete and so I can now look at kOS compatibilty as this is not the first time it has been asked for.
First, for those who have not heard about it, AGX brings the number of usable action groups up to 250. The idea as it has been presented to me is that rather then having to add support for activating things individually in kOS, use kOS's ability to activate action groups to control the functions on your vessel by assigning those functions to an action group that kOS activates.
As mentioned however, currently there is some significant work that has to be done on my end before I can pass it to the kOS dev's (reading the thread it looks like multiple people are working on this) to complete the integration.
So, in addition to adding support for activating actions on vessel's that are not the vessel currently being flown, what else do you want to see from AGX to better improve your kOS flights?
Note: Any requests are tentative as they must be okay'd by a kOS dev as well as myself, both to make sure they make sense in terms of what our mods do, and from a technical standpoint to make sure they are possible.
There are a couple features I have thought of:
1) Activate an action group by name rather then number. AGX gives you the ability to name action groups so you can remember what the group does. Does this make sense from a kOS perspective? Currently it is a simple "AG1" command, can this be changed in a way that makes sense on the kOS end to activate an action group via its name?
2) Throw an error if an action group can't execute, notably if the target vessel is out of range. Note that I will display a message on screen on the AGX side of things (the large green text in the middle of the screen), but are people getting complex enough with kOS scripts that they would want to execute error handling of some sort if I return a "action failed" message from AGX to kOS?
D.
For my bit i am very excited to get integration between out mods and i think 1 and 2 should be doable .
-
Hah! I have it. I don't know how well it will work, but a form of proportional control could solve the problem of limited action groups, when controlling IR with Kos.
Imagine you have to control 6 legs independently. you need 6 action groups for up, 6 for down, and 6 for neutral. That's 18 just to control up and down, and you only have 17 if you steal action groups from canned actions for gear and stage etc. Your Kerbals aren't going anywhere today.
But imagine I slice the actions up into little timed on/off segments. Now I just need to invoke down as a single action on all the legs, 50% of the time for example. I counter that with an action group up on each of the legs that can be varied in length. Then I add a single action for neutral for all the legs (with programming that limits the impulses for the other actions). Now I've accomplished the same control with just 8 action groups.
I can do the same thing for cyclical movements of the six legs to make it crawl like a bug. Since neutral is common, this added action will only take 7 action groups. I have 2 left!!!
We are working on it
-
Okay then why wouldn't my code work then when i press 8 or 9? if i understood what you meant, i should be able to use ag 8 and 9 regardless of having AGX installed, as it's the only current flight in the entire save (testing it on default sandbox before using it for the career)...
btw i don't know what hardcode means
question, have you upgraded AGX lately? it wasnt that long ago when AGX was blocking us from seeing actions groups.
-
Thanks for the quick reply.
I tested this, as said, thoug ofc I might have just done something else wrong. Here's what I did and what happened:
- Installed just Mechjeb, kOS and RT2.
- Launched sandbox game.
- Constructed simple rocket (without Mechjeb-module or antenna).
- Put rocket on launchpad, open kOS and enable the RT-setting.
- Write a program that locks thrust to 1.0 and changes heading back and forth every couple seconds to see something.
- At a certain height (once RT looses connection), the throttle cuts to 0.5. AFAICT the program is running but RT still prevents it from keeping throttle to 1.0 or changing the heading. Once the rocket drops back into connectivity range, kOS regains control.
- Rince and repeat until out of fuel.
(Written down from memory, so there might be some inaccuracies in this report. As said, I can test this again, if needed.)
and you wrote this program on the local volume? it wasnt in the archive or the 0 volume? The remotetech integration is still in beta as of 0.14.2 which is why it is turned off by default. let me try it tonight and see if i have trouble with it.
- Installed just Mechjeb, kOS and RT2.
-
How are you setting it in-game? Unless there's a configuration screen I haven't seen, you have to edit the config.xml file by hand.
you can actually set all of the in game configuration in the terminal
http://ksp-kos.github.io/KOS_DOC/structure/config/index.html
-
It should be fairly easy to add trim to kOS, we are in a feature freeze right now but once we are on to v0.16 expect to see it.
-
I must admit that i never added trim to the fine control system because i have never used it in the game. How useful will it be to have access to trim because it shouldnt be that hard to add it.
-
I agree with Steven here. If you just want to use an autopilot, MechJeb is the way to go. If you want to *write* your own autopilot, kOS is the tool to use. I would even suggest that the internals of LOCK STEERING remain private. They should work for very simple craft to ease programmers into kOS, but complex and tuneable PID loops should be the meta-game of kOS. Just remember how hard it was to get your first rocket into orbit using stock KSP! To me, the challenge is most of the fun.
As an aside, I have forked the docs on github and am writing a sequel to the quick-start tutorial. My goal is to provide non-programmers with a way to get from simple LOCK THROTTLE commands to a full PID implementation without giving too much away (like a whole auto-pilot system).
What is your github user name? we are always excited to have more contributors on every part of the project
-
As I understand multiple laser sensors are being detected by kOS. What I have in mind for my project is the following:
Laser1 measures a distance < 0.2 meter - kOS activates action group 1 - Laser1 measures distance > 0.2 meter - kOS deactivates action group 1.
Can kOS run multiple of these processes at once? For example 8 lasers with 8 action groups all at different times?
For this one, I would need 7 lasers.
It should have no issue, the biggest trouble you would have is figuring out which laser goes with each action. The next version of kOS has a few pretty awesome tools that steven wrote to make querying parts easier.
-
Question: can you make a menu or wait for an input from the user? So you can kinda make a menu with your scripts?
Answer: not yet, it is in our backlog to allow it.
-
I need help from KOS gurus to understand what I'm doing wrong... The rocket doesn't keep the apoapsis at 100Km on last burn to establish the orbit (11 seconds on eta:apoapsis) ... it always end up with periapsis of 99Km and with apoapsis of 1,800,000Km :/
Thanks
LIGHTS ON.
RAS OFF.
SAS OFF.
SET alt1 TO 100000. // Target Orbit.
SET heading1 TO 90. // Launch Heading. Usage 0-360 where 0=North.
SET rollalt TO 8000. // Altitude at which to perform the initial roll
SET CountDown TO -10. // Countdown value
SET curFace to SHIP:Facing.
SET totallf TO SHIP:LIQUIDFUEL. // Set total liquidfuel in the ship
SET boosterslf TO 2*(3*180). // set total liquidfuel in the two boosters
SET X TO 0.
SET Y TO 1.
SET flag_ditch_boosters TO 0.
SET flag_jettison_fairings TO 0.
CLEARSCREEN.
PRINT "Orbit altitude set to [" + alt1 + "m]" at (X-1,Y).
//**Begin Countdown.
PRINT MISSIONTIME + " Count down: " at (X,Y).
UNTIL CountDown = -3 {
PRINT "..." + CountDown + " " at (X,Y).
SET CountDown TO CountDown + 1.
WAIT 1.
}.
//**Ignition.
LOCK THROTTLE TO 1.
LOCK STEERING TO UP.
WAIT 2.
SET msg TO round(missiontime,0) + "s Ignition!!! ".
UNTIL SHIP:MAXTHRUST > 0 {
LOCK STEERING TO UP + R(0,0,180).
run screen(X,Y,msg).
STAGE.
}.
PRINT "-2 " at (X,Y).
wait 1.
PRINT "-1 " at (X,Y). wait 1.
CLEARSCREEN.
//**Release the clamps.
STAGE.
//**To make a rotation relative to ships current direction.
//LOCK STEERING TO curFace + R(30,0,0).
//LOCK foreDir to SHIP:FACING * V(0,0,1).
//LOCK foreUnit to foreDir:VECTOR.
//**In flight.
SET msg TO "Launch!!! ".
LOCK STEERING TO UP + R(0,0,180).
UNTIL ALTITUDE > rollalt {
run screen(X,Y,msg).
IF ship:liquidfuel < (totallf - boosterslf) AND flag_ditch_boosters = 0 {
SET msg TO "Release boosters ".
STAGE.
SET flag_ditch_boosters TO 1.
}
}.
SET msg TO "Beginning gravity turn ".
LOCK STEERING TO UP + R(0,0,180) + R(0,-50,0).
//LOCK STEERING TO HEADING (90,40).
UNTIL APOAPSIS >= alt1 {
IF ship:liquidfuel < (totallf - boosterslf) AND flag_ditch_boosters = 0 {
SET msg TO "Release boosters ".
STAGE.
SET flag_ditch_boosters TO 1.
}.
run screen(X,Y,msg).
IF apoapsis < alt1 {
LOCK THROTTLE TO 1.
}.
IF apoapsis > alt1 - 500 {
LOCK THROTTLE TO 0.
LOCK STEERING TO PROGRADE.
}.
IF altitude > 40000 AND flag_jettison_fairings = 0 {
SAS ON.
SET msg TO "Jettison fairings... ".
STAGE.
SET flag_jettison_fairings TO 1.
LOCK STEERING TO PROGRADE.
TOGGLE AG9.
SAS OFF.
}.
IF stage:liquidfuel < 10 {
STAGE.
}.
}.
SET msg TO "Waiting for circularization burn. ".
UNTIL eta:apoapsis < 11 {
LOCK THROTTLE TO 0.
//LOCK STEERING TO PROGRADE.
LOCK STEERING TO UP + R(0,-90,-90).
//SET msg TO "Burn... ".
run screen(X,Y,msg).
//WAIT UNTIL ETA:APOAPSIS < 15.
}.
LOCK THROTTLE TO 1.
LOCK STEERING TO PROGRADE.
SET msg TO "Burn... ".
run screen(X,Y,msg).
WHEN periapsis > alt1 - 500 {
LOCK THROTTLE TO 0.
UNLOCK STEERING.
SAS ON.
SET msg TO "Orbit established!!! ".
run screen(X,Y,msg).
}
//WAIT UNTIL periapsis > alt1 - 500.
SET msg TO "Orbit established!!! ".
run screen(X,Y,msg).I assume you never see the "Orbit Established!!!" message? I think your trouble is that getting within 500 meters of circulation is not happening.
The circularization burn is trying to reduce your eccentricity to as close to 0 as possible right?
so a simple fix for this that i have used is to have the code watch your eccentricity and stop burning when eccentricity starts to rise again. It gets you pretty close.
-
OK, in a likely futile attempt to spur myself into action, I'm going to try to get an RPM integration done. Maybe just a read-only display for now, but we'll see what can be done. Possibly a custom-made volume navigator to manage and run scripts. And it'll have to be able to switch from CPU to CPU, too... Hrmmm... That means I need to enumerate all the kOS CPUs and volumes (separately, since there's at least one volume that has no CPU, and mayhap we'll soon have a decoupling of CPUs and volumes).
I'll be thrilled just to get a single-CPU vessel to display anything on an RPM screen...
Advice i would give anyone trying to do this:
Start with the very simplest and smallest form first. If there is enough interest in that then you can expand it to cover more and more cases. I am excited to see this
-
Hi, I got kOS a few days ago to work with RemoteTech 2. I've been looking at the wiki to try to understand it and came up with this script to execute a circularization burn since I could see the probe would be out of contact at that time. I used the following script but it never stopped waiting for nextnode:eta < 2.
I looked at the node executor in the maneuvering modules of the wiki but the script was too complicated, not well commented and relied on other scripts. It looked like something made to be used rather than understood so it didn't help me much.
Can someone tell me why my script didn't work? Thanks.
There is a config setting to turn on remoteTech integration. In the terminal type
SET CONFIG:ENABLERT2INTEGRATION TO True.
you can also go into the kOS plugin folder and find the config file and change the value manually.
-
I hope people don't mind if I post this here. It's really about the kOS Scriptable Autopilot mod mostly, BUT it's about progress on making kOS interface with other mods, and the showcase mod it's interfacing with is Infernal Robotics:
(I posted this a few days ago but it was in the wrong thread by mistake.)
I really liked the use of the IR gantries. I think this is going to open a lot of cool uses for IR parts in general
-
Well... You should be able to get the parent vessel by name. The problem is that I can't find any documentation (or easily found reference in the source) for getting the target of a different vessel.
Along with erendrake's mass check, you could also check various part counts (only one engine? I've been launched!)
Hmmm... We need a decent way for cores to talk to one another. I suppose you could do some log file trickery to cause a file to appear in the volume for the missile, which could include a quick script to set the target and run its own guidance program. Once we get access to the right-click actions, you could even have the missile decouple and launch itself!
Quick question for erendrake and/or Steve Mading: If a script tries to get a handle on a vessel by name, and there are a number of vessels with the same name, does it return a list?
edit: Here's a thought! Have the missile turn itself off (or better, have a non-missile core power off all the missiles). Then when you want to fire the missile, build the aforementioned "log file" as a boot file for the missile and power it on. The missile will read in the targeting info from its boot file, and then go on to run its guidance routine.
I agree, we do need a nice way to send information between cores. Right now targeting a vessel by name gets the "first" instance of that name. with no real implied order.
-
Hi!
I got a very simple "smart" missile script written. And I'm wondering is there a possibility to make a program witch:
a) loads itself to the missile probe core.
does not affect plane steering.c) still function after detaching from plane?
you should be able to add a kOS processor to the missile probe core. It could have a boot file for these cores that is a guidance computer that only kicks in when you tell it to (eg when the mass gets low enough to know it is detached).
-
Is there a way to set up AGE so that it doesn't save some key bindings for all vessels? Like if I bing crew report to "1", it'll work like this even on different vessel, even though on that vessel I set "1" to different action in VAB.
Can you give me an example of why you would like to do this? Overriding Actions seems like the very thing that AGX was trying to get away from by adding all of the extra Action Groups.
-
Ominous shadows are ominous. that is pretty cool man
-
Sorry if this is a stupid question, but is there a way to make the steering more smooth? I'm a set of statements like "lock steering to heading(90,85).", the problem is the steering is flipping out and oscillating like crazy. The logic that the SAS and mechjeb use is much smoother, but of course I can't use those as well as kOS.
We currently have two ways to control the craft, the automatic "LOCK STEERING TO HEADING" and the raw controls http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html
We originally wanted to give a very basic automatic control and also have the more robust direct control scheme. That being said the automatic system could use a little refinement
-
Hello. Is there any comparability of RemoteTech with MechJeb mod? Since it is quite frustrating when signal disappears and so does the programmed autopilot command of getting into orbit. I can't get even the 1st satellite on RSS orbit.
There is integration with kOS if you want to do unmanned missions. It is a little more involved but there are simple ascent scripts that people have built.
-
I want to understand how the internal coordinate system of KSP works and since there is already a bit of documentation in the kOS Wiki
http://kos.wikia.com/wiki/XYZ_system_of_KSP
http://kos.wikia.com/wiki/Tutorial_with_example_-_Conversion_from_Directions_to_XYZs
I thought, this thread might be a fitting place to ask.
It would be a great help, if someone could point me to additional documentation on this subject.
Digging into the kOS source code is kind of a last resort, which I would rather avoid.
I think that the best way to learn about the KSP coordinate system is to play with the kOS's VECDRAW system
http://ksp-kos.github.io/KOS_DOC/structure/vecdraw/index.html
let us know if you have any questions. Here is a great place to ask.
-
I am feeling quite proud of myself.
print "Initiating SRB.txt Script.".
wait 2.
print "SRB AUTOPILOT LOADED!".
wait 2.
toggle SAS.
wait 1.
print "Preparations complete. Attempting to Launch.".
lock throttle to 1.0.
stage.
when ship:surfacespeed >3 then print "Launched successfully.".
when stage:solidfuel <0.01 then {print "Staging Booster.". stage.}.
when stage:solidfuel <0.001 then {print "Staging Separatron Ring.". stage.}.
when ship:verticalspeed <0 then {print "deploying parachute device.". stage.}.
wait until 1>2.It works! It launches an SRB ship, then it stages a separatron ring, then when the ship falls it deploys the parachute.
That is pretty cool! please keep us up to date on your progress and ask questions.
-
I have gone back to ornithopter development in stock 0.25. I guess I will return to FAR/NEAR when I fell I'm done with playing around with them and climb the aerodynamics mountain later.
cool
keep us posted
does not affect plane steering.
[1.2.2](Dec10/16) Action Groups Extended: 250 Action Groups, in-flight editing. Now kOS/RemoteTech
in KSP1 Mod Releases
Posted
I agree with Diazo, Having a mod that is defined in scope and executes it flawlessly is what all mods should aspire to. My 2 cents would be to skip the "do x action y seconds after action z" is a black hole of intervalometers and other timers that would vastly increase the scope of the mod.