Jump to content

DaniDE

Members
  • Posts

    189
  • Joined

  • Last visited

Posts posted by DaniDE

  1. 1 hour ago, TomTheTragedy said:

    I actually deleted it and believe it or not EL is still trying to use material kits to try and build a craft ;-; im just going to delete MKS for now until this problem is fixed i think, thank you for all of the guidance help and support though.

    Make sure you really deleted the correct thing, then go to the gamedata directory and remove all modulemanager cache files (everything starting with modulemanager *except* the ModuleManager.2.7.2.dll itself). Restart the game, and check in sandbox mode what is required to build rockets from an EL workshop.

  2. @Padishar thank you for this wonderful mod. I have one simple question, do you have to apply the padding manually everytime you restart the game? I have noticed padding = false is set by default, and I am not sure if that is safe to turn on and if you still should manually invoke it by alt-end after a while even if that is set to true. (I am just assuming here that this setting does the auto-applying :-).

     

    Thanks :)

  3. I use this patch to do sort the smart parts into control, because I am to lazy to change all the configs again on updates:

    @PART[km_smart_alt_low,kb-fuel-breaker1,kb-fuel-breaker3,kb-fuel-breaker15,kb-fuel-breaker2,FuelController,km_smart_fuel,km_prox_sensor,km_valve2,km_valve,km_smart_time,km_smart_speed,km_smart_radio]:AFTER[SmartParts]
    {
    @category = Control
    }

    Maybe it saves one of you some time :-)

  4. My 2 cents on the whole compatability thing: If you dont want compatability problems, you need to manually take care of it yourself. Mod Authors cannot foresee the combination of mods a user has. Its not as easy as using some mod manager software, but its also not so complicated you could not do it yourself.

    As for compatability, you need to be in control of what modules get applied to which parts. I delete the inclusion patches that come shipped with tweakscale and only apply tweakscale to certain parts like structural stock parts and Infernal Robotics with my own tweakscale MM patch. Sometimes Mods come with tweakscale configs included and you might want to check if you really like to keep those or not.

    I got rid of interstellar fuel switch which is way too invasive in its implementation - for some reason, the author decided it would be a good idea to apply it to @PART[*] instead of defining the parts that would receive it. I personally had IFS back then for Fuel Tanks Plus, which recently dropped IFS as a dependency and lets you use Firespitter instead, which does NOT include itself to all parts and is therefore a recommended alternative for all texture switching parts. (Nertea uses B9PartSwitcher for Near Future Tech, which also is not as invasive as IFS and should also not give you trouble controlling it).

    What I mean is - decide yourself what parts tweakscale and other Part changing mods apply its module to and check if you really need Interstellar Fuel Switch - If you do, you can basically not *prevent* it from getting applied to all qualified parts, instead you can only try to make a custom mm patch that should *remove* the applied IFS module from a tank/engine that you dont want or need it on by something like this (no guarantees, I bascially wrote that out of my memory, not tested :):

    @PART[FuelTank]:BEFORE[KRnD]:AFTER[InterstellarFuelSwitch]:NEEDS[InterstellarFuelSwitch,KRnD]
    {
        !MODULE[InterstellarFuelSwitch]{}
    }

    (What this does is telling Module Manager to remove the module [InterstellarFuelSwitch] from the part [FuelTank] before KRND is run, because it needs to do it beforehand so KRND has not already blacklisted the part, and after IFS so the IFS module applying has already happened. Otherwise IFS would be removed but KRND might not get applied anyway. Only run this Patch when both mods are actually installed.)

     

    If you have done the work once, you can place all your custom module manager configs in a separate folder that you can back up for reinstalls, so you dont have to do the same work twice. In the end, you should only have parts that have a part changing module on it, that you decided on beforehand. And if you ever see a part ingame that has two conflicting modules on it, you can patch it with a variant of the above example patch.

    Remember to delete the Module Manager cache files in your /gamedata/ folder (ModuleManager.ConfigCache, ModuleManager.ConfigSHA, ModuleManager.Physics, ModuleManager.TechTree) when you made changes, also delete "PartDatabase.cfg" in the Kerbal Space Program folder when you changed your partlist (at least when you delete a part or a mod with parts).

  5.  

    Would using the arithmetic function of modulemanager:

    				PartStats
    				{
    					mass *= 0.99
    				}

    not prevent any negative mass problems? This example would reduce mass by 1%, not a plain number.

    Thanks,

    Dani

     

    PS: The quoting and code box function of this forum software is a crime against usability.

    2 hours ago, -MM- said:

     For testing I used a new, custom tech tree node which makes all parts 1t lighter (just place this snippet into a new cfg file in your KSP-installation):

    
    @TechTree
    {
    	RDNode
    	{
    		id = massUpgrade
    		title = Mass Upgrade
    		description = Just for testing.
    		cost = 100
    		hideEmpty = False
    		nodeName = rnd_massUpgrade
    		anyToUnlock = True
    		pos = -1309,1809,-1
    		scale = 0.6
    	}
    }
    
    @PART[*]
    {
    	MODULE
    	{
    		name = PartStatsUpgradeModule
    		showUpgradesInModuleInfo = true
    		UPGRADES
    		{
    			UPGRADE 
    			{
    				name__ = Mass Upgrade
    				techRequired__ = massUpgrade
    				IsAdditiveUpgrade__ = True	
    				PartStats
    				{
    					mass = -1
    				}
    			}
    		}
    	}
    }

    One could now simply build like 10 of these nodes, each called "Mass Upgrade -10%", but it has some drawbacks:

    • The description of the parts is not updated, even after applying the upgrade with -1 mass to a part which weighs 1.25t, it will still be listed as 1.25t, only with the additional remark "** Upgrades Available **"
    • With this you could obviously create parts with negative mass. So unless you want to start your very own Kerbal Ballooning Program, we would have to generate the upgrades for these nodes programmatically for each part (unless Squad introduces a relative modifier in the future).

    While the second point can be solved with a clever mod, the first one seems pretty inconvenient. But maybe some of you guys with incompatible third party mods can do some tests with this to find out whether a system like this would solve your problems?

     

  6. 15 hours ago, Terwin said:

    I have not looked into it personally, but from what I have read about others discussing this, upgrades are read from tech nodes in order(of research cost?) and only the latest modification to a given parameter on a given part will be used.  I think it is implemented in a 'once this node is researched, set these parameters on these parts to these new values' so there is not really any way to stack the modifications, as it is simply assigning a new value(and some of those values could even be worse in some ways than the previous values, if so designed)

    Before there goes more hearsay into this, I would like to point you to a source. The default behavior of PartStatsUpgradeModule seems to be replace, there is an additive update function in there too though. Quote:

    " the "IsAdditiveUpgrade__" field. This field tells the PartModule Load to add the UPGRADE nodes additive. If it is false the nodes will overwrite each other this is only applicable to the PartStatsUpgradeModule. "

    Another Quote that is important: " The PartUpgradeManager ScenarioModule handles the Upgrading. Mods can Interface to this to modify the stock upgrade behaviour and extend"

    You can check this out for more info:

     

  7. @-MM-

    Regarding compatibility, I always wondered if it would be possible to have a common layer for modifications so all the mods that modify parts at runtime would send their changes to that layer, and then the combined changes would be passed on to the runtime. Like a modular (as in, does not need all mods to function, but could work with all the part mods at once) API that sits between the part modifying mods and the game. Maybe storing everything in RAM even, now that we have x64 across the platforms that matter.

    In any case, thank you for keeping this essential mod updated :)

  8. Hello :)

    I have installed this mod for quite a while now, because I think it looks absolutely great - however I only really tried to use it until now - and after countless attempts I just cannot figure out how to "fill" the large truss structures with something. There seems to be no attachment nodes inside that one could use, and there also seems to be no "end piece" that offers attachment points for the inside so you, for example, could build 2.5m stacks inside the trusses. Of course I might be overlooking a part (I really have too much stuff :).

    Any hints for this would be greatly appreciated. Thanks :D

     

    Maybe if you could make a structural end / or even also separator that has two sides and could go between two T404 trusses, that has some inline attachment points like this - I managed to simulate it a bit with a spacey thrust plate - of course its not spaced out properly inside the truss:

     

    U9jeYcZ.jpg

    JBaG7dh.jpg

     

    HffY6Et.jpg

     

    vgqjFC9.jpg

     

  9. Since 1.1.1 introduced some part related changes I suggest you delete the part database cfg in the KSP main directory as well as all the module manager generated cache files in the gamedata subdirectory. That might help, I do this anytime I change or update a mod or a KSP update happens since they can become corrupted or are not updated correctly under certain circumstances and since they get auto-generated upon gamestart it's a no brainer to be safe on that side of things.

    5 hours ago, CobaltWolf said:

    EDIT: It is also REALLY hard to test stuff when I crash every 2-3 minutes in game... after one such crash, I loaded back in to find this:

     

     

    On a sidenote, I believe with unity 5 the colliders changed, maybe check with the KIS/KAS folks what they needed to change to get the ground pylons attachable in 1.1. ?  (Since capsule hatches now need a box collider, maybe its the same thing here?)

    Thanks for maintaining this essential mod :)

  10. On 19.4.2016 at 7:12 PM, Eleusis La Arwall said:

     

     

    Woops, somehow I thought sockel was an english word too but as it turns out it is not. Will change that in the future. Suggestions?

    "socket" or "base" or even "foundation" (fundament) should all work

     

    About that latin thing, its been like 20 years since school, but maybe this is a bit of inspiration - :

    Money - over/through - (kerbal-)rights -> pecunia per (or super) civitas

    Money over folk/populace -> pecunia per populus

    Kerbalized versions might be "pecunia per kerbulus / kivitas" or something like that. Just don't use "Kopulus" or it might get weird quickly.

    If you want literally "before" in the sense of time you can use "ante" instead of "per" but it does not make sense in this particular case imho.

     

    Thanks, hope to be able to use your great mod it in the current game version soonish :)

×
×
  • Create New...