Jump to content

a.g.

Members
 View Profile  See their activity

  • Posts

    270

  • Joined

  • Last visited

 Content Type 

Everything posted by a.g.

  1. a.g.
    You can also just add your experiment results to the stock ModuleScienceContainer, and avoid having to deal with any details. I also found that that approach allows truly generating science gradually, by adding a report with 0 data in it first, and then incrementing the value every frame until it reaches the full amount.
  2. a.g.
    That is a side effect of some refactorings I made to the orientation math in KAS (for one, previously it used hard-coded cases for just 6 possible node orientations and would have broken with anything else), and fixing the stack nodes on parts where the new code fails is the right thing to do: https://github.com/Majiir/KAS/commit/56abd1710a1720555fd3c116a11158981ad82d64. Since node orientations aren't stored in either crafts or launched vessel files, and flipping the vector like that doesn't really matter for stock, it's safe and won't damage any previous progress.
  3. a.g.
    Try getting rid of that KASResizeFix thing, whatever that is.
  4. a.g.
    Which other mods are you using?
  5. a.g.
    How about maybe right click to switch container if the window is already open?
  6. a.g.
    I noticed that issue in Minmus orbit myself, but have no idea why it may happen. If you mouse over the part, you may notice that its highlight is blinking erratically, and the degree of that may change depending on the camera angle. Right-clicking is also erratic following this blinking. This may be somehow caused by the vessel actually moving: if the velocity is high, Krakensbane absorbs it and in the physics world the vessel hardly moves, while low-velocity orbits have full orbital velocity.
  7. a.g.
    Are you in orbit and using linux by any chance?
  8. a.g.
    To add to what Ferram said: if you don't want/need that node, you can nuke it with a MM config, like I did to those B9 VTOL engines: @PART[B9_Engine_VA1] { !node_stack_bottom = DELETE } It may rather be the orientation of the part: FAR emulates parts as cylinders and cones, and is rather sensitive to the orientation of the main axis of those that it guessed relative to the flow.
  9. a.g.
    How realistic is it that nodes on the back of active engines cause a lot of drag? I'd imagine expanding gases would alter aerodynamics. (A more specific problem is that the B9 VTOL engines for some reason have a node right on the back, unlike all other aircraft engines, and it's impossible to cover it with anything reasonable. ) Also, it seems that the ferram_graph code creates a lot of Texture2D objects and doesn't destroy any of them - yesterday I had KSP crash on me because of running out of memory after a lot of fiddling in the editor, and the backtrace pointed at that code creating textures.
  10. a.g.
    Upload KSP_Data/output.log somewhere for a start. No, containers will just remember that your tank was empty when you stored it and not magically refill it when taken out again. Btw, since now certain parts have individuality in the container, Take & Store is guaranteed to cycle through them in order stored so that you can find the right one eventually.
  11. a.g.
    I've just noticed in the source code that there is an undocumented in-game GUI, which allows tweaking those offset and direction numbers directly in the flight scene. To activate, press Ctrl-K to open the window, then Ctrl-click on your test part to select it. After that you can use buttons in the window to tweak the values in varying increments, and then press G-G to drop and re-grab the part and view the new position. This makes finding the exactly right coordinates a lot easier.
  12. a.g.
    That sounds like a bug reported recently in the KJR thread - when the craft is loaded it sets their break force to an extremely small value by accident, and they all fall off.
  13. a.g.
    It is impossible. What you can do is fiddle with the offsets and direction so it doesn't clip into ground or the helmet. Here are my configs: https://gist.github.com/angavrilov/8971612#file-modulemanager_tac-cfg Note that those configs are for a new KAS version with a bunch of fixes that is to be released eventually, and it changes some internal math in how those coordinates are interpreted; so with the current version the coordinates may be off (or maybe not).
  14. a.g.
    That's because it plainly ignores Serializable unless it's on a class in one of the original dlls, like Assembly-CSharp.
  15. a.g.
    That's a symptom of raycasts that it does to find if it is behind a wing intermittently failing, although I have only encountered that with spoilers attached to the top of the wing before. I have already sent a patch to Ferram that adds a special case for control surfaces structurally attached to a wing, which should hopefully fix this kind of thing.
  16. a.g.
    Also, what's your opinion on the idea to reduce the number of joints decoupler reinforcing creates by using some heuristics? That rocked doesn't really need any, but it patches it up with struts like a spider web - even those bits inside the service bay that connect to the decoupler. Maybe it should only connect parts that are 5x or whatever the setting is heavier than the decoupler and/or any part in the path to them, exclude any that are smaller than the 0.01 mass threshold or are surface attached and don't have anything connected to them, etc?
  17. a.g.
    I wonder if that anchor thing is all it's hyped up to be: as I understand it, anchors are the points specified relative to each connected body, which are considered connected (and around which the joint will rotate if rotation is allowed). That is a PhysX thing, and every joint always has one anchor per body. The only thing they seem to have added is the ability to specify both anchors, instead of specifying one, and having the other one computed automatically by literally converting the first anchor coordinates into local space of the second body via global.
  18. a.g.
    The "Center HUD" button literally centers the HUD on the screen. It's a one-time action that's there in case you want it to be in the exact center.
  19. a.g.
    Posting here, since it says that your PM inbox is full: Did you test if it is necessary for the decoupler reinforcing to create all the links it creates now, i.e. connect basically everything on one side, to everything on the other side? Maybe it can use some heuristics based on the masses of the specific parts and the vessel to decide that. In my case I referred to previously in my PM I have this tiny rocket develop serious orbital drift, which causes a 500km change in Pe height within minutes if amplified by an encounter. This happens on its own without doing any rotations or similar, but only if decoupler reinforcing is enabled. It also seems that the more links I eliminate by a mass cutoff, the more stable it is; I think that at the very least it shouldn't create any links to parts that are already excluded from changing attachJoint because of too small mass.
  20. a.g.
    I actually fixed that yesterday (I think ). In the meantime, does saving and reloading help? I have a hunch it should.
  21. a.g.
    Activating the motor opposite to the current direction of movement should generate energy. I think that is even realistic and happens automatically with the simplest permanent-magnet DC motor.
  22. a.g.
    You can actually add auto-trim like that in FAR too - or after the negative deflection for flaps is re-enabled, anyway. You just configure your elevators to be simultaneously flaps, with an appropriate small positive or negative deflection. Of course, this only works if you have separate elevators which can be tweaked like this.
  23. a.g.
    One place where the 'time warp' argument does not apply at all is flying planes and driving rovers, since in that case it is limited to 4x at most. These two activities are also nearly useless for producing science at the moment. I'm actually experimenting with a plugin that generates science for doing that, but can't decide what the most balanced per minute rates should be.
  24. a.g.
    I think it may be rather that MechJeb sets target to a fictious object that doesn't have an orbit at all - I seem to recall a similar thing with HUD and landing guidance.
  25. a.g.
    Well, for instance this definitely f's up initialization of whatever part this happens in, which can easily cause other stuff to break later:
×
×
  • Create New...