Jump to content

allista

Members
  • Posts

    2,208
  • Joined

  • Last visited

Everything posted by allista

  1. For ground workshop there isn't: it can recycle anything within 300m radius, same as with construction. For orbital workshop the recycled vessel should be docked. Hm... this poses a problem, as docking may re-root the vessel, making it inaccessible for recycler. Have to think about it...
  2. Slowly making recycling of parts and vessels for GC...
  3. Haven't had time yet, too much work at work Was planning to address this at the weekend; if family allows
  4. Always interesting to look at things people make; and want to be sure nothing's wrong.
  5. Percent of the volume used is not the thing to look at: it shows literally how much volume of the whole hangar space this particular ship occupies. But since ships are not liquefied in hangars, you can't fill a hangar to 100% unless ship's geometry exactly matches the shape and size of the space. 50% is actually pretty good packing for a single ship. The more important and strict constraint is that the ship should geometrically fit inside the space. But with parts like rover wheels (which have suspension) and antennas and such it's indeed possible to fit in editor what would not fit in flight, because it actually got a little bigger after spawning (year, undocking would be a good term, but it's linked with docking ports too tightly). Need to see actual ships (screens, video, craft files) to tell you precisely what's going on, or if it's indeed a bug... UPD: also there are some weirdly modeled animated parts with SkinRenderers who's size is hard to estimate; the known cases are drills, but they're blacklisted already and their dimensions are measured separately. But you never know with mods what else can you encounter.
  6. Undock? Could you, please, elaborate the situation?
  7. Thanks for the report, I'll look into it. Could you provide the KSP_Data/output_log.txt for more information? *on mac/linux it's called Player.log and is located elsewhere
  8. Not with the current door animation: you see, resizing works literally by space metric distortion. When you set the size to 1 and aspect to 2 the 3D space of the part itself becomes distorted relative to the world space: each unit of length along x and z are equal to 1 unit of length in the world space; but 1 unit along the y axis becomes 2 units in world space. So... suppose you have a door in x-z plane; it is 5m along x and 3m along z; to open it, you rotate it around x... and its z dimension gradually becomes y; in the end the door is 5m-x to 6m-y. And believe me, this looks really, really awkward! *if you didn't quite catch this, just edit the ground hangar's config: GameData/Hangar/Parts/SmallHangar.cfg and see for yourself MODULE { name = AnisotropicPartResizer ... sizeOnly = true //remove this line But if the doors do not rotate across y dimension (like with radial hangar), you can change aspect. So it's possible to make a ground hangar with, say, sliding doors...
  9. Nothing much changed since then. Still, it's what you're playing with and it doesn't work. Could you maybe make a video of an incident you describe? Until the launched ship is loaded and unpacked (i.e. goes to the physical simulation mode) the hangar controls its position/rotation itself, so even if your mothership is rotating or moving, it shouldn't be a problem. The launched ship will get it's momentum and spin in the end. It does require an asteroid and the hangar hatch and the square docking port to function, yea. I'm planning to add an appropriate hangar extension though, so that the asteroid gateway could be used without asteroids.
  10. Made a twitch highlight from the latest stream, so that you could see all the interesting parts in some 13 minutes instead of 30
  11. Thanks for suggestions, I always appreciate them! Now this shouldn't actually be happening. The checks that ensure the payload fits inside are geometrically strict, no guessing here. And as you may see in the latest video on twitch (see above), the relative velocity of the launched payload (when not pushed away at launch) is zero. So if something collides with the hangar it means something is wrong with the calculations and I want to test and fix it. Do you have a .craft file or a save to test? This is what Hangar Gateways and Hangar Extensions are actually about. Not exactly, but in spirit: a gateway is a part that provides facilities for ships to go in and out of the storage behind it. It may or may not have geometrical constrains or walls; the actual constrains come from the storage, but they're not physically enforced. An extension is a part that provides storage for ships, but cannot accept and launch them itself. So by combining the two (which could be done in a single part actually, like with VTOL hangar) you can in principle have what you want. Not as virtual as you suggest: you would still need physical parts to reserve space for docked vessels; but this would solve the problem of confined hangar spaces. Two problems there: first, there's only one gateway part at the moment -- the Asteroid Hangar Gateway, which also have walls and thus constrain vessel dimensions. Second, personally, I don't like the idea of bodyless hangars. At least, I can't myself make one that satisfies me aesthetically. Hey, @everyone, who wants to model some cool hangars for the mod?
  12. No worries! I need to practice live streaming anyway. I write alright, but as soon as I start speaking at the microphone, even when recording for future editing (let alone go live), I instantly forger all the words, my own name and why I'm sitting here in the first place
  13. Going live... UPD: and done. Not that much audience, but you can watch the record for some time on twitch.
  14. And also @bcqJC I've more or less made it work with user-defined spawn orientation and wanted to show you (and everyone here), before moving forward with it, as it changes A LOT in terms of user experience with the Hangar. So, today at 20:00 UTC I'll be streaming at twitch. Tune in, watch and ask questions (better in my discord server). I'll post again before going live...
  15. I suppose it's better to repost this to SSPXr thread and/or MKS thread. Also, as far as I remember, MM doesn't support multiple HAS, NEEDS and so on. You can join them by & or , though.
  16. All TCA autopilots turn other functions on and off as they need; so if something should indeed be turned off for proper takeoff, this is a bug, not a user problem
  17. Sure, no question here; If we find that it's DLC-specific, I'll still fix it Same here
  18. Looks like you've used MH and or BG expansions in the craft, which I don't have. But if you say it's that easy to reproduce in stock, I'll just recreate the situation myself. Thanks for thoroughness!
  19. @AlexO thanks for the report. There's nothing normal about THESE messages: infinite UT should not be there. I'll investigate; but since it may be the case that I won't be able to reproduce it, I'd appreciate if you try to reproduce the situation with stock+TCA game and share the save for me to test.
  20. Oh, didn't know that. This means they're indeed fully compatible (so I'm removing the conflict def from netkan) But CC doesn't have the global @PART[*] script, only per-part patches for supported mods. So I should probably implement some kind of wildcard behavior for ModuleTankManager to be able to use one...
  21. The incompatibility notion came from the time when people tried to use both mods and ended up with the same parts (say, stock fuel tanks) having both PartModules (installed by corresponding MM patches) competing for PartResources management. Currently my patches look like this: @PART[TPtankR02]:HAS[!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch]]:NEEDS[!modularFuelTanks&!RealFuels]:AFTER[FuelTanksPlus] So they won't apply to the parts where IFS module is already present. This is fine for parts that were specifically made to use IFS; but how this will play out for parts that are patched by both IFS and CC? Don't get me wrong, I would love CC and IFS to be compatible! I just don't understand how this could be done in cases where they patch the same parts. Should we somehow predefine the order, giving priority to one over the other? It'll be fairer if a user could decide; but there's no mechanism for that... Couldn't agree more!
  22. CC as a mod is not compatible with IFS as a mod (meaning MM patches that change parts). But Global Construction (if you look closely) requires only CC-core, which is just the library with configs and does not conflict with anything. So you can use KSPIE and IFS and GC alongside, but you'll have CC functionality only in dedicated GC (and Hangar, if you'll use it too) parts. BTW, does KSPIE still require full IFS, or just the core variant? If later, KSPIE should be compatible with the full CC.
  23. Alright, but still the meaning of the whole message eludes me Why inflatables and rings (whatever they are) should not require material kits? Is it about construction them in GC? @melechdaviid?
  24. This is extremely weird! The liftoff is the simplest phase of them all. As always, I would like to have a .craft file of a rocket that does what you describe. Anyways, thanks for that observation, I'll start looking there...
×
×
  • Create New...