[1.3] kOS Scriptable Autopilot System v1.1.3.0

[mideg]

OK, I have to call of the alarm. Sorry.

I just repeated the test from a couple days ago, making sure to document everything, using the latest versions etc.

It seems to work perfectly. I launched a test rocket, basically an orange tank with probe core, kOS module and some batteries all the way to space without connection and with repeatedly switching thrust between 0.5 and 1.0 by an kOS-script running locally.

Any one of these things might have been wrong the last time I tried:

- not using the up to date version (I think I did but maybe not?)

- not running the script on volume 1. (dito)

- not setting the use rt-setting correctly (again I think I did that but who knows)

Again, I'm really sorry to have caused a false alarm, it seems to be working as intended. Time to build my automatic satellite network. :-)

[GabeTeuton]

Can i lock or set SHIP:CONTROL:PITCH to a variable i created? and then modify the variable in order to modify the pitch? 'cause it won't let me do it...

i tried "lock ship:control:pitch to o." with caps on, off... and it won't let me do it, it will tell that there's a syntax error at the first ":", this one "SHIP ":" CONTROL...

EDIT: okay i managed SET it using that... but it will only set it once... is there a way to keep setting SHIP:CONTROL:PITCH to a variable until i say it to stop? do i need to use until and some condition that never until i stop the program?

why isn't this working????? i press 8 and 9 and nothing happens........... (though when i run there is no error and the screen shows "this is the current pitch 0")

declare o.
declare p.
set p to 0.001.
set o to 0.
until alt:radar < 0 {
set SHIP:CONTROL:PITCH to o.
print "this is the current pitch " + o at (0,0).
on AG8 {set o to o + p.}.
on AG9 {set o to o - p.}.
}.

can Action Groups Extended mess with this?????? ('cause it's a great mod, it would be awful to have to uninstall it...) I've seen a thread where Diazo was talking to Steven Mading and they were trying to implement AGX with kOS as far as i understood... which was mainly code haha! But i didn't find a conclusion...

Edited October 30, 2014 by GabeTeuton

[Dunbaratu]

Could someone explain how to, or link to an example of "get a handle on a part", long story short I want to switch control to a second command pod, it's a unique part, I know its name, how would I select it and apply the "SET PART:CONTROLFROM" to it?

Thanks in advance.

At the moment it's messy.

LIST PARTS IN PLIST.

FOR P IN PLIST {

IF P:NAME = "something" {

Do_stuff_with_P_here.

}.

}.

In 0.15 there will be a SHIP:PARTSNAMED("something") to make this better.

[Dunbaratu]

can Action Groups Extended mess with this?????? ('cause it's a great mod, it would be awful to have to uninstall it...) I've seen a thread where Diazo was talking to Steven Mading and they were trying to implement AGX with kOS as far as i understood... which was mainly code haha! But i didn't find a conclusion...

It ran into a snag because we insist with kOS that we don't hardcode *anything* to operate on ActiveVessel only. The variable called "SHIP" means whichever vessel happens to contain the cpu part that's executing the code, which *usually* is the same thing as ActiveVessel, but isn't always. During docking operations there's more than one ship in range that could be running kOS code, and they can't both be the ActiveVessel.

The problem we hit is that Action Groups Extended only works on the current ActiveVessel. I don't know if this problem ever got addressed.

[GabeTeuton]

It ran into a snag because we insist with kOS that we don't hardcode *anything* to operate on ActiveVessel only. The variable called "SHIP" means whichever vessel happens to contain the cpu part that's executing the code, which *usually* is the same thing as ActiveVessel, but isn't always. During docking operations there's more than one ship in range that could be running kOS code, and they can't both be the ActiveVessel.

The problem we hit is that Action Groups Extended only works on the current ActiveVessel. I don't know if this problem ever got addressed.

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

[erendrake]

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.

[GabeTeuton]

question, have you upgraded AGX lately? it wasnt that long ago when AGX was blocking us from seeing actions groups.

I started using it not that long ago, i currently have verion 1.18, and i just realized there's a new one... but hey, if i have to uninstall it for my script to work, i will certainly do haha, i mean i've been working with only 10 ag since i started playing, i can bare with the limited amount haha... will version 1.18 and maybe 1.19 stop the code i posted above from working?

EDIT: I deleted agx and it works fine... it gives me strange numbers from time to time, instead of the small 0.001 increment but it works... with 8 and 9... i need to tweak it a little bit and add another key to reset it... can i also add a key still run the program but like release the controls????

Edited October 30, 2014 by GabeTeuton

[Darren9]

At the moment it's messy.

LIST PARTS IN PLIST.

FOR P IN PLIST {

IF P:NAME = "something" {

Do_stuff_with_P_here.

}.

}.

In 0.15 there will be a SHIP:PARTSNAMED("something") to make this better.

Thanks, but you're dealing with a total non-programmer. The "Do_stuff_with_P_here." bit, if I "SET P:CONTROLFROM TO TRUE." its an error "operation not valid due to current state of object", what do I need to do to P to set the parts CONTROLFROM to true?

LIST PARTS IN PLIST.

FOR P IN PLIST {

IF P:NAME = "Mark2Cockpit" {

SET P:CONTROLFROM TO TRUE.

}.

}.

Thanks again.

[GabeTeuton]

OMG i'm so happy, it doesn't do it's job perfectly just yet... but it works... every intended thing works as inteded more or less... i can't believe it... i feel like a little genius! haha

declare o.
declare p.
declare u.
set u to 0.01.
set p to 0.001.
set o to 0.
until alt:radar < 0 {
set SHIP:CONTROL:PITCH to o.
print "this is the current pitch " + o at (0,1).
print "6 increase by 0.01." at (0,2).
print "7 decrease by 0.01." at (0,3).
print "8 increase by 0.001." at (0,4).
print "9 decrease by 0.001." at (0,5).
print "5 resets Pitch to 0." at (0,6).
on AG5 {set o to 0.}.
on AG6 {set o to o + u.}.
on AG7 {set o to o - u.}.
on AG8 {set o to o + p.}.
on AG9 {set o to o - p.}.
}.

i just have one question... as you can see i make it print at line 0,1 "this is the current pitch" now whenever i hit 5 it resets back to zero, but all the numbers to the right of zero stay there until those decimal "places" are needed again... like let's say=

this is the current pitch 0.00001123131231434... (not sure how it gets that far, but when i start to decrease it sometimes gets those numbers... not sure why...)

[(then i press 5...)]

this is the current pitch 0.00001123131231434 (still shows those because the only "place" it needs to show the pitch is the first 0 to the left of the dot... is there a way to "erase those from showing once i hit 5??????

[Diazo]

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.

Edited October 30, 2014 by Diazo

[erendrake]

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 .

[Cairan]

I've got a small bug report (or feature request...) to make regarding LIST VOLUMES.

When you do this:

LIST FILES IN ls.
PRINT ls:LENGTH.

...it provides the proper number of files in the current volume. And of course the list element contains the file names, sizes, etc. However, when you do this:

LIST VOLUMES IN disks.
PRINT disks:LENGTH.

...it returns a list of length 0, and no volume information is given on the contents of the current volume... despite "LIST VOLUMES." returning the proper volume listing of the ship.

It would be nice if it worked as I've described, since it would then enable to do a standardized multi-volume naming script, and if it has the same structure than LIST FILES, then storage space management becomes much more practical by using the filesizes and the available storage space on each volume.

Here's what -should- work if LIST VOLUMES would behave like LIST FILES.

LIST VOLUMES IN disks.
SWITCH TO 1.
SET hdd TO 1.
UNTIL hdd > disks:LENGTH+1 {
  LOG "RENAME VOLUME "+hdd+" TO HD"+hdd+"." TO hdmap.
  SET hdd TO hdd+1.
}.
RUN hdmap.
DELETE hdmap.
LIST VOLUMES.

Please note that it is still possible to get the number of kOS CPUs by running this code:

CLEARSCREEN.
SET hdd TO 0.
SWITCH TO 1.
LIST PARTS IN shparts.
FOR part IN shparts {
  FOR mod IN PART:MODULES {
    IF mod = "kOS.Module.kOSProcessor" {
      SET hdd TO hdd+1.
      LOG "RENAME VOLUME "+hdd+" TO HD"+hdd+"." TO hddmap.
    }.
  }.
}.
PRINT "Number of kOS-CPUs: "+hdd.
RUN hddmap.
DELETE hddmap.
LIST VOLUMES.

Edited October 30, 2014 by Cairan

[Dunbaratu]

@cairan

IMO, all the LIST operations should be made the same, to return a LIST() of items rather than just dump things to the screen.

But a few of them don't quite do it yet. If Volumes isn't doing it, then yes that's a bug.

[FreeThinker]

I'm looking for a simple script which put my satelite heading prograte towards the sun all the time. Anyone give me some pointers?

[GabeTeuton]

I'm looking for a simple script which put my satelite heading prograte towards the sun all the time. Anyone give me some pointers?

As you may or may not know, i'm totally new to this mod, but i guess you could use a vector, which i tried but still don't fully understand how they function, but i believe vectors work with coordinates z,x,y of the game, so i guess that's absolute coordinates... just need to guess once in space, which ones correspond to the sun, does this make any sense?

http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html maybe the cooked controls work...

http://ksp-kos.github.io/KOS_DOC/structure/vector/index.html here's vectors information...

http://ksp-kos.github.io/KOS_DOC/structure/direction/index.html directions info...

From my point of view there should be a way to do what you need fairly easy, but i have no idea how to do it as of now, i guess you could also lock the steering to the sun's prograde point? you could set the sun as your target and point at the prograde of that body which should be facing the sun, i guess? I'm not sure but al least you have some ideas, it shouldn't be more than a single command, (provided there is any sense in my idea, and if you just want it to be pointed at the sun and not to also be taken to orbit by the software)!

EDIT: by prograde towards the sun, you mean kerbin's prograde in relation to it's orbit around the sun? does the sun have a prograde by itself?

Edited October 30, 2014 by GabeTeuton

[undercoveryankee]

I'm looking for a simple script which put my satelite heading prograte towards the sun all the time. Anyone give me some pointers?

It sounds like what you want to do is point at the sun (e.g. so solar panels on all sides of the satellite can get full sun). Sun:Position is a vector from your ship to the sun, which you should be able to convert to something you can LOCK STEERING to.

[GabeTeuton]

I'm currently working in a kind of "altitude holder" similar to the code i made to "trim" the airplane, as it's not as precise as i expected it...

I pretend it to work very much like the trim program but automaticaly let's say... to add pitch whenever the vertical speed is less than -1 (until vertical speed is +1) and to susbstract pitch whenever the vertical speed is +1 (until it goes back to -1), so it will go up and down in a loop but never loosing more than whatever altitude changes at that speed thru those vertical speeds between -1 and +1...

So far i got this=

declare o.
declare p.
set p to 0.01.
set o to 0.
until alt:radar < 0 {
print "this is the current pitch= " + o at (0,1).
print "this is the current vertical speed= " + verticalspeed at (0,2).
set SHIP:CONTROL:PITCH to o.
when verticalspeed <-1 then set o to o + p.
 preserve.
}.
wait until false.

but when i run it it says that preserve is only used inside triggers like when and on, so i added {} to when and then it says that there's a syntax error at the first {}...

declare o.
declare p.
set p to 0.01.
set o to 0.
until alt:radar < 0 {
print "this is the current pitch= " + o at (0,1).
print "this is the current vertical speed= " + verticalspeed at (0,2).
set SHIP:CONTROL:PITCH to o.
when {verticalspeed <-1 then set o to o + p. preserve.
}.
}.
wait until false.

the until alt:radar < 0 is a condition i use to make it work until program ends (by user) as i can't think of another one... open to suggestions on this one aswell...

so How should i work around this to make it keep adding p to o?, o being the pitch, until the verticalspeed > 1, in which case i'll add another line that will do the opposite, when that condition is met (verticalspeed > 1), another line will susbtract p from o until verticalspeed < -1, going back and forth i hope...

PS: i looked on several wikis articles and couldn't find an example on how to use when with preserve.

Edited October 30, 2014 by GabeTeuton

[Cairan]

@cairan

IMO, all the LIST operations should be made the same, to return a LIST() of items rather than just dump things to the screen.

But a few of them don't quite do it yet. If Volumes isn't doing it, then yes that's a bug.

Exactly... Hence my comment regarding LIST VOLUMES as it's behavior diverges from what one would expect from all the other LIST operations, particularly the difference from LIST FILES.

In the meantime, I've yet again hacked something together... I'll share the relevant code when it's polished, but my boot script now does filesize validation, balancing on multiple volumes and create aliases for programs on volumes other than the "master disk" (VOLUME 1), by creating small routines on VOLUME 1 (hd1) which encapsulate the run calls with volume switching:

Ie. Let's say AUTOABORT file is copied from Archive on Volume 3 (hd3) due to free space constraints on Volumes 1 and 2, this AUTOABORT file gets generated on Volume 1 (hd1):

SWITCH TO hd3.
RUN AUTOABORT.
SWITCH TO hd1.

From the calling script's point of view, all is good...

[madlemur]

@GabeTeuton:

Set the WHEN ... THEN ... event(s) outside the UNTIL ... { } loop.

// declare o. // Not needed, since you're setting them below.
// declare p. // DECLARE is only needed when you're passing the values into the script

SET p TO 0.01.
SET o TO 0.

WHEN verticalspeed <-1 THEN {
  SET o TO o + p. 
  PRESERVE.
}.

WHEN verticalspeed > 1 THEN {
  SET o TO o - p. 
  PRESERVE.
}.

UNTIL ALT:RADAR < 0 {
  PRINT "this is the current pitch= " + o AT (0,1). 
  PRINT "this is the current vertical speed= " + verticalspeed AT (0,2).
  SET SHIP:CONTROL:PITCH TO o.
  WAIT 0.001. // No need to loop until the next update
}.

WAIT UNTIL false.

This way, you're setting up the trigger event(s) to update the trim, then going into your loop to print out the status and keep the controls at current trim.

[madlemur]

@Cairan:

Have you seen kOSis?

[Cairan]

@Cairan:

Have you seen kOSis?

No I hadn't... Looks great but I'm having "fun" doing my own stuff too... Years of using Slackware will do this to people!

Thanks for the link, I'll look into what I can inspire myself from if things get stuck, but so far so good.

[erendrake]

I just confirmed that the issue with LIST VOLUMES IN <foo>. Is a real one and i have added an issue on github

https://github.com/KSP-KOS/KOS/issues/308

[hvacengi]

I'm currently working in a kind of "altitude holder" similar to the code i made to "trim" the airplane, as it's not as precise as i expected it...

I pretend it to work very much like the trim program but automaticaly let's say... to add pitch whenever the vertical speed is less than -1 (until vertical speed is +1) and to susbstract pitch whenever the vertical speed is +1 (until it goes back to -1), so it will go up and down in a loop but never loosing more than whatever altitude changes at that speed thru those vertical speeds between -1 and +1...

So far i got this=

declare o.
declare p.
set p to 0.01.
set o to 0.
until alt:radar < 0 {
print "this is the current pitch= " + o at (0,1).
print "this is the current vertical speed= " + verticalspeed at (0,2).
set SHIP:CONTROL:PITCH to o.
when verticalspeed <-1 then set o to o + p.
 preserve.
}.
wait until false.

but when i run it it says that preserve is only used inside triggers like when and on, so i added {} to when and then it says that there's a syntax error at the first {}...

declare o.
declare p.
set p to 0.01.
set o to 0.
until alt:radar < 0 {
print "this is the current pitch= " + o at (0,1).
print "this is the current vertical speed= " + verticalspeed at (0,2).
set SHIP:CONTROL:PITCH to o.
when {verticalspeed <-1 then set o to o + p. preserve.
}.
}.
wait until false.

the until alt:radar < 0 is a condition i use to make it work until program ends (by user) as i can't think of another one... open to suggestions on this one aswell...

so How should i work around this to make it keep adding p to o?, o being the pitch, until the verticalspeed > 1, in which case i'll add another line that will do the opposite, when that condition is met (verticalspeed > 1), another line will susbtract p from o until verticalspeed < -1, going back and forth i hope...

PS: i looked on several wikis articles and couldn't find an example on how to use when with preserve.

I can't test it right now, but here is how I would implement your code:

set p to 0.01.
set o to 0.
until alt:radar < 0 {
    print "this is the current pitch= " + o at (0,1).
    print "this is the current vertical speed= " + verticalspeed at (0,2).
    if (verticalspeed <-1) {
        set o to o + p.
    }.
    set SHIP:CONTROL:PITCH to o.
}.

That way you aren't adding a new when trigger every time you run through the loop. Otherwise you could do it like this:

set p to 0.01.
set o to 0.
when verticalspeed < -1 then {
    print "this is the current pitch= " + o at (0,1).
    print "this is the current vertical speed= " + verticalspeed at (0,2).
    set o to o + p.
    set SHIP:CONTROL:PITCH to o.
    if not (alt:radar < 0) {
        preserve.
    }.
}.
wait until false.

You had the "{" in the wrong spot on your second code block, which is why you got a syntax error. Also, I deleted the declare portion on each script because you immediately redefined the values, but you can re-add them as a declarable variable if you want to assign them from another script.

I'm not saying that this code will accomplish anything, btw. It kind of looks like you'll keep spinning in circles until you hit the terrain, and eventually you'll overflow the variable "o" to be greater than 1. But if you're going for proof of concept, then don't worry about it.

I'm by no means an expert, and will defer to any of the people more experienced than I with kOS.

Edit: I see I took too long to hit post after reading and madlemur already posted some code that looks more helpful than mine.

[GabeTeuton]

Well guys, after several hours of not doing the laundry I managed to get a primitive Altitude Holder to work as desired... it can be further tweaked but it will need nearly constant tweak as ship Level Flight AoA will change as CoM changes due to fuel consumption, and if the vehicle is perfectly balanced to have the dCoM at the same point than the CoM it will still need tweaking as speed will change due to mass decreasing with fuel consumption...

HOWEVER, it does its job onces the basic tweak is set... By basic tweak I mean that the needed U and D variables are set to a specif point according to plane, I have no idea if it's possible to calculate those based on plane specs...

EDIT= in order to get an estimate of U and D, you need to flight to your desire height and at the desired speed (or throttle), then manually trim the airplane with the stock system, until you are more or less satisfied, let's say when VS is more or less 5 m/s (positive value), then quicksave... pause the game, go to the quicksave, search "trimpitch" (the one for your vessel) and there you have a rough estimate of the values of U and D, if the trim gets you 5 m/s VS, then your U is around that pitch... you'll probably want less than that... but not much!

I proudly present=

LOCK VS to verticalspeed.
LOCK THROTTLE TO 0.66. // Throttle also affects U and D,
// 0.66 was selected randomnly...
SET U TO 0.16.         // The pitch up value.
SET D TO -0.075.       // The pitch down value.

clearscreen.

UNTIL ALT:RADAR < 0 {

if VS < 0.1 {

UNTIL VS > 0 SET SHIP:CONTROL:PITCH TO U.
}

ELSE {

UNTIL VS < 0 SET SHIP:CONTROL:PITCH TO D.
}.

PRINT "<Altitude Holder v0.1>" AT (13,0).
PRINT "Radar Altitude= " + ALT:RADAR AT (0,3).
PRINT "Current Pitch= " + SHIP:CONTROL:PITCH AT (0,5).
PRINT "Vertical Speed= " + VS AT (0,7).
PRINT "Pitch Up Setting= " + U + "  Pitch Down Setting= " + D AT (0,9).
PRINT "Program made by GabeTeuton" AT (20,30).
}.

Currently for my plane gains 1 meter every 30 seconds... which doesn't bother me up to this point...

{guys is there a way to allow me to change U or D values while the program is executing????? (that would make the tweaking waaaaay easier)}

I believe the trim feature to be added may make this program easier and waay more precise, but i'm not sure...

If any of you want to test it and help improve it go for it, i'm just starting so this is reaaaaally basic, (though for me it was hard haha)... I'm not sure if I should post it in a new thread somewhere to make people test it... I'm not even sure if anyone may find it useful... But for long trips it works, at least for me...

Thanks to all those who helped me get here! Certainly now i comprehend the power of kOS and with time I may script other things if I'm in need of its infinite power again!!

Next project... fully automatic sattelite deployer, w/RT.

Edited October 30, 2014 by GabeTeuton
add EDIT.

[Dunbaratu]

I'm looking for a simple script which put my satelite heading prograte towards the sun all the time. Anyone give me some pointers?

Do you mean you want it to stay pointed that way all the time even when it goes on rails or you go focus on another ship? As awesome as kOS is, it can't escape from the fact that KSP does not allow anything, human or mod, to adjust the ship's movement when it's on rails. When the ship is on rails, kOS is helpless to do anything with it. Worse yet, when the ship is not within the 2.5 km (or whatever you changed it to) loading limit, kOS can't even run on that ship at all because the kOS part on the ship doesn't even exist, period. It's unloaded from memory until the ship is brought back into view and has all its parts "rebuilt" into the universe.

That makes kOS scripts who's purpose is to keep a ship on a particular orientation "at all times" even when not in view sort of impossible.

It's unfortunate because I think it would make perfect sense to use kOS for a "station-keeping" script like this, but sadly doing so would require more than just a mere mod. It would require changing how squad's own code works.