Jump to content

Dunbaratu

Members
  • Posts

    3,846
  • Joined

  • Last visited

Reputation

914 Excellent

3 Followers

Profile Information

  • About me
    Capsule Communicator

Recent Profile Visitors

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

  1. "When saving them in drive 0" from kOS or from outside the game in some file manager or text editor? I believe when kOS *reads* the files it can accept them without mentioning the .ks but when *writing* them you need to explicitly include it. When in doubt just state it explicitly. Also, if you are on Windows, be aware of the secret trap where the default settings for its file manager window actively lie to you about the filename by hiding the extension portion of the filename. If you are on Windows, then in Windows Explorer (the file browsing window), open the folder Ships/Script and click folder options in the top of the window and then "view" and there should be a checkbox that hides extensions. It's turned on by default and you need to change that so it will stop hiding the true filenames.
  2. "Why" as in "What is the mechanical difference in how the game implements them?" or "Why" as in "What was the reason for choosing the implementation that has this limitation"? I can answer the first, but the second is harder as that requires dev insider knowledge. The mechanical difference is that Gilly, being a moon, is modeled as a kind of CelestialBody, while asteroids are a type of Vessel, much like flags are a type of Vessel and Kerbals floating in their EVA suits are a type of Vessel. The game does not calculate the effects of a vessel pulling on another vessel due to gravity, since most of the time a vessel's mass is so small that the effect isn't worth the computing time it would take to bother. Also, when you go into time-warp mode, the game doesn't *really* use Newtonian gravity from a celestial body to pull on the ship anymore, it instead just uses Kepler's ellipse formulas to decide where along the orbit path the vessel would be at time=t. To do that in the stock game model requires that the body you are orbiting be your sphere of influence center point. So that answers the first kind of "why". As to the second kind of "why", now I have to speculate about what was in the dev's heads. But I'll do that. I just want to throw the caveat that at this point I'm trying to read their minds and this is not definitive: So here goes: To do gravity with asteroids using the stock system, those asteroids would all have to be modeled as tiny planets with their own little spheres of influence. The sphere of influence model really breaks down at that point, as you have to be SUPER close to the asteroid before it's gravity is strong enough to treat it like its own little pocket reference frame that ignores perturbations from the sun. I suspect they didn't bother because it's an organizational mess to have that many asteroids being modeled as planetary bodies instead of as vessels, especially when for the smaller ones their spheres of influence wouldn't even be above their ground altitude. Imagine if it treated them as planets what the map view would look like with all those little orbit lines. I think before it becomes even possible to do it well, the game would first have to leave behind the sphere of influence model and use an N-body model like Principia mod does. And a change like that is *massive* and breaks some other parts of how the game is meant to be simple for players.
  3. Update: I found a way to identify which of the thrusterTransforms are actually present in the current part variant and which are not, so I made a PR about it.
  4. @garwel I had some time today to look at the problem and I think I know what's wrong. I don't know how to fix it yet, but I know the cause of the problem. The problem also occurs in stock, not just restock, BUT it is slightly exacerbated by restock. But what *is* relevant is that the problem is caused by changes in KSP 1.11.x versus KSP 1.10.x. It was correct before KSP 1.11.0. Specifically it did this: KSP RCS part modules have an array of all the rcs thruster transforms (position plus orientation) for the part. i.e. the one-nozzle RCS thruster has just one thrust transform for the one nozzle, but the 4-way block has 4 thrust directions one for each nozzle. kOS calculated the torque capability of the RCS part by iterating over these thruster directions and summing up the torque they can give based on where they are relative to center of mass KSP 1.11 introduced the new feature that RCS parts have variants. For example you can use the version of RCS block that angles the nozzles slightly out, or the variant that has them straight. To implement the variants in KSP 1.11, the superset of *all* possible nozzles across all variants are defined in the array mentioned in bullet point (1) above. Presumably there exists a place where it's specified which of them are actually present. kOS didn't "know" about this change so it was still assuming all the rcs nozzle definitions in the array are all present at once. So it was calculating torque as if all the nozzles for variants other than the current variant will be thrusting too, and thus getting values much too high. It's a bit worse with Restock because it apparently defined more variants. (There are 9 variant nozzle positions in KSP 1.11 stock RCS 4-way blocks, and 18 variant positions in restock RCS 4-way blocks). The fix will have to involve me finding out where in KSP it defines which of the variant rcsTransforms are the ones currently actually existing in the part, and ignoring the ones for other variants.
  5. This seems to be only happening during scene setup, and only with people who have lots of mods. Once scene setup is done the messages stop. I don't know the cause but it is harmless at the moment. It seems kOS is being told to start running FixedUpdate() before the scene is done being set up, so kOS hasn't initialized everything yet. It may be a race condition that only occurs when there's a lot of mods so scene setup takes longer than normal.
  6. Okay I had a look at this today. First I started by recreating your vessel in pure stock without Restock, to see if Restock was doing anything funny to it. I got the same thing in pure stock that you were getting. Also, you didn't tell me the reason it was taking 40 seconds was because it overshot the setpoint and kept oscillating back and forth across it. That's relevant. The picture I had in my head was that it was taking 40 seconds to turn agonizingly slowly toward the target, not a mere 3 seconds plus another 37 seconds wavering around before settling down. That's a very different kind of problem, generally caused by kOS thinking there's way more torque available than there really is. (So it thinks it can stop in an instant when it can't.) I don't know yet why the torque values being reported are clearly weird, and I'll have to examine that in detail, but for the time being this seems to really help with that design, as a workaround: set steeringmanager:pitchtorquefactor to 0.25. set steeringmanager:yawtorquefactor to 0.25. set steeringmanager:rolltorquefactor to 0.25. This tells kOS "pretend the vessel's torque capability is only 1/4 as big as it's being reported to be, and act accordingly." How I know the values are bogus - the R1-IX thruster should be doing 0.1 kN of thrust. In any one rotation axis the best case is having 4 of them helping push that rotation (i.e. pitch by having two at the bottom push one way and two at the top push the other way). The entire vessel is only about 5 meters long, so if we assume a Center of Mass halfway between one end and the other, that's a torque of 4 * 0.1kN * 2.5m or about 1Kn*m. But the torque it was *claiming* was about 2.5to 3 Kn*m. So something is probably wrong with the kOS TorqueProvider replacement code, and I'll have to look into that. But that's a long term thing. In the mean time, try the 3 lines above (put them somewhere temporary you can remove later if a future release of kOS fixes this).
  7. I had a brief window of time to test this today but this information wasn't true. The save file is for KSP 1.11.2, not 1.11.1 so I have to re-download a fresh copy to perform the test on KSP 1.11.2, and that means I'll try tomorrow. (I barely had an open window of time today and having to prep a different install of the game with the right mods etc pushes me over the time limit.)
  8. That should only happen when the total rotation time it takes to get aligned is less than 4 seconds. The description says it's longer than that even in stock SAS.
  9. I don't see this when I try it in stock so I'm going to have to try your exact mods and your exact save to see if I can reproduce it. I'll try that tomorrow.
  10. It was never something I worked on. Not using a controller myself it's not a thing that's really on my radar much.
  11. That makes me wonder if it would be worth it to have kOS spend a few clock cycles copying the vectors it receives into a normalized form when doing LOOKDIRUP() and VANG(). With VCRS() and VDOT() the magnitude is relevant so it can't do it there, but for LOOKDIRUP and VANG the magnitudes don't matter. (VXCL() could do it to the first argument (the normal vector of the plane being projected onto) but not the second.)
  12. That is really strange. Can you try this experiment: normalize the m and k vectors into unit vectors first, before you pass them into LOOKDIRUP(). Is the mun one still zero if you do that? LOOKDIRUP() is letting Unity do the heavy lifting under the hood, and a lot of Unity's stuff only uses 32-bit floats. It might be that the mun angular velocity is just too small to survive the floating point error in the underlying Unity call. As a rule of thumb, if you are doing an operation where you don't really care about the magnitude of your vectors, only their aim, then getting your vectors normalized before passing them through operations like lookdirup, vcrs, vdot, vang, etc, can help with precision. (Sometimes even when you *do* care about magnitude, you can make things more precise by first memorizing the vector's original magnitude, then normalizing it and running it through the vector operator, then multiplying the result by a scalar afterward to restore the proper magnitude.)
  13. The new contracts introduced in KSP 1.11 were quite bugged. They keep consistently having contract parameters with weird wrong values for the ID number of the parts and vessels you are supposed to repair, so that when you repair them it doesn't recognize that as being the correct vessel that went with the contract. Here's 3 issues in the bug tracker about them: https://bugs.kerbalspaceprogram.com/issues/27308 https://bugs.kerbalspaceprogram.com/issues/27203 https://bugs.kerbalspaceprogram.com/issues/27020 It would be entirely justified to pull open the Alt-F12 menu and cheat the contract as "finished", since it's literally impossible to finish them with the ID mismatches they have. (Alternatively you could risk trying to edit your save file to make the ID numbers match so the contract becomes possible.)
  14. Thanks for the information. I'm taking further conversation to the github issue about it.
  15. Well, it sort of does... but ... the reference frame SHIP:RAW that all the velocities are returned in is the reference frame the main game uses, which is centered around the active vessel's current Sphere of Influence body. In other words, if you are currently orbiting Kerbin, then you are getting Kerbin's velocity relative to itself, which is why it's zero. If you want its velocity relative to the Sun, you can just not care what's the reference frame it's using and just explicitly subtract one velocity vector from the other, like so: print "Kerbin is orbiting The Sun at " + (kerbin:velocity:orbit - sun:velocity:orbit):mag + "meters per second.".
×
×
  • Create New...