firda

Reminder: ...specifically for those not getting the contract completed upon recovery. I had no other issues with the mod. P.S.: I have seen tomf actually merging my PR (two weeks ago), so, ... maybe ... there will be a release ... maybe

A brave man exploring the [Unsafe] I do that all the time, switching things to public, so that the script can work with it, and experimenting to see what to add to our "safe" API (or learn Unity UI). We will gladly accept new team member willing to work on any part of this mod, just send me PM (with discord ID) if you are interested.

OK, I now see there actually is some interest in this mod (exactly what I asked for), so I now feel obliged to do a release. I am currently working on the Science API, UI.ScrollBox (and ScrollBar) and some collections for ROS (list, queue, dictionary) ... all towards the goal for recreating [x] Science (or something like that) in `science.ros`. I will consult that with Evan, but, will at least put unofficial `.zip` here (in a month) in case we do not agree on the release. I am leaving for holiday in two days Have fun

Thank you, that means a lot to me to see anybody actually interested in this mod... I was loosing hope, feeling like all this work was just "dream unfulfilled" and I should move on to something different. Take a look at the science API here, please: https://github.com/evandisoft/RedOnion/blob/firda/RedOnion.KSP/API/Science.md Feel free to build that version (currently in "firda" branch) before we release it. You should be able to automate science-gathering based on what data you have in KSC (something like [x] Science does) and you can use RedOnion.UI to create any UI you like (with that button - try launch.ros and control.ros to see what you can do with this mod). BTW, you can access raw KSP API already, so you should be able to do anything, including science-data transfers (planned feature for our API) and possibly even that KAL-1000, but would have to experiment with raw reflected API ('native'), possibly crashing the game if you do something wrong P.S.: Use 'ship.parts.science' to get this: https://github.com/evandisoft/RedOnion/blob/firda/RedOnion.KSP/Parts/ShipPartSet.md and eventually this: https://github.com/evandisoft/RedOnion/blob/firda/RedOnion.KSP/Parts/PartScience.md

Thanks a lot, renaming GameData\UmbraSpaceIndustries\MKS\Assets\LightGlobe.mu (to *.remove - changing/adding extension) helped Looks like the above fix is all that is needed ... needs more testing.

Anybody else experiencing loading freeze with MKS_LightGlobe? Removing MKS solved it, KSP.log contained some NRE about (just after) MKS_LightGlobe (PartLoader) when present (and "frozen", pictures still changing, but no progress after that). I will provide necessary logs if needed, now just asking, I know 1.10 is fresh.

After first testing, this seems to work with 1.10, will do more tests. Anybody really reading this? I am not frustrated, but currently uninterrested, some feedback or anybody saying they actually use this mod would help

Allright, does anybody want some feature? There are two kinds of players that may like to use this mod: 1. Modders: the REPL and 'native' is great for exploring KSP API, you can try and learn without leaving KSP. Lua/Moon(Mun)Sharp is mostly what it is, but if you want some feature in ROS, just ask... generics? or at least one-param-generic-no-arg method to be converted to type-arg method (those 'getByType' methods)? Anything? Be reasonable if you want it quick, don't be affraid to express what you need - best would be to say what you want to do/achieve. 2. Players wanting to automate things: I have created some ready-to-use scripts (launch.ros, control.ros - see second post in this topic). Want some feature? Automate solar-panel deploy and retract? Science gathering? (I had something ready... few months ago, left the work when I planned science-containers and probes gathering science for various labs). @Drew Kerman The problem is that I will never release anything if it was just about doing what I want - because I would just do what I want which is play the game, not bothering about what other folks think and want. There is kOS, we know, but I went the route of possibly helping others when Evan found me after what happened at kOS (search for 'parts redone'). I was hoping to help others, especially modders, by partnering with Evan who was already working on that REPL, I was working on ROS... so we joined to create this mod. P.S.: I 'fixed' two other mods I liked... no guarantee: 1. [x] Science: 2. Station Science:

I have some release ready, with science API, with witch you can automate sciene gathering, .... but does anybody realy care? Maybe I should really switch to "what I want" mode, instead of "what folks may want" ... because there is nobody there.

1. Will have to test that, but my code uses different approach - KSP-native AssemblyLoader.loadedAssemblies, looking for a) class named DMModuleScienceAnimate in module DMagic derived from PartModule (Magnetometer Boom etc.) b) class named DMModuleScienceAnimateGeneric in module DMModuleScienceAnimateGeneric derived .... so it is not dependent on namespaces, just class-name and dll-name, nothing else. NOTE: that is not part of the PR, but you can find it in my code here: https://github.com/firdacz/KSP-X-Science/blob/firda/DMagic.cs 2. No need for such MM-patch because I fixed the code which now works with DMModuleScienceAnimate directly (that is/was the purpose of the PR). EDIT: Actually, I did not push that version. Will test it and do it when I have time. The code involved looks like this: EDIT2: Updated, dll here: https://github.com/firdacz/KSP-X-Science/blob/firda/GameData/[x] Science!/[x] Science!.dll?raw=true Note that it was created 5.4.2020 but I did test it just now, after updating everything. Looks like I fixed a problem that did not even exist at that time.

Unfortunately, I no longer have the save and craft designs. Will remember to include them next time I encounter something. Nice mod, keep up the good work.

See this post: I have ZeroMiniAVC installed for a long time (I use CKAN), so I did not even notice the problem, and BTW, even removed MiniAVC from my build of this mod: https://github.com/firdacz/KSP-X-Science/tree/firda/GameData/[x] Science!

Try deleting "[x] Science!\PluginData\[x] Science!\settings.cfg" instead of reinstalling. Anyway, include at least KSP.log to get any support, some require output_log.txt / Player.log - see

@Flupster Found why DMagic's Orbital Science (e.g. Magnetometer Boom) does not work: deployDMExperiment expects IScienceDataContainer not ModuleScienceExperiment https://github.com/DMagic1/Orbital-Science/blob/a4e805b9f819692a1546b741683da64b783694fe/Source/DMAPI.cs#L111 https://github.com/Flupster/KSP-X-Science/blob/3ba43b8d0ff550ee9f91d65d8cfaa1202c5acf31/X-Science/DMagic.cs#L166 https://github.com/Flupster/KSP-X-Science/pull/8 P.S: My DLL is here: https://github.com/firdacz/KSP-X-Science/blob/firda/GameData/[x] Science!/[x] Science!.dll?raw=true (includes some changes about EVA on ladder around KSC)

What is the orientation of the kit? How do I check? How do I make sure up is up? I have base-addon build in SPH: build a ship (with seconady mission on top, but that is not relevant) land and start building, but it grows in wrong direction - it should be flat, not growing up! EDIT: This little arrow? Is that up? (I do not really care what is left and what forward, but that should be knowable as well .... and things imported from SPH should not end like this!) However final result is as expected ... strange ... the expansion is wrong/strange, but the result is ok:

That sounds like exception in event handler to me, seen those from various mods lately (since 1.8), usually NRE (NullReferenceException). I assume that such a thing stops the event-handler chain which has catastrophic consequences, one of them being "InputLock" not released, which leads to no control, keys and buttons not working etc. BTW: I built it against 1.9.1, but that should not be a problem. EDIT: Doing another experiment (Prograde Kuarqs in my Mun Station) ...you can see it is modded - ReStock, ReStock+, other Nerteas, ScanSat and other DMagic's, USI, K&K (ok, cannot see that, but I have a base down there)... no problem (well, KIS/KAS crashed it yesterday, but I have seen some NREs from USI prior to this and attaching EVA strut using KIS/KAS is no trivial task) Sure it completed as expected:

scratch that, I probably misunderstood how it works

I am playing with this build: https://github.com/firdacz/StationScience/tree/firda/GameData/StationScience navigate to branch "firda" (if the link does not already) and copy the content of the directory, or at least the dll inside "Plugins" into KSP (overwriting the old one) - this is the version I currently play with and it works for me. The "master" branch is there for the PR in original repo (minimal, not built, I am not the creator or maintainer of this mod), "debug" branch prints some diagnostics into KSP.log Note that I rewrote it a lot to even be able to build it and then understand how it works, so "master" is really minimal change to the original, but you would have to build it from source yourself (firda and debug are built - ready for use).

I hope everybody is well and we stop the virus soon

To be clear: I am not the maintainer of this mod, just a programmer/modder that found a problem (recover not working) and fixed it for myself (and created PR in original repo). I never had problems with switching ships (it just checks again), so my version may still not work for you, but you can give it a try (it works in my game). As for the debug build - it prints something into KSP.log that could help identify problems. I can add some more printouts specifically for the problem of switching ships (send me private message if you want help, I do not want to polute it here).

Small bug made it to release: last part-tag is ignored (e.g. "noauto"). Workaround: use "noauto=" (or "noauto x=y") instead

Cannot help with the "does not come back after switching to the ship with the experiment" unless you use my debug version and provide more info (PM me), but the release build works for me: https://github.com/firdacz/StationScience/tree/master/Kerbal Space Program/GameData/StationScience (just finished one experiment and got two new .... not sure what was wrong with my "hard" game, had to edit the save to remove some tourists not connected to any contract) P.S.: Debug dll here: https://github.com/firdacz/StationScience/raw/debug/GameData/StationScience/Plugins/StationScience.dll

@tomf Any update on this? I did fix the accept/finish-problem for myself (PR still pending), but I have different problem: looks like the contract is rarely generated, StnSciContract.MeetRequirements is almost never even called by KSP and the SetExpiry inside Generate uses default 1-7 days which makes it even harder to spot any contract if it gets generated, making the probability of getting any contract miniscule. I am new to all this stuff (contracts), any idea? EDIT: Looks like my "hard" game is was somehow broken, it works in my "default" (and now in that "hard" as well - talking about my build).

1. This really needs at least KSP.log, because your description sounds more like general "InputLock" problem than autopilot holding "FlyByWire". Some other mod can do that (e.g. TooManyOrbits had this problem, fixed recently). Also try the reset buttons in the REPL (reset autopilot, reset process) first. You may also try "ksp.inputLock.printLockStack" and/or look at the locks in the Alt+F12 debug window. Being in any editor field may also be holding the controls (to get the keyboard input). 2. The purpose of the autopilot is to control the ship, so you either control it by a script or not. Pitch control is not so easy to override without totally confusing the autopilot. Nevertheless, I created some way of correcting / overriding the autopilot a bit in the code we are currently testing. The main problem is that when you set a direction for the autopilot and then manually override pitch/yaw, the autopilot will immediately try to compensate, because it treats your input as external disturbance (like drag), but the code being tested now (in firda branch) feeds the user input into the PIDs, which is not ideal, but somehow works (e.g. the surface-retro landing assist now lets you adjust the landing zone by user pitch/yaw controls, works a bit like hover, good for low-tech science gathering around KSC). Also "user.pitch" etc. were added to access user controls which you can then use in the script to react to user/player input and e.g. change the direction you feed into the autopilot accordingly (the new feature has "autopilot.userFactor" etc. to control the strength of user input for changing the autopilot output, setting it to zero reverts to original/current behaviour which is no user control and you can then use "user.pitch" or "player.yaw" to e.g. change the angle instead of directly controlling pitch/yaw - the user input can be used in various ways, another would be to control altitude of a helicopter by throttle controls - but you first need to script that well). P.S.: Is the above the real code used? You should be saved by the 100-instruction rule here (hoping that the "wile true; if ... wait" won't eat 100 instructions), but generally, the button-clicks are handled asynchronously and could interrupt your main code at any time, which includes just after the "if stab" test, which it could pass, then execute the handler (disabling autopilot) but still continue and execute the "autopilot.direction = ..."

Was not sure what was the source because I have noticed some timed control locks lately as well (1.8+), usually when working with nodes. Actually, can you edit second maneuver node? The gizmo does not work for me on second node, but the new bottom-left thingie does work. It had some problems in 1.8, much better now in 1.9. Also had DMagic's Maneuver Node Evolved, so uninstalled that first, thinking it was the source (wasn't). P.S.: And thanks for the screen with the Input Locks window, didn't know it is there (got too used to doing stuff in the REPL).