Jump to content

[kOS] The Automated Mission Challenge


Recommended Posts

I'd be more than willing to amend the rules when you've cleaned up your light delay code as you mentioned. The only reason I used the rules I did was because I wanted to avoid using other mods like RemoteTech while still requiring transmission times to be taken into consideration. Because the only time you can be absolutely certain that your craft will not impact anything before it receives the transmission is when it ls landed or in a stable orbit, I decided this was the best restriction I could impose. It would be much fairer and realistic if an actual light delay calculator was used.

Okay, here it is. I got around the "cant' query selected volume yet" problem by just making it be a parameter the caller has to give the program, as in "This is the volume I intend to switch back to to run this thing".

I changed its name to "kscCmd", as in "command from Kerbal Space Center", because in future I'm contemplating other potential radio delays like the delay between two vessels talking to each other, and I wanted to distinguish this from them.

kscCmd(cmd,vol,fancyPrint).


//KOS - simulate lightspeed delay between
// craft and home based on distance craft
// is from archive. Any time you want to issue a
// command to the vessel manually you must do so
// via this script in order to simulate the long
// delays caused by lightspeed.
//
// NOTE: This script assumes the following situation:
// 1. To execute a command requires a round-trip transmission,
// becuase you need to see the craft returning the result back.
// So the time it takes to go twice the distance from craft
// to Kerbin is used in the calculation.
// 2. An additional pad of 3 seconds is added on top of that
// so the code still has an effect when near Kerbin.
// 3. The code only simulates the problem of long lag time,
// and does NOT address the issue of having to use low bandwith
// due to the noise and weak signal across long distances.
// Therefore sending 1k to the craft or sending 5k to the craft
// takes just as long. It's only the initial lag time to get to
// the first byte of the transmission started that's being accounted
// for.
//
// You are allowed to keep this script on your home archive and run it
// from there, as it is meant to simulate something initiated from
// ground control:
//
// To run, you do the following:
//
// RUN kscCmd( "command.", volume , display ).
//
// Where "command." is any arbitrary KOS command. Note you DO NEED to
// include the period at the end of the command inside the string. Also,
// if the command string has a literal string embedded inside then you
// have make it a string variable because you can't embed quotes inside
// literal strings in kOS and there's no way to protect quotes in quotes.
// (There's an example of this below).
//
// The second argument is the disk volume of the remote craft to
// use as your selected volume while running the command.
//
// The third argument is a boolean 0 or 1 that enables or disables
// the printing of the countdown timer box. The countdown timer
// box is printed under the assumption you are scrolling along
// and printing your things at the bottom of the terminal window.
// If you've clearscreened before running the timer will appear outside
// the box.
//
// Examples:
//
// Report what's on the remote drive volume 1, and don't show the
// timer countdown box:
// run kscCmd( "LIST.",1,0).
//
// Report what's on the remote drive volume 2, and DO show the
// timer countdown box:
// run kscCmd( "LIST.",2,1).
//
// Make the remote drive copy a piece of software called program3
// from the archive to its volume 1, and then run it, then remove it:
// run kscCmd( "copy program3 from 0. run program 3. delete program3.",1,1).
//
// Print "hello" on the remote drive. Note that because you can't
// put quotes inisde quotes, you have to make it a seperate variable to do it:
// set arg to "hello".
// run kscCmd( "PRINT arg.",1,0).
//

declare parameter rdCmd. // command the vessel is doing.
declare parameter locVol. // local Volume the command is meant to run on on the remote disk.
declare parameter doDisplay. // true if you want to show the display box, false if not.

switch to 0.
set lSpd to 299792458. // light speed in m/s.
set extraPad to 3. // Extra seconds to wait on top of lightspeed delay

// BODY:DISTANCE is bugged at the moment and returns
// a number that isn't allowed to play maths with
// other numbers (some sort of cast error). Therefore
// I'm faking it with POSITION minus kerbin radius:
set kerbDist to KERBIN:POSITION:MAG - 600000.


// Let's assume a round-trip transmit is required:
set totDelay to ( kerbDist*2 / lSpd ) + extraPad.
print "RADIO DELAY FROM KSC IS: " +
floor(totDelay/60) + " min, " +
floor(mod(totDelay,60)) + " sec.".
if doDisplay {
print "+-----------------------------------+----------".
print "| " + rdCmd.
print "+-----------------------+----------------------".
print "| MY DISTANCE TO KERBIN = " + round(kerbDist,0) + " m".
print "+-----------------------+---------------------+".
print "| RADIO DELAY REMAINING:| |".
print "+---------------------------------------------+".
}.
set startTime to time:seconds.
set dLeft to totDelay.
until dLeft <= 0 {
if doDisplay {
print
floor(dLeft/60) + " min, " +
floor(mod(dLeft,60)) + " sec. " at (26,34).
}.
set dLeft to totDelay - (time:seconds - startTime).
wait 1.
}.
if doDisplay { print "Done " at (26,34). }.
print "RADIO DELAY OVER.".

// ===== Self modifying code to run rdCmd: =====
// Clear old file, making sure it exists first
// so delteing it won't give an error if it doesn't:
log "dummyline" to delayCmd.
delete delayCmd.
// wrap command with 'switch to 'locVol and 'switch to archive.':
log "switch t" + "o " + locVol + "." to delayCmd.
log rdCmd to delayCmd.
log "switch t" + "o 0." to delayCmd.
// run it:
run delayCmd.

Link to post
Share on other sites
Okay, here it is. I got around the "cant' query selected volume yet" problem by just making it be a parameter the caller has to give the program, as in "This is the volume I intend to switch back to to run this thing".

One thing it does NOT do is automatically time warp through the delay for you. I probably could add that as an optional parameter for people that want that.

Link to post
Share on other sites
Uhm. No. You can't be seroiusly trying to pretend this is analogous to anything in the real world. First off real world computers can clear RAM without naming each variable individually. Secondly bad software even if that accusstion wasnt bull**** still does not make half the vessel vanish from reality.

Sorry, I was unclear: a well written KerbalScript 0.9.2 prgram clears problematic varibales before it finsihes. in general it's only a few that you need to worry about - strings, and values that may become very small or large, and vessels

Stop pretending this is even remotely like a real world problem. I won't insult your intelligence by pretending you believe what you said.

That one works around problems in the software envirnment is a real world practice, and as an anecdote, back in 1991, I wrote chemical plant control software and the compilers' optimiser had a glitch whereby it would fail to return the value of a variable it had optimised into a register. To work around this many of my functions ended

  return val;
stoopid_compiler(*val);
}

And, tongue in cheek, it's just possible that failure to do this, coupled with failure of mechanical saftey systms may well have caused half a (pressure) vessel to (metaphorically) disappear from reality.


DECLARE PARAMETER att_message.
DECLARE PARAMETER att_start.

SET att_plus TO "+". IF TIME:SECONDS<att_start {SET att_plus to "-".}.

PRINT att_message + " at t"+att_plus+ ROUND(time:seconds-att_start,1).
LOG time:seconds +"|"+ att_start +"|"+ MISSIONTIME
+"|"+ VESSELNAME
+"|"+ VELOCITY:ORBIT:VEC +"|"+ BODY +"|"+ BODY(BODY):POSITION
+"|"+ att_message
TO missionlog.

//load/save bug...
SET att_plus TO 0. SET att_message TO 0.


Link to post
Share on other sites
Sorry, I was unclear: a well written KerbalScript 0.9.2 prgram clears problematic varibales before it finsihes. in general it's only a few that you need to worry about - strings, and values that may become very small or large, and vessels

You were clear. I am well aware of your incorrect claim. When you make the claim you did, you are pretending there isn't anything in need of being fixed about the underlying system because you've put the blame on the higher level code instead for a problem that it didn't cause. You are also pretending that it would be possible in the real world for a software error to edit the laws of physics themselves and cause the impossible to happen when you claim this has any similar analogy to real world situations. No autopilot for a real world airplane, no matter how badly written, can cause the universe to delete the wings from the fabric of reality itself. Break them by abusing the plane? sure. Have them not break but in fact literally vanish from reality? No.

No real world program can cause the laws of physics to break. If you *could* you'd have a Nobel prize on your hands. But the software that controls a simulation can cause the fake laws of physics inside the simulation to break. And when that happens, there is no analogy to be made with real world software for that situation. None.

And, tongue in cheek, it's just possible that failure to do this, coupled with failure of mechanical saftey systms may well have caused half a (pressure) vessel to (metaphorically) disappear from reality.

Bad analogy. You're talking about a thing that is possible in reality and then choosing to deliberately describe it incorrectly because if you described it correctly it would undermine your point. Described correctly, a chemical explosion is not causing matter to "disappear from reality" like what happens when kOS fails to load the vessel because it can't parse the format that kOS itself used to store the vessel.

Edited by Steven Mading
Link to post
Share on other sites

Ok, ok. Lets stop arguing about whether or not kOS's bugs are analogous to the real wold in this thread please. If you guys want to continue to debate, please do so through PM. Thanks. :)

Also, Steven Mading, I'll probably get around to modifying the rules to allow the delay program in the next few days. My midterms are coming up so I'm a bit pressed for free time right now.

Link to post
Share on other sites

[edit] Sorry Thrfoot, you hadn't posted when I started typing this :( I'll shut up now :sealed:

You were clear. I am well aware of your incorrect claim. When you make the claim you did, you are pretending there isn't anything in need of being fixed about the underlying system because you've put the blame on the higher level code instead for a problem that it didn't cause. You are also pretending that it would be possible in the real world for a software error to edit the laws of physics themselves and cause the impossible to happen when you claim this has any similar analogy to real world situations. No autopilot for a real world airplane, no matter how badly written, can cause the universe to delete the wings from the fabric of reality itself. Break them by abusing the plane? sure. Have them not break but in fact literally vanish from reality? No.

I think you are missing the point, I guess you're maybe taking this as an assault against your programming skills or something, I thought the comment was intended as a bit humorous with the smiley and all, not a claim that kOS doesn't have an issue. The argument I think JoCRaM was making is that yes there is a problem in kOS, but a coder could take the problem into account and take steps to prevent it from happening with his program. Which is true, a program can be coded to work around and minimize the probability of a kOS variable persistence bug, despite your claims for this being impossible. (okay, a crash at an inopportune moment will still ruin your day if it happens before you're ready to save) Now, in kOS you can't just reset all variables easily for saving and random crashes do happen, so I do agree that it is impractical and should not be necessary, but stop pretending like it could not be done at all.

This whole good/bad code thing is a bit philosophical anyway. If there is nothing wrong in the program per se, it can't be badly coded, but if it doesn't take into account the limitations of the environment it is running in and therefore can cause ship breaking bugs, can the program be well coded? Well, yes I guess, but does that turn a program that is well coded and takes into account the limitations of the run environment minimizing the chance of bugs appearing into great coding? :cool:

I'm also not clear on the relevant difference between a part going bye bye because of a kOS-Kraken or because of an explosion. In both cases the end result is the same, a part goes poof, though of course the possibility of it happening IRL, the timeframe of the event and the resulting debris is different, but none of these are that relevant to whether you can or should work around it in code. If the parts exploded on load instead of disappearing(or decouplers fired randomly or whatever realistic thing as opposed to a magical vanish), would you be okay working around the problem in a kOS-program until a fix comes out, since it no longer breaks the laws of physics? :wink:

Anyway, after all that rambling my take on this matter in the end is in support of you. One should be allowed to edit the persistence file to work around the variable-persistence-kOS-bug-thing for this challenge. Because of the game-breakingness of the bug it's probably on the top of the fix-list when/if Kevin comes back and then such bug workarounds become redundant bits of code. :huh:

I'll tip my proverbial hat for anyone who does work around the bug inside the code, but in my opinion it shouldn't be a requirement, merely a personal choice on the method of banging your head against the persistence-bug before it's fixed. :confused:

Edited by Sacred Aardvark
Link to post
Share on other sites

OK here's my NASA style mun mission.

It's entirely scripted, nothing is calculated on the fly (excluding staging). Does hit Mun SOI and get back to kerbin and land on landing legs though! Reliably, even. Sometimes it breaks half the solar panels off on launch, don't know why, there isn't anything they can hit. This is one of the runs where it did that.

May have gone slightly overboard on the screenshots, I was awfully pleased with myself.

Javascript is disabled. View full album

It does Science, too!

lock steering to UP + R(0,0,180).
lock throttle to 1.
wait until time > 402627060.
print "launch in ten.".
wait until time > 402627065.
print "launch in five.".
wait until time > 402627070.
stage.
print "wheeee! Liftoff at " + time.
wait until altitude > 7500.
print "7500m gravity turn.".
lock steering to UP + R(0,0,180) + R(0,-50,0).
when stage:liquidfuel < 1 then stage.
print "Outta fuel, staging.".
wait until altitude > 20000.
print "more gravity turn!".
lock steering to UP + R(0,0,180) + R(0,-65,0).
wait until apoapsis > 75000.
print "High enough. Coasting.".
lock throttle to 0.
lock steering to prograde.
wait until eta:apoapsis < 26.

lock throttle to 1.
print "Making a circle-ish out of it.".
wait until periapsis > 71000.
lock throttle to 0.


toggle AG4.
print "Good enough.".




lock steering to heading 270 by 0.
wait 30.
set warp to 2.
set target to mun.
wait until time > 402628400.
set warp to 1.
wait until time > 402628560.
set warp to 0.

print "Off to Mun.".
lock steering to heading 90 by 0.
wait until time >402628590.
lock steering to heading 90 by 0.
lock throttle to 1.
wait 38.
lock throttle to zero.


wait until altitude > 1900000.
wait until altitude < 800000.
toggle AG3.
wait until altitude < 80000.
toggle AG4.
lock steering to retrograde.
wait until alt:radar < 8000.
toggle AG1.

wait until alt:radar < 450.
toggle AG2.

I calculate this as 2 points, as my Mun orbit wasn't exactly stable. Unless returning from a free-return Mun trip counts as returning from Mun orbit, in which case three. I'm guessing two though.

This is a lot of fun :D

Edited by Bobnova
Link to post
Share on other sites
You were clear. I am well aware of your incorrect claim. When you make the claim you did, you are pretending there isn't anything in need of being fixed
Poppycock. I've already stated my opinion that kOS isn't ready for this sort of challenge, I've expanded the kOS issue tracker for this with further variable types that cause issues.

there are actually three bugs here

  • the kebalscript interpreter can't parse its state dumps. (that's an "in game" bug, and like the unterminated string or brace bugs I'm happy for them to stand)
  • the seconds is that the kOS game mod allows kerbalscript bugs to break it. unterminated strings, missing closing braces and state dump problems should simply result in a briked kOS computer, that a reboot may or may not fix.
  • the third is a KSP bug, a mod thorwing an exception should not cause the craft to load nor the game to fail.

No real world program can cause the laws of physics to break. If you *could* you'd have a Nobel prize on your hands. But the software that controls a simulation can cause the fake laws of physics inside the simulation to break. And when that happens, there is no analogy to be made with real world software for that situation. None.

Well, in the real world, the KeralScript bug would brick the kOS computer. your mission is still screwed. You work around the probelms in the run-time envrironment. Stop pretending that the fact it breaks "physics" makes it a special case.

Edited by JoCRaM
Link to post
Share on other sites

I did this a while ago. Alas, I do not think this qualifies according to the rules. However I thought people here might be interested. An honorable mention mebe?

Anyhows... This is a K-prize qualifying run, all under kOS control. Clicky pic below to play. Video is on Skydrive.

10771511616_d3cfd4d8bb_o.png

Link to post
Share on other sites
Well, in the real world, the KeralScript bug would brick the kOS computer. your mission is still screwed. You work around the probelms in the run-time envrironment. Stop pretending that the fact it breaks "physics" makes it a special case.

JoCRaM, I'm going to give you the benefit of the doubt and assume that you didn't see my earlier post. I do not want to see any more posting related to this argument in this thread. This tread is for the Automated Mission Challenge, not debating kOS's bugs, and while I will tolerate the occasional side-conversation, this argument is showing no signs of being resolved any time soon. Hopefully I won't have to, but if I see another post furthering this argument in this thread, I'll have no choice but to bring this issue to the moderators. If you absolutely must continue arguing about this, please do so in PM, not here. Thanks. :)

OK here's my NASA style mun mission.

It's entirely scripted, nothing is calculated on the fly (excluding staging). Does hit Mun SOI and get back to kerbin and land on landing legs though! Reliably, even. Sometimes it breaks half the solar panels off on launch, don't know why, there isn't anything they can hit. This is one of the runs where it did that.

Nice work! I'll add you to the leaderboards as soon as I get a chance. Edit: Done!

I did this a while ago. Alas, I do not think this qualifies according to the rules. However I thought people here might be interested. An honorable mention mebe?

Actually, I don't see anything in that video that would disqualify it. Unless I'm missing something, you could consider that an entry if you want. It'd only be worth 2 points though. :P

Edited by Thrfoot
Link to post
Share on other sites
the vessel contains Kerbal(s).

Yup, and MechJeb too (though i did not use it obviously). I actually copy-hacked the MJ part to have both MJ and kOS functionality actually, which is pretty neat.

Really nice plane. You had spaceplane autoland program? Can you share?

Well the program flew the whole mission. You can find it here.

Note that the program is specific to the craft, but the algorithms can be tweaked and adapted to another SSTO Spaceplane.

Link to post
Share on other sites
JoCRaM, I'm going to give you the benefit of the doubt and assume that you didn't see my earlier post. I do not want to see any more posting related to this argument in this thread. This tread is for the Automated Mission Challenge, not debating kOS's bugs, and while I will tolerate the occasional side-conversation, this argument is showing no signs of being resolved any time soon.

Keep in mind that it was an argument about what to allow FOR THIS CHALLENGE. Had JoCRaM's argument convinced you it would affect the rules of the challenge.

So it mattered to the contest. It wasn't off topic.

On the subject of that ruling, I'd be perfectly fine with making it dependent on kOS version so that assuming progress on kOS does resume at some point and the bug fix does make its way into a working official release, this rules exception about the persistence file goes away at that point.

Edited by Steven Mading
Link to post
Share on other sites

@bsalis, Technically the rules only say there can't be Kerbals on board. It doesn't say there can't be crew modules *capable of* holding Kerbals. So if having a Kerbal on board becomes an issue that people use to dispute your entry, you could just run it again with the exact same design of ship, but just make sure the cockpit is empty when you take off.

Edited by Steven Mading
Link to post
Share on other sites
Keep in mind that it was an argument about what to allow FOR THIS CHALLENGE. Had JoCRaM's argument convinced you it would affect the rules of the challenge.

So it mattered to the contest. It wasn't off topic.

JoCRaM never directly challenged my decision to allow persistence editing, he merely pointed out it was not the only solution, and thus was, in his mind, was unnecessary. It is for this reason that I did not get involved in the argument, as well as because he had not yet provided me with a compulsive reason that persistence editing should not be allowed. However the argument the two of you were having, while it started off because of JoCRaM's comment, was more about whether or not kOS's game-crippling bugs were analogous to real world problems and should be handled as such than if persistence editing should be allowed. I decided to pull the plug before it got out of hand and cluttered up the thread. Not to mention I probably would have done the same at some point even it it was about the challenge.

However, all I am asking is that this argument not continue in this thread. If the two of you want to finish it off in PM, I have no problem with that. You can also PM me if you disagree with my decision to allow persistence editing. But for now, my decision remains unchanged.

On the subject of that ruling, I'd be perfectly fine with making it dependent on kOS version so that assuming progress on kOS does resume at some point and the bug fix does make its way into a working official release, this rules exception about the persistence file goes away at that point.

Yep, that's the current plan. The challenge will (hopefully) always assume that the user is using the latest version of kOS, so if and when the bugs persistence editing fixes are resolved, I will remove persistence editing from the rules. :)

@bsalis, Technically the rules only say there can't be Kerbals on board. It doesn't say there can't be crew modules *capable of* holding Kerbals. So if having a Kerbal on board becomes an issue that people use to dispute your entry, you could just run it again with the exact same design of ship, but just make sure the cockpit is empty when you take off.

I specifically wrote the rules as I did to allow this, in case people had made similar missions with kerbals on board. This way all they have to do to validate their entry is to dump their "cargo" before takeoff. :P

So bsalis, if you are at all interested in making a valid entry out of that mission, I believe it'll require extremely few (if any) modifications to your existing design.

Link to post
Share on other sites

My kOS K-Prize run was done as a personal challenge before I know of this Challenge. I may give a legit run again sometime, mebe even kick it up a notch and trying a VTOL landing instead of a glide. (i started working on a hover algorithm a while ago but lost interest)

In any case - I know the K-prize Challenge has a Gatecrashers list. No reason you can't have your own.

Link to post
Share on other sites
In any case - I know the K-prize Challenge has a Gatecrashers list. No reason you can't have your own.

Good point. I'll go ahead and make an honorable mentions section. Your mission is definitely impressive enough to earn a spot in it. :)

Edit: jpaverly was kind enough to make an extremely awesome mission patch for this challenge. He's currently taking requests here: link

Edited by Thrfoot
Link to post
Share on other sites
  • 3 weeks later...

Hello all,

I was told to try and post my endeavor here on this thread. I created an automated flight to land on Mun and back to Kerbin. The reason I did this was to have something cool to put on my resume that involved orbital mechanics to apply to SpaceX.

I compiled the flight into a video explaining what I did technically speaking. Here is the link to the video (audio might be a bit bad but its my first video ever :P).

I dont know if this counts as an official post to the challenge but I figured a video would be sufficient instead of screen shots.

Problems I see:

-I use Engineer to get data read outs. I know its supposed to be all stock so if this disqualifies me I understand.

-The video is meant to show just the major technical achievements so its cut in places to shorten the 30 trip to about 10 min. I dont know if that would change the validity of my post.

-If you need the code/craft files I can give them to you here but in the link to the video there is a link to the craft files and code in the description if you are interested.

Please let me know if this is acceptable as a post and if not please let me know how I can make it acceptable! Thanks!

Link to post
Share on other sites

So, for the future of this challenge…. what are the possible ways to deal with the fact that the official public release of kOS won't run on KSP 0.23 and we can't assume Kevin will be coming back any time soon to rectify that?

I see two possible approaches (if you see another one let me know):

1 - Keep the use of stock kOS from the spaceport, but then also state that the challenge must be performed on an install of KSP that's on the old version (0.22) that kOS used to work for. If you don't have access to a 0.22 installation of KSP then too bad you can't participate.

2 - Allow people to start using 0.23 of kOS but then that means picking some sort of semi- official version of kOS that people have been compiling and putting up themselves on cloud hosted public shares as the baseline for the challenge.

The problem with allowing privately compiled own-versions of kOS is that there can be lots of slightly different versions with lots of slightly different features and fixes - so you'd have to pick just one of them and keep it the official one for the challenge.

Link to post
Share on other sites
Hello all,

I was told to try and post my endeavor here on this thread. I created an automated flight to land on Mun and back to Kerbin. The reason I did this was to have something cool to put on my resume that involved orbital mechanics to apply to SpaceX.

I haven't yet had time to view your video, but good luck making it into SpaceX! I know that's where I'm going to try to get a job when I get out of college. :D

EDIT 1/13/14: Ok I took a look at your video and am sorry to say it does not qualify as an entry. However, it would be very easy to modify it so it does. Here's what you need to change:

1. Remove the kerbal from the manned pod prior to launch. The challenge necessitates that the mission be unmanned.

2. Only execute programs from either stable orbits or when landed on the surface of a body. It would be easiest to just run each of your "phase" programs from a master program with a time delay between each.

3. Remove Kerbal Engineer (I wouldn't have turned down your attempt if this was the only rule violation, but since you have to re-do it anyway you might as well remove it for the challenge run)

I might have missed something, so it wouldn't hurt to run through the rules yourself just in case.

Its also worth noting that you won't need a video of the mission, just screenshots documenting the process. You're welcome to make a video if you want to though. Good luck! :)

So, for the future of this challenge…. what are the possible ways to deal with the fact that the official public release of kOS won't run on KSP 0.23 and we can't assume Kevin will be coming back any time soon to rectify that?

I see two possible approaches (if you see another one let me know):

1 - Keep the use of stock kOS from the spaceport, but then also state that the challenge must be performed on an install of KSP that's on the old version (0.22) that kOS used to work for. If you don't have access to a 0.22 installation of KSP then too bad you can't participate.

2 - Allow people to start using 0.23 of kOS but then that means picking some sort of semi- official version of kOS that people have been compiling and putting up themselves on cloud hosted public shares as the baseline for the challenge.

The problem with allowing privately compiled own-versions of kOS is that there can be lots of slightly different versions with lots of slightly different features and fixes - so you'd have to pick just one of them and keep it the official one for the challenge.

We'll probably go with option #2. I know nothing about modding KSP, so if you or someone else would be willing to handle updating it to 0.23 I can put a link up on the main page. We'll just run with that until Kevin (hopefully) returns and releases an official version.

Edited by Thrfoot
Watched video
Link to post
Share on other sites
  • 3 weeks later...
Random question: is there a reasonable way to do the logical equivalent of an if-else in polynomial time or (ppreferably) in linear time?

I don't even know what polynomial and linear time are. My programming knowledge only dips into the intermediate levels. You might have better luck asking around in the kOS mod thread.

Link to post
Share on other sites
Random question: is there a reasonable way to do the logical equivalent of an if-else in polynomial time or (ppreferably) in linear time?

Two problems with this:

1 - An if/else is not a looping mechanism. As a mechanism that can only branch forward (not backward), discussions of algorithm timings sort of don't apply. You need some concept of looping and therefore a count of "how many iterations" of it for that sort of question to be meaningful (to me).

2 - This is the wrong thread anyway. Questions about the language itself rather than about this challenge *using* the language should go in the mod showcase thread for kOS.

Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...