Jump to content

Mihara

Members
  • Posts

    1,511
  • Joined

  • Last visited

Posts posted by Mihara

  1. 8 minutes ago, linuxgurugamer said:

    Log file would be helpful

    Well, here's an excerpt. It doesn't look helpful: By the time you see any messages that look at all suspicious, the vessel has already disintegrated. (i.e. "debris" objects start getting mentioned and initialized.) The actual disintegration does not appear to correspond to any event that gets logged.

    As I mentioned above, though, I think I got it to happen reliably: It always happens when, before jump, there was another vessel (a beacon, in this case) within physics range, and seems to never happen if there was no such vessel. Let me see if this can be observed in isolation...

  2. So I'm having a strange problem with this... Namely, vessels tend to randomly disintegrate -- or rather, get krakened apart, in the original meaning of the word -- upon successful jumps. That is, the jump succeeds, and then, after the ship gets unpacked, parts start falling off, or freeze after getting shifted far off their original positions. This happens about 40% of the time.

    What's weird is that there is clearly nothing relevant in the logs after that, but Flight Event log mentions structural failures on joints.

    I have a hunch that 60 frames is too low for HoldVesselUnpack with as many mods installed as I have, (GameEvents for SOI change take time to run, don't they?) but it'll take me some time to verify that...

    Alternatively, it might be some other mod interfering with the process (BonVoyage-driven rovers also seem to occasionally bend, so it happens at least sometimes with any kind of vessel unpack) but I currently don't have any idea which one. (ReCoupler?...)

    EDIT: ...It seems to reliably happen when the jump starts when any other vessels are in physics range.

     

  3. So I've been playing KSP again, and found myself quite frustrated, when, picking a KW P-fairing for its aesthetic properties -- the frame base, to be precise, makes a very nice component for an Orion workalike -- my rocket, finely tuned with the stock fairing first, wouldn't fly the way I wanted.

    Turned out, it's because the fairing bases are way heavier than a stock fairing plus decoupler. And the 1.875 fairing base has the same mass as the 2.5m fairing base too.

    Is there any particular reason for it? Or should the masses of these parts be reconsidered?

  4. 2 hours ago, DoctorDavinci said:

    I've been asked numerous times to make them visible and usable as structural panels but only managed to get around to it yesterday

    There are some strange artifacts on the edges when I do tweakscale them: They become partially invisible, depending on the distance from camera -- at least in the editor.

  5. 2 hours ago, Streetwind said:

    ...But how? The patch that does that is tagged ":NEEDS[TacLifeSupport]". It should only trigger if your GameData folder includes a folder or DLL with that name somewhere. o_O

     

    It also says "FOR[TacLifeSupport]". For ModuleManager, this implies that the mod so tagged is present, because all patches for a given mod should be tagged so where possible.

    As a result, everything else that had its own TAC-LS patches started "detecting" it and inserting TAC resources. I got bitten by that too. :)

    The fix: Never do that. Use "AFTER[..." instead, because that's what you meant.

  6. 3 hours ago, IgorZ said:

    And that's what I call "simulate". It's not as easy as you may think. The very first question would be: where to pump the resources into? The game is good in requesting resources (there is a method which gives what you need), but it's not as good in making resources. I'm not saying it's not possible, my point is that this is a huge piece of complexity in the mod which was not designed for it.

    Not that huge, as long as you don't concern yourself with simulating flow over time or even distribution. Take a look at this method for example. Things do get a lot more complicated if you do, but still manageable. I fully understand why you wouldn't want to do it, it does go out of the original scope. But well, it would make sense. Far too few things in Kerbal universe make sense. :) 

    As it is, even when OSE Workshop recycles an item which contains resources, resources do not get reclaimed, so the only way to get them out is to go out and bolt the item to the outside of the vessel, which does not make sense at all.

    3 hours ago, IgorZ said:

    Or simply put all the tanks into a cargo bay, which would be a real life experience :)

    Part count and physics, and the fact that I can't use the nice premade replicas set up for KIS like, say, Phoenix Industries kit, is what's stopping me. Going the other way -- i.e. sending resources down from space -- is even worse than sending them up.

  7. 2 hours ago, IgorZ said:

    That said, no - there is no such a way, and there are no plans to implement it.

    Well, I know they're not actually parts, but something simple like an "fill/empty resources" button which would try to pump pumpable resources in/out of the item into any available containers on the ship shouldn't be too hard... If that didn't involve making UI, (I have an allergy to programming UI) I would just write that myself and send a pull request

    Oh well.

    P.S. There's probably also an option of creating an extra tank in the container part the moment a resource-containing part enters its inventory, and destroying it when it's taken out, but that feels like a potential nightmare of bugs, since there would be no reliable way to tell which ones got created by which contained item.

  8. If you, like me, wish to have rotation on construction ports (so that they're easy to adjust to perfection before welding) but prefer regular ports to be handled by KJR (see fix that makes them play together above) and don't care quite as much about their alignment, here's a patch for you.

    // DockRotate is very sweet, but I *only* want it on the construction ports:
    // I would rather KJR act on the docking joints.
    // So taking it off every other port.
    
    @PART:HAS[@MODULE[ModuleDockingNode],@MODULE[ModuleDockRotate],!MODULE[ModuleWeldablePort]]:FINAL
    {
    	!MODULE[ModuleDockRotate] {}
    }
    

     

  9. Something I keep meaning to ask.

    Occasionally, it makes sense to fill a large KIS container with resource tanks or smaller containers. It certainly is more convenient in some cases than rebuilding a vessel to contain tanks of multiple resources, and there are mods with large KIS storage volumes in convenient vehicles to suit this particular purpose.

    However, the problem turns up when I need to make use of these resources: To do so, I have to EVA, take the container out, attach it to the station -- whether using a container socket or surface attach -- and pump the resources out. This is only practical in some cases, since the kerbals can't really manipulate resources heavier than one ton, and using multiple kerbals to work with heavier resources in orbit is a dangerous exercise.

    So, is there a way to get at part resources while they are still inside the KIS container? If there isn't, is there a hope one could be arranged?

  10. 2 minutes ago, navot said:

    If by crash you meant make the part unclickable, then it still happens in 0.3...

    Like I said, I didn't look in the logs, so I can't tell you if there's an NRE involved or what, but yeah, that's what happens -- the part doesn't get placed and can't be removed.

  11. 2 minutes ago, navot said:

    Is this in v0.2 or 0.3 (I just put it up minutes ago...), because in 0.2 I didn't check if the part with the decoupler actually has a top node. I think (and/or hope) this isn't a problem in 0.3.

    That's in 0.2. The particular nosecone is unusual because it's meant to decouple the bottom node, but that bottom node is meant to attach to a node that is physically inside the pod itself -- but it also has a top node, and I'm not sure how is that one meant to be used...

  12. This is very promising, but screws up certain decouplers which are supposed to decouple from things rather than things attached to them, in particular, Tundra Exploration's decoupling nosecone. I think this particular part simply causes the module to crash, although I didn't look in the log, I just wrote a patch to exclude it.

    @PART[CargoShroud]:FINAL
    {
    	!MODULE[ModuleDecouplerShroud] {}
    }

    I suspect a more elaborate patch to install this module is needed, I'm sure there are other exceptions.

  13. On 8/10/2017 at 11:34 AM, TK421 said:

    Hello Nightingale,

    I had noticed one of my kerbals portraits was disappearing and had assumed it was related to Portrait Stats, however Dmagic has suggested that this mod might be causing it directly as his doesn't touch Kerbal levels. 

    I (somehow, despite only having level 0/1 kerbals) got a contract to rescue a level 5 scientist from LKO, and when I activated the science strategy granting him +2 effective levels, his portrait no longer shows up.

    I'm not really concerned about it, but just thought I'd point it out in case it is a problem of Strategia.

    Yep,  that's a problem caused by Strategia.

    Here's how I fixed it: https://github.com/jrossignol/Strategia/pull/70

  14. 1 minute ago, MaximumThrust said:

    Now I got TCA do to this, it's working well. I just drove 60 km in the Mun.

    ...I guess I'm just still burned out after having had to drive 3400 km on Tylo back in 0.25 at 4 physical warp. :)

    Current BonVoyage in CKAN already supports Feline Rovers, and works wonders precisely for getting all biomes in a single landing. Works especially well if your rover is manned and not dependent on solar power, because then BonVoyage drives at night, and at speeds you would be hard pressed to maintain manually for quite as long.

  15. 2 hours ago, KSPrynk said:

    Thanks.  I was editing my comment as you were viewing, tweaking cfg file stats and adding other hab parts.  Dividing the 288 by 10 for 28.8 extra hab-months actually makes even more sense when compared to the other inflatables and MKS parts.  Either way, a little re-balancing to keep the USI parts competitive would be welcome.

    MKS hab ring offers 497.5 extra hab-months for just 5.1888 tons dry mass, though. I understand the scale probably shouldn't be linear, but what should it be, and why?

  16. 7 hours ago, JadeOfMaar said:

    I'm working on fixes now. What do I do with this, though? Its purpose is not clearly defined and it's in Utilities, though it is a Command part. Should it serve as a tanker for LS resources if used with LS?

    It's a bus. That is, the IVA is set up in two levels horizontally, and while it's fairly versatile, it doesn't look like a place meant to be used for long. A rover or a purely orbital station-to-station transfer vehicle. So it probably should have supplies, but the amount should match the available habitation levels.

    I tried tracking down the original NASA concept art that this was inspired by to find out what it was supposed to be, and while I know it exists, I haven't found the source.

  17. So I recompiled this for 1.3 and it works fine. Lovely plugin, though I would prefer to be able to set the abort conditions in the editor, which doesn't seem to work.

    Any particular reason this hasn't seen an update release?

    P.S. Oh, and the best way to use it in my opinion:

    // Install automatic escape controller into escape tower parts.
    // Other abort modes can live with the controller part.
    
    @PART[LaunchEscapeSystem,SDHI_LES,SmallEscapeTowerHGR,HeavyLES]
    {
    	MODULE
    	{
    		name = ModuleAAS
    	}
    }
    

     

  18. Woot, it's the new one! :) I was expecting to see the old one, not sure why. Does the IVA render at all? I see it's commented out, but the file is there.

    My take on the USI-LS config for the new centrifuge. Since there are no sensible balancing guidelines for that, I just took the numbers of the larger inflatable centrifuge from MKS and assumed the habitation bonus conferred as well as the electric charge consumed are proportional to mass, so take it with a grain of salt.

    @PART[centrifugeSmall]:NEEDS[USILifeSupport]
    {
    	MODULE
    	{
    		name = ModuleLifeSupport
    	}
    	MODULE
    	{
    		name = USI_ModuleFieldRepair
    	}
    
    	MODULE
    	{
    		name = ModuleHabitation
    		BaseKerbalMonths = 288
    		CrewCapacity = 0
    		BaseHabMultiplier = 0
    		ConverterName = Habitat
    		StartActionName = Start Habitat
    		StopActionName = Stop Habitat
    		INPUT_RESOURCE
    		{
    			ResourceName = ElectricCharge
    			Ratio = 7.2
    		}
    	}
    }

     

  19. Got a bug report.

    There are now two sets of lifesupport patches in the distribution -- one in "lifesupport" and one in "patches". Both get applied, resulting in multiple copies of life support modules. I am pretty sure this confuses USI-LS at least, (two identical right click menu items collide, it starts lying about the remaining hab time) not sure about the others.

    Previously, life support configuration was part of the part config itself, so that's definitely new. :)

    Also, shouldn't TIorbitalorb have a hab module too?

×
×
  • Create New...