• Content Count

  • Joined

  • Last visited

Community Reputation

11 Good

1 Follower

About firda

  • Rank

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Both RedOnion.Script and RedOnion.UI are independent libraries and can be used by anybody (MIT license). The code used to create the test window in the video from Evan (with the "Click Me!" button) looks like this: var wnd = new window function shutdown wnd.dispose wnd.layout = layout.horizontal var left = wnd.add new panel left.layout = layout.vertical var top = left.add new textbox var box = left.add new textbox box.multiline = true box.flexHeight = 1 var right = wnd.add new panel right.layout = layout.vertical var btn = right.add new button btn.text = "Click Me!" var lbl = right.add new label lbl.text = "Clicked 0x" var counter = 0 function click counter++ lbl.text = "Clicked " + counter + "x" += click wnd.y -= unity.screen.height / 3 The purpose of the shutdown function is to close the window when you click the Red Onion launcher button for second time. It is looking for functions named fixedUpdate, update and onGUI, to execute them from the Launcher : MonoBehaviour, so, you can e.g. try IMGUI from inside function onGUI. The list of imported objects can be seen here (the FillRoot method). UPDATE: UI.Window now has ROS-native wrapper that will dispose the windown on engine reset. The engine is also no longer looking for any specific function, because you can now subscribe to system.update (aliased as ksp.update) or system/ksp.idle which are called from FixedUpdate. Subscriptions to update have precedence, idle may get invoked less often (especially if update used a lot of jumps/loops/calls). ROS is currently unable to pause and continue the execution, so, do not write infinite loops (it has execution countdown and will stop the script if breached). I will edit this post later, if we get some feedback...
  2. Was it always needed to DOUBLE click to focus a vessel? I don't think so. Does it behave the same for everybody? 1. Single click just selects the vessel in the list/tree, but does not focus it. 2. Double click selects and focuses. 3. Another double click, when already focused, jumps into the ship. Win10 18xx 64bit, fresh reinstall of everything (new SSD).
  3. part.GetConnectedResourceTotals(, out res, out outRes, true); if (res < DeployResourceAmount) Really looks like rounding error, something like 1/3+1/3+1/3=0.333+0.333+0.333=0.999 < 1. It should probably use Math.Round, but you seem to have it configurable, so it would need another parameter, something like if (Math.Round(res * DeployResourceRound) < Math.Round(DeployResourceAmount * DeployResourceRound)) to mitigate the problem. (Default DeployResourceRound = 100) ...and it could create problem when you try to remove the resource, needing similar check/fix (make everything empty if the difference is < 0.01).
  4. Ahh, the drills, thanks for the info, I will deliver them separately next time. AWESOME! BTW, finished product: ...I will disassemble the SkyCrane and the probe on it, this was just delivery of the Material Kits (tank, storage and flexible docks will stay). The left-most part will ship the fuel up to Mun Station for further use.
  5. Hello, I have a little problem with GC (from USI/MKS) - everything grows extremly large (like 10x the true size), so I have to move it very very far, which gives penalty because any closer would explode the base - it can swallow the entire base which is larger than what I am constructing. Second problem is that it grows into the ground and then jumps to the air, but I have already found out that WorldStabilizer can mitigate this. I have uninstalled it, becase I have installed Kerbal Joint Reinforcement (beta because of Infernal Robotics). The description of KJR suggested it does the same job, but doesn't, so I am installing WS again. It is not that big problem when using WS, I just have to move it far far away and pay the penalty, but it can be used. ...any idea? Mods:
  6. Nope, was some rounding error, or it requires more (greater than) but not exact (same as). I sent three fresh engineers (info states "Crew to Deploy: 3" ... CREW, not engineers), didn't work. Then I disassembled some RCS on the ship I sent the engineers in and IT WORKED! 75 extra MaterialKits did the trick. And then I loaded the save, just when I docked, before deploying. Undocked, thus having the original cew with just one engineer, one technician and three pilots, but with those 75 extra MK and IT DID DEPLOY. Well, the three extra engineers were still within 150m, but not docked. I think I did deploy something earlier with just regular cew, no engineer. Looks awesome, btw, nice mod! EDIT: Loaded again, landed the engineers and then deployed (engineers not needed, the extra MaterialKits were). The Hotel is now officially open: ...damn that thing is power hungry
  7. Any idea why the Mercury won't deploy? I have the MaterialKits right there - 3*3150=9450. Three pilots, one engineer, one technician. Need anything else?
  8. Something like that? I am also using the final Terriers to help the Poodle. is probably overpowered, but I am going to save some poor fellow from the Mun and take him/her together with four tourists to visit my station there, before we return.
  9. kOS is the reason I can achieve orbit with eccentricity 0.0000 (reported by DMagic's Basic Orbit) and see how Apo+Peri are jumping like mad
  10. To OHara: I will definitely try the mod, when I have the time. To Kesa: I know PIDs, wrote some myself: The fine-tuning is usually to miminize overshooting and oscillation. P-only regulator should, in theory, achieve the rotation, PID should, after some dumped-oscillation, achieve that too. So again, I will try the mod. 1. That is where I-part kicks in, because it accumulates the difference quickly, to overrule P-part to make the adjustement quicker (but causes overshooting and oscillation if unchecked - D-part helps canceling this side-effect). But the accumulator will then diminish when you get close to the goal and PID will revert to P-only regulation (with possible constant accumulated offset to counter lower-P factor used in PID regulator, but it would act like P-only with Kp=1 when stabilized). 2. Circular orbit is the condition for stable result, not that the PID would need to know it, it should achieve the goal when e=0. It would not if e>0, because the rotation won't be stable, it would with e=0 and that is all the PID has to care about. 3. PID is designed to achieve stable result (if the set-point is stable) and the goal is keep prograde oriented. The feed-back is the difference between your forward vector and prograde vector and it will try to minimize that difference, which is exactly what you need to get the wanted rotation (assumming infinitesimal dt and infinite precision of numbers, real world gives tiny difference for P-only and tiny oscillation for PID ... look at my experiments in the link, my PID regulator quickly ended with one-bit oscillation).
  11. And what are you doing, when you hit 'W'? If the ship is not rotating, then the universe is. Orbit is something else, you orbit around some body, but rotate around your own CoM. That rotation can be zero in some reference frame and non-zero in another, but at least one of these frames won't be inertial and there would be some fictional forces acting on objects (making Kerbing appear like orbiting around the ship and moon doing some crazy flower-shaped orbits around you ... people actually described geo-centric systems like that, before moving to helio-centric). I have started this, becase I was observing my ship in warp and seen, that Kerbin is rotating around the ship (you can enter the cockpit to see same thing), but I had SAS locked to prograde and the only reasonable thing for me was, that the prograde-locked SAS should actually make the ship rotate (in global reference frame, where the ship is orbiting Kerbin and not the other way around) to match the period of the orbit, becase that is the most stable result, requiring least amount of energy to maintain (zero in ideal world), but KSP is doing something else - it cancels the rotation in global reference frame ... and maybe even the coding of prograde-SAS is somehow wrong, to treat zero-rotation in global frame as stable, which it is not (becase the SAS needs to repeatedly cycle between readjusting to prograde and pseudo-stabilizing in global reference frame, that is just wrong). So, my "if you give it the proper amount of rotation´╗┐ (hit "W" a bit)" and Shadowmage's "You'll need a rotation rate that matches your orbital period." is exactly what I expected prograde-locked SAS to do
  12. Really? The above explains everything. P.S.: Is the ship rotating or the world around it? ...when you hit warp. I never said that FoR must be inertial (well, no FoR is really inertial, because universe is expanding).
  13. And that about ISS confused me, because it sounds like ISS needs A LOT of energy to keep it's momentum, like if somebody was hitting the time-warp, that violates the Conservation of angular momentum. It sounded to me like contra-argument to me stating, that ISS just needs small correction because of disturbances (drag, gravity gradient changes, non-circular orbit, solar wind etc.), but not because of something really inherent: Thank you all, I think I have learned something today. It wasn't easy to see what is wrong with all the possible reference frames (and I have started with me on the ground looking up at the ship, thus rotating together with Kerbin/Earth calling this FoR the Kerbin's/Earth's, but you use that name for different FoR, where Kerbin is rotating), but I think I got it. It is really best to use the biggest reasonable FoR (the one where Sun rotates and orbits around CoM of the system, which is somewhere inside the Sun, but not exactly in its center) to describe the things, which makes sense why it is used in KSP (well, probably CoM assumed in the center of the Sun), not that it would be the ABSOLUTE, or the only possible or correct, but it does not have as many fictitious forces in it, like the Coriolis force. Footnote: If SAS was not canceling rotation (angular momentum) but instead keeping the proper rotation (non-zero angular momentum in Sun's FoR, but ZERO in FoR of anybody on the ground) and KSP was either keeping it or reseting to this stable state, then it would be no problem to build ISS that would keep one window towards the earth, without needing to spend any energy on it (because there would be no real-world disturbances in KSP that real ISS has to correct for). P.S.: I hope that i have used angular momentum correctly, I mean the rotation and hope you get what I mean, if it is not angular momentum. EDIT: Actually, I was working (in my mind) with FoR, where neither Kerbin nor the ship are moving, that is why I imagined the ship rotating when warping, but it can also be made non-rotating in that frame, until you hit warp. That frame is not inertial, btw, and Kerbin IS rotating in it.
  14. And if you give it the proper amount of rotation (hit "W" a bit), then it will keep rotating and pointing in prograde forewer (with e=0) ... or not?
  15. Thanks Vexillar, you have actually supported my claims, if I understood you correctly. Moon is rotating in Sun's FoR but not in Eearth's FoR. Same is true for ISS and the fine-tuning is needed because of disturbances (irregular gravity, drag), not because the rotation would be zeroed by time warp, so it is limitation of KSP, because it zeroes the rotation in ABSOLUTE frame of reference (Sun's / Kerbol's) instead of body's reference.