Jump to content

allista

Members
  • Posts

    2,208
  • Joined

  • Last visited

Everything posted by allista

  1. FYI, posting this here: KSP-1.3.1 has a small (one liner, really) but nasty bug in localization system that affects asteroids and who-knows-what else. The bug effectively prevents KSPFields of integer type to be persistent, as a module can't read in OnLoad what it had written in OnSave. In asteroids ModuleAsteroid can't save its seed, so on each load it changes shape. That's the source of bugs were things attached to an asteroid become visually "detached" (and what really happens is that the asteroid changes below them): http://bugs.kerbalspaceprogram.com/issues/16087#change-82157 So I guess, or rather hope, that we'll soon see KSP-1.3.1.1 or something too fix this. For my part, I've made a workaround in AT_Utils that will prevent asteroids from changing, if you have old saves to start with. Wait a couple more days for the release.
  2. Should they weight the same, or have the same amount per tank? I cannot afford the changes to the common tank type that affect many parts and resources, so either you'll have to bear with that discrepancy, or to adjust the tank config (the second file) accordingly, to keep things in balance.
  3. I'll try to make the patch as soon as they're updated to 1.3.1
  4. @Shaman, to what tank type do you suggest to add it? EDIT: currently only the LiquidChemicals seems appropriate, but it is used mainly for fuels.
  5. It does not conflict with FS or any other .dll that allows to manage part resources. It does conflict, however, with mods that patch stock fuel tanks, because CC also patches them. So when you use CC and GS .dlls to make your own parts work, it's alright. Only the MM patches cause conflicts. I object against the following: @UsefulVolumeRatio = 0.95 @TankCostPerSurface = 2 The "Soil" tank stores non-aggressive solid resources that do not require any special treatment. If Snaks implies that "Soil" is some kind of organic waste, it's better to place it into the "Waste" tank type: TANKTYPE:NEEDS[TacLifeSupport] { name = Waste UsefulVolumeRatio = 1 TankCostPerSurface = 2 //pressurized PossibleResources = Waste 1.33; WasteWater 0.995; //1t/m3 }
  6. It does by default. With no way of turning it off, actually Yep, @swjr-swis is right. I haven't upgraded TCA to the last KSP version yet, sorry.
  7. The installed modules (along with other TCA settings) are indeed saved with the craft file to save you the reconfiguration of TCA each time you want to launch the same craft. To change craft's modules, in editor open the TCA window and press the Modules button. I agree that if you never had the need to configure TCA modules this looks counterintuitive. I'll try to improve this logic. Especially in the light of the new default configs feature in TCA-3.5 Cheers
  8. I'm developing it already, but it will take me some time, as my new work leaves me very little time of my own, and it's a decent piece of coding.
  9. @LatiMacciato, could you elaborate on that whole thing: what are you trying to achieve in the end? And what mod uses snacks+soil combination? Edit: oh, didn't see your edits. Processing...
  10. Yep, do that. There probably won't be many calculations since CPR resources tend to have their units to be liters, so it will be 1u/L in CC config. Just tell me what mod to check for and I'll add the snacks to the Food tank type, and Soil to Soil (ashes to ashes )
  11. Thanks! Now this is literally an issue: https://github.com/allista/hangar/issues/190 Because grapples and hatches are supposed to work together and in quantities. Oh, this whole thing with vessel attachment is maddening! As for request: it belongs to CC, rather than here. There's the configuration that manages what resources CC tanks (hatch is such a tank) can hold: https://github.com/allista/ConfigurableContainers/blob/master/GameData/ConfigurableContainers/TankTypes.cfg
  12. Yep, that's a problem. And i don't know how to solve it properly. CC allows me to use any resources in CRP in my mods without the need to bloat the game with even-more-poorly-modeled recourse tanks. But both RF/MFT and IFS also modify stock tanks, hence the conflict. Most of CC patches check for all known conflicting mods and do not install CC modules if they're found. But MM patch ordering mechanism is not sophisticated enough to resolve circular dependencies because of the FINAL stanza which most of these mods use. The only thing you, as a user, can do, is to remove CC patches to only have CC functionality in dedicated parts from my mods.
  13. Sorry for late response. You're missing MultiAnimators.dll from AT_Utils. This dll is included into hangar's distribution and into the full AT_Utils distribution, but not into other mods (as they don't use it). I'm not sure it's a good design; I just try not to bloat the game with unnecessary code. Thanks for through description. I'll try to reproduce and fix it.
  14. @B-STRK, so this issue had returned again It's that IScalarModule framework that messes things up, but I honestly thought I've fixed it. Will try to figure it out yet again... To temporarily disabled have conversions of the stock bays, delete this patch: https://github.com/allista/hangar/blob/master/GameData/Hangar/MM/Squad.cfg
  15. A known problem caused by incorrect orientation of the model of that body. Simple workaround is to add a probe were the front should be and re-root at it (press 4, then click the body, then the core, if I remember correctly). And you can always see how the content is oriented when editing hangar's content (see the video I've posted with the last release). Orientation switching, on the other hand, while it can be implemented, is a difficult design problem: launch orientation is a property of the hangar, but a hangar, generally, can hold several ships, so you need to decide, how to launch each, when it is stored; you also need some meaningful way to display the ship during switches, and a way to choose between the six possible orientations, preferably without testing each in turn.
  16. They are mutually exclusive, so you just don't install both of them at the same time. If you're using CKAN, it won't happen; if you're installing manually, it's your responsibility to not end up with two mods that do the same thing and conflict. As for the mentioned "convention" -- it is not so. A convention is something that people discussed and agreed upon. No one discussed this with me. So I'm not including patches that will effectively render my mod inactive in favor of another mod. The user has the privilege to choose between them.
  17. Basically it strips all tweekable resources with mass, with the exception of some preconfigured ones here: https://github.com/allista/GroundConstruction/blob/master/GameData/GroundConstruction/KitResources.cfg This config may be patched by MM like any other.
  18. In the beta, all settings that you can change in Editor, could be saved as default for new crafts. In the current version it's only possible to save them per craft. But there's no notion of global settings in TCA: everything is stored inside ships, and there's no propagation of config options to already flying ones.
  19. AT_Utils a common library for all my mods. I'm not aware of anyone else who use it, so the only mods that need to be kept in sync with it are: TCA, Ground Construction, Configurable Containers and Hangar.
  20. TCA has no explicit support for remote tech; but it does for the stock comm net, acting like separate control source (which allows to lands without comm signal). So i guess it should also work with RT, but you may want to check it first in a sidekick save.
  21. I'm sorry for not being here for a while: my new work leaves me little time to spare But as little as it is, I still use it to make TCA and other mods better! And now I need your help: as usual, for testing TCA 3.5 !!! Beta Testing, Regression Testing !!! Lots of improvements in orbital autopilots! Completely reimplemented Attitude Control using PID cascades + gain scheduling + adaptive gains. Lots of bugs fixed! Lots of new bugs created! Lots of old functionality broken! (truly, I hope not!) https://www.dropbox.com/sh/givuxyi2biqaujz/AADNTc5mYVplkSPTj2rqluGQa?dl=0 Technical: TCA changes come along with many changes to AT_Utils, so if you're using any other of my mods and want to test, you need to also install the beta-versions of these mods (available through the same link). They will should work the same as current versions. How to report bugs: Try to reproduce the bug several times and write down the recipe for me to also reproduce it. Collect output_log.txt (win) Player.log (linux, mac) and share it here (dropbox, gdrive, etc.). Note: KSP.log is almost useless, don't bother posting it. It would be great if you could also provide screenshots and/or videos of what happens. It would also help if you provide .craft files or .sfs (saves) files along with mod list for better reproducibility. And thank you all in advance!
  22. All this designed for parts already instantiated in editor (or parts in-flight, in my case). It should work with prefabs as well, but be carefull with GetModuleSize, as modules in a prefab are not started so may not be completely initialized. I hope that's enough to get going with
  23. GetModuleSize is like GetModuleMass/Cost -- it retrieves modified size from IPartSizeModifier modules, if they're present. What I do is I actually measure them mesh-by-mesh, encapsulating either meshFilter.bounds or meshFilter.vertices (for wheels, not needed in Editor), all transformed from meshFilter.transform to part.transform: https://github.com/allista/AT_Utils/blob/4d68ac1e5e4fa0a6dfcaf8f790d9384541039476/Metric.cs#L91 I've wrote this in KSP-0.24 times, when there was no notion of size in editor. Now the ShipConstruction calculates ship size almost the same way, using MeshRenderer.bounds (which are in worldspace) and remembering, unlike me, that there are also SkinnedMeshRenderers There's a bug in current ShipConstruction.CalculateCraftSize method, though, preventing it from accounting for part.boundsMultiplier and part.GetModuleSize (I wonder, does anyone noticed it yet?). Here's what KSP does: [snip]
  24. Thank you for the report, and sorry for not being able to answer quickly. I'll update the message to make it clearer.
  25. Hi everyone. I'm not an engineer, so maybe this is common knowledge already, but during TCA development I've encountered a problem with numerical instability of Vector3[d].Angle methods at small angles. Both methods use the same straightforward implementation: public static double Angle(Vector3d from, Vector3d to) { return Math.Acos(Math.Min(Math.Max(Vector3d.Dot(from.normalized, to.normalized), -1), 1)) * 57.2957795130823; } Which is fine, unless rounding errors start producing cosine values > 1 that get clamped, which results in angle "measurements" like this: *this, of course, depends on the vectors themselves, as most of the error comes from normalization. So I've started looking and, soon enough, found a paper reciting a much more numerically stable approach: https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf (page 47, top, don't mind the title ) What's more, as it uses arctangent of direct quotient of sine and cosine, we can use the standard atan2, which is robust at all angles: public static float Angle2(Vector3 a, Vector3 b) { var abm = a*b.magnitude; var bam = b*a.magnitude; return 2 * Mathf.Atan2((abm-bam).magnitude, (abm+bam).magnitude) * Mathf.Rad2Deg; } No normalization, no clamping, and much, much more reasonable results: So if you happen to have the need for accurate angle measurements in Unity, this is a cheap and effective solution.
×
×
  • Create New...