evandisoft

0.5.2 API fixed part tags (e.g. "noauto", required "noauto=" or "noauto x=y" before) reworked autopilot override + "pylink" for better 2D/3D control Science API, science.ros (supports DMagic's Orbital Science and DMModuleScienceAnimateGeneric) OS/Process API (early version of MunOS API for scripts) UI UI: ScrollBox and Scrollbar (early versions, some improvements shall come soon) Lua Fixed lua completion bug for array literals. ROS Built-in functions and objects (added collections, documentation) Fixed break in (nested) foreach (for var e in list)

It's not any more dangerous than what a modder has to do to try out code. Just happens at an interactive pace instead of changing something -> compile -> test -> changing something -> compile -> test I know you know this, but I just don't want people to get the wrong impression.

That is cool, would love to hear what you think about it. It's hard for us to know what is missing from a user perspective.

Version 0.5.1 New Dependency: ModuleManager required for part-values/tags to work API: user can now override/correct the autopilot (autopilot.userFactor) universal staging logic (mono, ion, LH2, ...), resources and propellants OrbitInfo, orbitAt and changes to positionAt and velocityAt TimeStamp and TimeDelta Scripts: launch.ros and control.ros: decouplers marked with noauto tag won't be auto-staged control.ros: auto-staging disabled until throttling or executing node control.ros: srf-retro landing assist and hohmann improved, can now circularize in different SOI lua tutorial scripts removed: This was done to remove clutter. You can copy in the tutorial code if you want the tutorials back. ROS Changes: fixed shadowing by loop variable (var i; for var i...) string comparision is case-insensitive, new identity operator (===) added for case-sensitive compare comparing anything to string first converts it to string (including enums) strings now have .format, .substring, .equals, .compare and .contains methods (case-sensitive)

Version 0.5.0: MunOS: Initial version of our system for running multiple scripts at a time, called MunOS. API: autopilot.disable now also resets killRot to false (was often locking roll in control.ros) api for maneuver nodes, sas, rcs and some other orbit-related properties Lua: Fixed bug where the new function was causing errors when it recieved no argument except the type to instantiate. Scripts: control.ros: maneuver executor, circularize, Hohmann planner, inclination match control.ros: srf-retro throttle limiter (below 10km) as landing helper (full throttle makes the ship hover) launch.ros: fixed the wobble at the end of circularization And also, happy new year.

I found a bug in the lua engine's "new" function when you pass in no arguments beyond the type itself. HashSet=native.System.Collections.Generic.HashSet myset=new(HashSet) Causes an error. Normally I would fix this immediately, but we're working on a big release that is not ready. A workaround is HashSet=native.System.Collections.Generic.HashSet myset=HashSet.__new()

I've started regularly playing with a highly modded install (52 mods). I'm including many of the most popular mods. I cannot make any guarantees, but hopefully if there are compatibility issues I will encounter them. If anyone else encounters compatibility issues, please let me know, and I will start working on a fix immediately.

Version 0.4.8: ROS Changes: ROS: fixed problem with variables with same name launch.ros: pitch-down logic for tilted/off-center engines (Dynawing) target and ship.target - works for bodies, ships and parts (docks) control.ros: targeting, rendezvous and docking assist LiveRepl Changes: Changed Kerbalui to use GetControlID to get a unique controlid for each window. Fixed issue where LiveRepl was making modifications to the fontsize of the default GUI.Label style instead of making those changes to a copy of that style. Hitting run will only save the file if it has been modified in the editor. Otherwise it loads the file from disk into the editor. This will allow you to more conveniently use an outside editor. Scene changes, including revert, now terminate any windows or vecdraws.

thanks. I will work on a fix. (I did not intend to modify anyone else's scale). Edit: I've installed a bunch of mods and am checking for any issues in general. Edit2: After trying a bunch of mods I see that this at least effects ToolbarController. Edit3: Found an issue where I was modifying the default style for GUI.Label instead of modifying a copy of it. I think that is the bug. Fix will be in next patch.

Version 0.4.7: General Changes: time.warp.ready improved added GameSettings and GameEvents into KSP namespace ROS Changes: launch.ros and control.ros now use try..finally fixed delay in repl for native events in ROS LiveRepl Changes: Fixed bug where LiveRepl cleared all Input ControlLocks instead of just the one it had set. Stopped using the ControlTypes.KEYBOARDINPUT lock. Now keyboard input (except camera control) is only locked to the window when the window is focused. Still have to lock ControlTypes.CAMERACONTROLS when mouse is in the window bounds, as otherwise scrolling the mouse zooms KSP in and out regardless of the mouse being over a window and that window being focused.

Version 0.4.6: RedOnionScript (ROS) Changes: Try/Catch/Finally for handling errors. Kerbalua has Lua's pcall. LiveRepl Changes: Fixed an issue where the global keybindings of LiveRepl could be activated when the input is not locked to the window. (input is locked when the mouse is inside the window bounds) Made LiveRepl use KSP's UI_SCALE setting. Hard for me to test this thoroughly as I don't have a monitor with a high enough resolution, but from what I can see it is working. I could add an additional scaling factor in some other setting later, if desired, to make it even larger. One thing I did not find how to scale was the scrollbar. But I was able to scale the part of the scrollbar that accepts mouse dragging. CompletionArea resets the scroll position each time the completion results list gets updated. Lua Changes: Lua reflection api was a bit confusing. I'm changing the terminology to type and runtime type instead of static and type. So what was once a static will now be called a type, and what was once a type will now be called a runtime type. (runtime types are for reflection whereas types are for accessing static members of clr classes or passing as the first argument to new to create a new object.) Removed dofile, loadfile, and loadfilesafe as they do not use the Scripts directory as the base directory and cannot be configured to do so. Versions of these (at least dofile) will be implemented in the future. require can be used because it allowed me to specify the base path. However, require will only run something the first time you call it on some filepath. To make it run that file again you have to do packages[filepath]=nil first.

Thank you for informing us of this issue! The fix will be in the next version released within a few days I think. I've managed to scale everything but the scrollbar widths. A compromise is that I was able to enlarge the area that accepts dragging, but not the part that looks like a bar and goes up and down when you drag it. So hopefully you'll be able to easily drag the scrollbar on your monitor. But the visible vertical bar (if you can see it) will be on the left of a somewhat larger area where you can use the mouse to drag it. (I don't have a high resolution monitor so on 200% ui scale I can only verify that the parts that fit on my screen worked)

Yes, it was great initially and then they did nothing with it. They seem to be doing more recently though, and its probably because of KSP2. I'm just wondering if that could work, because possibly their competition would lead to better features and more money. Though I suppose this is just a silly hope born of me owning KSP1 already and not wanting to have to buy another game.

My wish is that Squad is incentivized to create some very cool new features, then the two dev teams start actively competing as if they are rival games, people buy dlc for both games, and we have two competing space simulator games.

Could be because we aren't really well known by the community. Thanks for replying! Understandable. I used kOS for quite a long time. You could possibly use both. Though I wouldn't try using both's autopilot's features at the same time. You might be able to run scripts from both simultaneously if you are not using KSP api features that would interfere. Merely using the LiveRepl in cases where you are not running a kOS script and have no kOS locks set should be totally fine (though I have not tested it).