Jump to content

erendrake

Members
  • Posts

    536
  • Joined

  • Last visited

Posts posted by erendrake

  1. 2 hours ago, Steven Mading said:

    Can I request a lock on a thread I don't own but the owner isn't participating on the site anymore?  This is for the kOS mod, where the original thread owner is no longer involved in KSP, and I'm trying to move discussion over to a new thread where the current devs have permission to edit the first post (because the version number is quite out of date in the original thread and we can't edit it).

    Old thread: https://forum.kerbalspaceprogram.com/index.php?/topic/61827-122-kos-scriptable-autopilot-system-v103-20161207/

    New thread: https://forum.kerbalspaceprogram.com/index.php?/topic/165628-13-kos-v1130-kos-scriptable-autopilot-system/

     

    I Approve of this lock. I am no longer active enough to support the kOS team enough to maintain the OP.

  2. New Release

    Github : Download

    Spacedock : Download

     

    BREAKING CHANGES

    • As usual, you must recompile any KSM files when using the new version.
    • Vecdraw :SCALE no longer applied to :START. Only applied to :VEC.
    • Varying power consumption might make it so if you have high IPU settings some designs might run out of power when they didn't before. (in most cases it should draw less power for most people).
    • !!!! Default extension of ".ks" is no longer applied to all new filenames created. But it still will be looked for when reading existing files if you leave the extension off !!!!
    • FileInfo information now moved to Volume (http://ksp-kos.github.io/KOS_DOC/structures/volumes_and_files/volume.html).
    • VOLUME:FILES was returning a LIST(), now it returns a LEXICON who's keys are the filename.
    • String sort-order comparisons with "<" and ">" operators were implemented wrongly and just compared lengths. Now they do a character-by-character comparison (case-insensitively). On the off chance that anyone was actually trying to use the previous weird length-comparison behavior, that would break.

    NEW FEATURES

    BUG FIXES

    • Numerous additional checks to prevent control of other vessels the kOS CPU isn't attached to.
    • The error beep and keyboard click sounds now obey game's UI volume settings. (#1287)
    • Fixed two bugs with obtaining waypoints by name. (#1313) (#1319)
    • Removed unnecessary rounding of THRUSTLIMIT to nearest 0.5%, now it can be more precise. (#1329)
    • Removed the ability to activate both modes on multi-mode engine simultaneously.
    • LIST ENGINES now lists all engines and displays part names instead of module names. (https://github.com/KSP-KOS/issues/1251)
    • Fixed bug that caused hitting ESC to crash the telnet server. (#1328)
    • Some exceptions didn't cause beep, now they all do. (#1317)
    • Vecdraw :SCALE no longer applied to :START. Only applied to :VEC. (#1200)
    • Fixed bug that made up-arrow work incorrectly when the cursor is at the bottom of the terminal window. (#1289)
    • A multitude of small documentation fixes (#1341)
    • Fixed a bug when performing an undock (#1321)
    • IR:AVAILABLE was reporting incorrectly ()
    • Boot files now wait until the ship is fully unpacked and ready (#1280)
    • The Vessel :HASBODY (aliases :HASOBT and :HASORBIT) suffix was in the documentation, but had been lost in a refactor last year. It is put back now.
    • String sort-order comparisons with "<" and ">" operators were implemented wrongly and just compared lengths. Now they do a character-by-character comparison (case-insensitively)
    • Small documentation edits and clarifications all over the place.

    KNOWN issues

    • Using lock variables in compiled scripts with a duplicate identifier (like "throttle") throws an error (#1347 and #1253).
    • Occasionally staging with a probe core or root part in the ejected stage will break cooked steering (#1492).
    • The limitations of RemoteTech integration can be bypassed by storing a volume in a variable before the ship looses a connection to the KSC (#1464).

    CONTRIBUTORS THIS RELEASE

    (These are generated from records on Github of anyone who's Pull Requests are part of this release.)
    (Names are simply listed here alphabetically, not by code contribution size. Anyone who even had so much as one line of change is mentioned.)

    Stephan Andreev (ZiwKerman) https://github.com/ZiwKerman
    Bert Cotton (BertCotton) https://github.com/BertCotton
    Kevin Gisi (gisikw) https://github.com/gisikw
    Peter Goddard (pgodd) https://github.com/pgodd
    Steven Mading (Dunbaratu) https://github.com/Dunbaratu
    Eric A. Meyer (meyerweb) https://github.com/meyerweb
    Tomek Piotrowski (tomekpiotrowski) https://github.com/tomekpiotrowski
    Brad White (hvacengi) https://github.com/hvacengi
    Chris Woerz (erendrake) https://github.com/erendrake (repository owner)
    (name not public in github profile) (alchemist_ch) https://github.com/AlchemistCH
    (name not public in github profile) (tdw89) https://github.com/TDW89

  3. v0.18.2

    Github
    KerbalStuff

    BREAKING CHANGES

    • As usual, you MUST recompile all KSM files before running them on the new version. Some of the changes have altered how the VM works.
    • Nothing else... we hope.

    NEW FEATURES

    BUG FIXES

    • The processor's mode (on/off/starved) is now saved and restored ( #1172 )
    • Fixed stage resources again to address a change in KSP 1.0.5 ( #1242 )
    • Fix occasional instances of flight controls getting disabled during a docking/undocking/staging event ( #1205 )
    • kOS can now trigger module events with RemoteTech installed and no KSC connection (RemoteTechnologiesGroup/RemoteTech#437 )
    • Fixed handling of multiple thrust/gimbal transforms and corrected some of their directions ( #1259 )
  4. If you have tuning parameters whereby this craft can achieve orbit on .18, please share. The point is this craft can be orbited with MJ, pilot assistant, or .17. It cannot with .18 (believe me I spent hours fiddling with alternative ascent profiles and tuning parameters, short of writing my own PID loops).

    I'm not sure why the thin margin was so important. Isn't that a major part of the rationale behind KoS? Precise control for marginal situations? I would be interested to see how, for example, the eve mammoth ssto fares with the new steering method.

    I posted my craft/.ks files as a way to help developers improve the new steering, but apparently my use case isn't valid. Oh well, I have my custom build of .18.1....

    We appreciate you taking the time to share your craft/script and im sure it will help us improve the steering. I think that Dunbaratu is saying that in your post where you said you were getting "unreasonable behavior" you could have been more clear upfront. When you are operating on such narrow margins with such low control authority i am actually pleased as punch that the new steering got as close as it did.

    We will be making refinements to it over the next few patches and we hope that you continue to give feedback when you can think of improvements for our little mod.

  5. Well I went ahead and encapsulated the old steering logic and added a bound variable flag to enable/disable it. Took about 1 hour.

    If the dev team is interested in this, let me know and I will add documentation, open an issue, and submit a pull request.

    Otherwise, I'll just use my modified build of KOS until the new steering becomes adequate for my purposes.

    It would be helpful if you have a script and craft that can only work under the old system for us to test with. This is only the first version of the new system and there is surely work to do to improve it. We are interested in finding out why the new one may not be as good out of the box for some applications and find a way to improve it. All of my tests were very positive in the new system but i almost never fly spaceplanes.

    I dont think anyone who is active on the dev team is interested in including the old system. It was demonstratively broken in far too many situations.

  6. It sure is when you're doing this as a hobby in whatever spare time you manage to make for it. Why would the devs willingly make things more difficult under those circumstances? They are already giving you all this awesome capability for free.

    And are any of the devs able to answer my question posed earlier?

    For your question. I simply have never tried it and we dont test for it. I think that having an advanced kOS part with 2 would be fun and useful. Do we have an open issue in github about it? if not would you mind creating one and we can put it in the roadmap

  7. Github https://github.com/KSP-KOS/KOS/releases/tag/v0.18.0

    [h=3]BREAKING CHANGES[/h]

    • As usual, you MUST recompile all KSM files before running them on the new version. Some of the changes have altered how the VM works.
    • New LOADDISTANCE obsoletes the previous way it worked ( http://ksp-kos.github.io/KOS_DOC/structures/misc/loaddistance.html )
    • Fixed broken spelling of "ACQUIRE" on docking ports. The old spelling of "AQUIRE" won't work anymore.
    • Changed the bound variable "SURFACESPEED" to "GROUNDSPEED" instead, as the meaning of "SURFACESPEED" was confusingly ambiguous.
    • New arg/param matching checks make some previously usable varying argument techniques not work. (We don't think anyone was using them anyway).
    • Disabled the ability to control vessels the kOS computer part is not actually attached to. This always used to be possible, but it shouldn't have been as it breaks the theme of kOS. This affects all the following: vessel:control, part:controlfrom, part:tag (can still get, but not set), partmodule:doaction, partmodule:doevent, partmodule:setfield (can still getfield). These things become read-only when operating on any vessel other than the one the executing kOS module is actually part of.

    [h=3]NEW FEATURES[/h]

    [h=3]BUG FIXES[/h]

    • Made stage:liquidfuel more sane. ( #513 )
    • LIST BODIES returned unusuable structure type ( #1090 )
    • Made "ORBIT" and alias for "OBT" and visa versa ( #1089 )
    • Made vecdraws stop showing bogus atmospheric burning effects ( #1108 )
    • Removed non-functional broken attempts to save/restore variables ( #1098 )
    • KSM files didn't store relative jumps right, breaking short-circuit boolean logic ( #1137 )
    • (user docs) many minor docs fixes.
    • Lock throttle inside a FROM loop was broken ( #1117 )
    • Unlock anything inside a Trigger body was broken ( #1151 )
    • Replaced KSP's incorrect ground speed with our own calculation ( #1097 )
    • SASMODE "radialin" and "raidialout" were swapped in the KSP API ( #1130 )
    • Bug with remote tech allowing access without antenna in one case ( #1171 )
    • Wheelsteering by integer compass heading was broken ( #1141 )
    • SHUTDOWN didn't shut down immediately ( #1120 )
    • Remote Tech delay, and the wait command, were ignoring the time warp multiplier ( #723 )
    • Better detection of arg/param matching. ( #1107 )
    • Doing PRINT AT that runs offscreen threw an error ( #813 )

  8. I just upgraded from 17.2 to 17.3

    did I do something wrong i wound up with two copies of the part CX4181 available in the SPH/VAB

    I also have two name tags for each part...

    Its creeping into the craft files as the crafts have module definitions for two kos name tags.

    I am worried about going on and corrupting the save files.

    it sounds like you have two installs of kOS. maybe one inside of the other? it would be consistent with these errors

  9. care to share the config? :)

    edit:

    nevermind - found it was a package! :)

    Cool - been using NP++ so far as I use that normally but this is a great way to get into Atom, another great editor.

    - - - Updated - - -

    sorry for a self-bump, but I am stumped. I am trying to learn lists. How do I get a list from an object (a ship in this case) that isn't the default? 'LIST ENGINES FROM SHIP.' (or another ship object variable) is returning an error on the first F for FROM, while the same but without specifying a FROM clause is fine.

    we have a known issue for the LIST..FROM..IN syntax. https://github.com/KSP-KOS/KOS/issues/620

    but i think what you are looking for is "LIST ENGINES IN elist" that will give you the list of engines for the current craft.

  10. like how far a engine is from the CoM.

    http://ksp-kos.github.io/KOS_DOC/structures/vessels/part.html?highlight=part#attribute:PART:POSITION

    is there or will there be a warp to command?

    Predictions are hard, especially about the future. We dont have it now.

    I dunno why but I still get a message that is build for 0.90 KSP Add-on checker GUI.

    Maybe you haven't forget to update the file that sets this number?

    That was the problem, we got a PR to fix it this morning.

    https://github.com/KSP-KOS/KOS/pull/944

    Is the feature to scale the terminal window with font scaling accordingly anywhere in your todo list? Pleeeeeeease!

    it is not, you are welcome to add it here https://github.com/KSP-KOS/KOS/issues

    So, what is (at least some) replacement for ship:termvelocity

    ?

    What are you trying to do that you were doing with termvelocity before? is it some kind of metric for limiting throttle? many people use TWR and i think its a find choice.

  11. Don’t mistake my intention RemoteTech is the best mod there is and really makes KSP.

    But I’m finding some things a little strange, and would like to have some light shine on by the developers and/or player. But first of all the my opinion of the latest discussion, propes out of range are lost. as of facing the wrong target, well read what i miss in RT. I won’t elaborate why in prospect of reading time

    1. kerbal has only 1 space centre (unless to powerful mod), But only 1 coms dish array who’s power doesn’t get stronger with upgrading?
      I find it strange that the KSC has a fixed coms range I really miss the opportunity to buy/build (for other celestial bodies) ground connected coms dish arrays. That also can be ranged upgraded to increase range. (having a small prope sitting next to your TS who is stronger than the TS is really strange!)
    2. Sending and receiving.
      This is my Major point, of course receiving information requires a connection, but it shouldn’t be that difficult to receive info. Transmitting on the other hand should require a much stronger dish. RT tries this a little with transmitting power but this only applies to science.
      I would love to see the Sending and receiving max range split up. This allows for a lot more specific antenna usages.
      Like:

    • Omni’s only can receive info they can’t send info. This means u can control the prope but not use it as a relay. (or really nerve relay connection)
    • Dishes can receive info in a Omni direction (can nerve Omni receiving distance, in favour of also having a omni anntena), but can only send/relay in cone connection (and/or buff receiving in cone connection)
      This would allow for a difference In relay purpose antenna’s /satellite and end stage antenna’s /satellite also it fixes lost connection because it’s the facing wrong target since all receiving info is in a Omni direction.

    plz shine your light if this is possible, and or a good idea. Or what it needs to become a good idea.

    Thx Heineken

    Why?:

    I hated that my comms array needed receiving and sending antenna’s , 1 facing the relay, and 1 facing the relayed, and then one for the target.

    Instead I would like to have 1 transmitting comms satellite in high orbit with strong dish, with a couple in receiving in low for covering the dark side of planet without having each low comms needing big dish antenna for contact with the high comms.

    1. asked and answered

    2. We could make one way communication possible. It would likely be combined with blacking out your screen so you could not see what was going on with your craft. because everyone would hate that i think we would stay with synchronized rx/tx

  12. Hey guys.. how do get kOS to detect a stage event? Im trying to write a small script that will print the current mass of a craft after each stage sep, but i cant seem to get it to behave. heres an example of the code:

    set pmg to ship.

    set stg to 1. // stage counter.

    until pmg:mass < 1 {

    on stage { // check if stage has occured (hit space bar)

    print "Stage "+stg+" Mass = "+round(pmg:mass,2). // prints mass of the current stage.

    print " ". // forced carriage return

    set stg to stg + 1. // update count to next stage.

    }

    }

    the problem is that it loops through it, but prints the line endlessly regardless of whether i have staged or not.

    Help is appreciated. TIA.

    You should be able to see what stage number you are currently on with the following structure.

    http://ksp-kos.github.io/KOS_DOC/structures/vessels/stage.html?highlight=stage

    if the number increases you know you staged.

  13. Is there a way to get the layout of a ship?
    I think he means a part list..

    If that is the case. yes you can get parts, you can walk the part tree. there are all kinds of part magic you can do :)

    - - - Updated - - -

    anyone suffering crash? i'm surrfering crash but i can't make sure which mod did that.

    do you get the crash if you are only running kOS?

  14. [h=3]New Version v0.17.2

    On Github

    New Hotness[/h]

    • works with 1.0
    • New infernal robotics integration
    • Better error reporting

    [h=3]Old and busted[/h]

    • fixes keyword lexxing

    Edit: sorry for the soft rollout, we wanted to give a few people the chance to test it. We found some bugs but nothing showstopping. Expect another release in the next few days!

  15. So, if a probe has no connection and the vehicle is in focus, why not simulate it checking all the other options in the target list until it finds one with a connection?

    It's a simulation of backup code on the probe rather than a 'lazy hack', doesn't violate physics and you would only get control if a signal got through which maintains realism. This mode could even use more power.

    What's more, it's easy to code ;)

    I think that is a reasonable approach. for a start we have talked about simply having the craft raise its biggest dish and point it at kerbin if there are no active antenna. There are many interesting ways of improving RemoteTech to make loosing a craft to disconnect less common through proper planning. Its one of the first features i want to add once we get RT updated to 1.0.

    I think we might have a release candidate for people to test pretty soon. RC means that is most likely contains bees that will blow up your solar panels so make sure you back up your saves :)

×
×
  • Create New...