[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season

[SilverWolf]

Have you ever had a stubborn key that wont clear?  Take a look at the default Aerospike for a second, if you will.  I've got @key,2, 3, and 4 = DELETE, but the key 10 = ### is still there.

[Starwaster]

22 minutes ago, Verran said:

Have you ever had a stubborn key that wont clear?  Take a look at the default Aerospike for a second, if you will.  I've got @key,2, 3, and 4 = DELETE, but the key 10 = ### is still there.

Going sequentially.... key 10 becomes the 2nd key after you delete 2nd key.... not sure how MM handles that. Try reversing the order of deletion.

[Sigma88]

6 hours ago, Starwaster said:

Going sequentially.... key 10 becomes the 2nd key after you delete 2nd key.... not sure how MM handles that. Try reversing the order of deletion.

Mm will follow these 2 simple rules

1 - Each time you delete a key, the order is recalculated

2 - if you use an order too high (key,99 when the keys are less than 100) it will delete the last key instead

[Alshain]

EDIT Nevermind, I figured out my problem.

Edited August 13, 2016 by Alshain

[Fwiffo]

I'm using ModuleManager to create a bigger version of the Toroid ("donut") tank, and I have a question about drag cubes.

Originally I just used:

@rescaleFactor = 2

But now I want to create a version that scales differently along different axes; i.e. something like:

@MODEL {
    %scale = 2.2, 4.15, 2.2
}

In either of these scenarios (or using other techniques), will ModuleManager or the stock game ever automatically adjust my drag cubes?

(Responses, please quote or "@" me in the reply to ensure I get a notification)

Edited August 15, 2016 by Fwiffo

[Starwaster]

1 hour ago, Fwiffo said:

I'm using ModuleManager to create a bigger version of the Toroid ("donut") tank, and I have a question about drag cubes.

Originally I just used:

@rescaleFactor = 2

But now I want to create a version that scales differently along different axes; i.e. something like:

@MODEL {
    %scale = 2.2, 4.15, 2.2
}

In either of these scenarios (or using other techniques), will ModuleManager or the stock game ever automatically adjust my drag cubes?

(Responses, please quote or "@" me in the reply to ensure I get a notification)

Depends. If you cloned the part then yes it will create new drag cubes for it.

If you're modifying an existing part (including new parts that KSP has previously rendered cubes for) then the part database might not be updated to reflect the new change and I'm not clear on what circumstances that can happen under. Sometimes PartDatabase.cfg needs to be deleted so it can rebuilt. (declaring a part as having procedural cubes definitely seems to force an update...)

[Fwiffo]

@Starwaster Yes, I cloned the part.  But note it has a custom DRAG_CUBE defined for it.  Will MM or the game automatically scale up that custom drag cube and apply it to the cloned part when created in this manner, or does the game just blindly generate a new one?  Thanks.

[Starwaster]

29 minutes ago, Fwiffo said:

@Starwaster Yes, I cloned the part.  But note it has a custom DRAG_CUBE defined for it.  Will MM or the game automatically scale up that custom drag cube and apply it to the cloned part when created in this manner, or does the game just blindly generate a new one?  Thanks.

It uses the cube you created for it

[Fwiffo]

4 hours ago, Starwaster said:

It uses the cube you created for it

You mean, it uses the original drag cube, without attempting to modifying / scale it?

BTW do you know if the game itself scales drag cubes when using rescaleFactor?

[Starwaster]

20 minutes ago, Fwiffo said:

You mean, it uses the original drag cube, without attempting to modifying / scale it?

BTW do you know if the game itself scales drag cubes when using rescaleFactor?

No, if you defined a custom drag cube, it uses that cube as is regardless of rescaling.

Yes, rescale factor causes cubes to be rescaled (except for customd drag cubes)

[theonegalen]

Hi, I'm trying to use ModuleManager to replace an engine's atmCurve values. If I do this:

	@MODULE[ModuleEngines]
	{
		@name = ModuleEnginesFX
		@heatProduction = 50
		@PROPELLANT[IntakeAir]
			{
				%ignoreForIsp = True
			}
		@useVelCurveIsp = False
		@useAtmCurveIsp = False	
		-atmCurve
		atmCurve
			{	
				key = 0 0
				key = 0.2 0
				key = 0.45 0.5
				key = 0.525 1.025
				key = 0.9 0.9
				key = 1 1
			}

	}

The Alt+F12 database shows that instead of removing and replacing the first atmCurve, I end up with two atmCurves. What am I doing wrong?

I figured it out. You just have to put "{ }" after the -atmCurve. So much frustration because I didn't RTFM properly!

Edited August 18, 2016 by theonegalen

[falken]

Hi,

I don't suppose it's possible to make a MM patch that reduces engine ISPs across the board? I know I could manually designate each engine, but that would take... a long long time.

[Starwaster]

15 hours ago, falken said:

Hi,

I don't suppose it's possible to make a MM patch that reduces engine ISPs across the board? I know I could manually designate each engine, but that would take... a long long time.

The following code would cut all ISP values in half. Obviously you want to change that part to suit your needs. If you need something other than a static modifier then you'll need a more complex config. Otherwise, this will do it for you. You may want to make another one for ModuleRCS.

Also note that this will affect jet engines as well, so if that's not to your liking then you'll also need to figure out a way of weeding them out. Maybe by excluding all engines that have IntakeAir as a PROPELLANT (:HAS[@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir]]] )

@PART[*]:HAS[@MODULE[ModuleEngines*]]
{
	@MODULE[ModuleEngines*],*
	{
		@atmosphereCurve
		{
			@key,*[1, ] *= 0.5
		}
	}
}

 

 

Edited August 23, 2016 by Starwaster

[ErevanGaming]

Hi everybody,

Been a forum lurker for sometime now and just thought if it's possible for an MM patch to get the average resource availability on any given celestial body?

My reason being, is for the possibility of orbital mining or mining from the orbit ="> At the moment, all my mining bases at one time or another, jumps when I get near them =(

This may be sort of a cheat but I am hoping I could figure out on applying crew factors and some other elements that would equal this idea to the same as landing and building mining bases. All three kerbal types contribute to the orbital drill's efficiency =) have two or three of the same type won't add and still treated as one kerbal of that type.

 

Regards

[Starwaster]

@ErevanGaming

no. It doesn't work that way.  

MM can work on any config node that was configured in a cfg file. At that time, no planets have been initialized as that only happens when you load a saved game. MM can't access that information. 

[ErevanGaming]

hi Starwaster,

Awww =( thanks for pointing that out.

Do you think the next best option is to assign a part resource stats via MM on a per planet/moon basis to achieve what am aiming for? This is for the time being until I get to build a stable base design that won't jump and destroy itself =">

 

Regards

[Starwaster]

1 hour ago, ErevanGaming said:

hi Starwaster,

Awww =( thanks for pointing that out.

Do you think the next best option is to assign a part resource stats via MM on a per planet/moon basis to achieve what am aiming for? This is for the time being until I get to build a stable base design that won't jump and destroy itself =">

 

Regards

I'm not entirely sure what you mean?

[ErevanGaming]

hi Starwaster,

Sorry for being vague =">

Am thinking of using a stock part (ie an air intake) and have an MM cfg file that adds specific resources outputs generated by EC that reflects the average available resource of Mun (like ore and MetallicOre).

I would have that part attached to a vessel and have it orbit Mun. The vessel would have an ISRU, appropriate containers and ample EC from a reactor. The rate of output resource generation would be less than a ground-based mining base/rig.

If I can figure out how to also add productivityfactor based on types of crew present, I could include that too.

 

Regards and apologies if this is getting to be out of MM's scope/thread =">

[Kerbos]

@ErevanGaming I'm curious about your jumping bases, could be possible you post an image of one of them targeting whatever you use to support your base on the ground?

Oh... and your persistent.sfs if is not too much hassle...

Edited August 25, 2016 by Kerbos

[ErevanGaming]

Hi Kerbos,

Here's the album on imgur and here's my persistent.sfs file

 

Regards

[Kerbos]

@ErevanGaming your log must be a carnival, you got a ton of mods, 3 different versions of MiniAVC active, abandoned mods like Champagne Bottle or Vessel Mover (this last one redundant since you have Hyper Edit) and some deprecated mods like Advanced Animator.

I'm surprised your only NaN values are those expected from MJ.

I've asked you the pics because some gears can cause the bounce on low gravity places due collision meshes being too low, but I'm totally unfamiliar with those landing gears in the screen shoots.

[ErevanGaming]

3 hours ago, Kerbos said:

@ErevanGaming your log must be a carnival, you got a ton of mods, 3 different versions of MiniAVC active, abandoned mods like Champagne Bottle or Vessel Mover (this last one redundant since you have Hyper Edit) and some deprecated mods like Advanced Animator.

I'm surprised your only NaN values are those expected from MJ.

I've asked you the pics because some gears can cause the bounce on low gravity places due collision meshes being too low, but I'm totally unfamiliar with those landing gears in the screen shoots.

hi @Kerbos didn't realize I had 3 versions of MiniAVC, they other 2 might be in MODs that I have installed and wasn't aware Champagne Bottle and Vessel Mover were abandoned =( One of my stumbling blocks is giving ships/vehicles "kewl" names =D . I retain both Vessel Mover and Hyperedit for moving ships short distances with lateral/rotational control and resource editing respectively during tests and... dare I say emergencies =">

Haven't had the time to update my copy of MJ.

The landing gears I use came from B9.

On a closing note, I've picked an appropriate part from KerbonitePlus made by RoverDude called the Advance Particle Collector, added it to my custom parts to process EC into ORE which worked upon deployed. My next steps are to reduce its output comparable to a land based drill operating at 50%, then try to add some MM configuration lines for crew types. Hope I could find examples close to what am after. =) =">

[Kerbos]

@ErevanGaming I have no idea about config things, my coding skills are pretty much like a baby playing the piano, so you're on your own on that one.

But while practicing some stuffs on modeling came across the weird behavior on landing gears, which has been reported several times under several different issues (like this one), and I'm fairly sure it's Unity's fault but still trying to pinpoint a workaround. I'm gonna try to not make this a text wall:

Version 1.1 landing gears and wheels are blood relatives:

I can't really understand what is going on here because so far I can only say KSP has some really derailed physics concept when it comes to interaction between rigid bodys on what should move and what can move and turning the landing gears into some odd rover wheels (bogey module) but also implementing other awesome changes (nothing beats the bending joints). But it gets even better when you read about how Unity kindly suggest you to "simplify" every terrain mesh (AKA screw offroad) that should contact a wheel and makes you wonder if PhysX is being developed by hermits.

Unity is a jealous ex wife dating the best lawyer in town:

This is probably one of the reason why we haven't seen a crazy improvement on KSP when migrated to Unity 5 and also why several mods were destroyed and had to be recoded. Unity has bipolar disorder, discovered multithread (50 years later) and PhysX is not backward compatible. Also wheels, they use to be like planks on the ground (and felt like that too), today it's like a bunch of tennis balls inside a net.

Sandbox Derp Colliders:

Unity can handle itself like a baws when it comes to 1 collider meeting another single collider, but 10 colliders against 1 and the fun begins, now how many parts your standard ship has? 30-50 minimum? Rigid body groups are a nightmare for Unity and there's as many combinations of parts as players, KSP for the sake of performance only use primitive convex colliders but it's a juggling circus to calculate the correct behavior of a handful of colliders landing on a dynamic mesh, now once landed...

Hell is at 0,0,0. No cookies by the door:

Ever tried to land a ship on top of another ship using landing gears? Well don't do it, that's stupid, that's why we have planetary surfaces after all dummy. Seems like basically you're asking the game to calculate the mass and positioning of every collider (your gears) that touches the other collider (the roof of the big vessel) and expecting the big ship to simply add that mass and recalculate his own CoM, it can be done without noticing if the masses are ~1x10 and the little one is 100% symmetric, but the smaller ship is still under the effect of gravity and is yet to set itself as landed, so if you switch to another vessel around 20-40km distance from those 2, the dynamic mesh turns into static and the first ship's coordinates are saved to prevent them falling down to hell, and that should work, they still have a high chance of blowing up once loaded (at least the small one's gear) but the smaller one does not jump nor sink. A simple test, place 1 small engine on top of another without attaching them, save, change scene a few times or reload, you'll notice the engine sliding at first and when contacting the ground is doomed to hell, so something inside the algorithms used for that planetary mesh have "holes" and ships can sink even when not using landing gears, so unless KSP devs explicitly tell us that wheels have been fixed I'll keep on landing on girders, maybe my base clip to hell but at least won't be sitting on a set of omnidirectional wheels.

TL;DR. For some reason landing gears jump at random, don't use them on bases, also as far as I can remember B9 didn't include stationary landing gears, they look so good. Sry this turns out as a text wall anyway.

Cheers!

EDIT/// Sry @Sarbian, this is just how I see it, again I don't really understand coding, this is 70% my observations by experimenting, replicating, trying different kinds of meshes and 30% reading and trying to figure out things without full internal knowledge on how KSP handle things, but I did had a lot of help trying out things on Unity (lot of limitations there), I'll be glad to be corrected instead of dismissed. Also sry, this is totally out of MM subject, didn't actually realize.

Edited August 26, 2016 by Kerbos

[sarbian]

There is so much wrong in that post that I won't even bother wasting time to reply 

And this has nothing to do with MM

 

Edited August 26, 2016 by sarbian

[ErevanGaming]

My apologies to sarbian also ="> my subsequent posts veered off from my original question.