[1.11.x] AmpYear Main & Reserve Power Manager (v1.5.9.0) 22nd Feb 2021

[panarchist]

37 minutes ago, JPLRepo said:

Read back 3 or 4 pages would be my advice.
 

Ah - thanks, I should have went back one more page.  Stock bug, that's unfortunate.  Love you mods, BTW - this one is great, but I'm taking a bit of a frame rate hit - though it's way better than previously.  Never helps when the persistence file is hundreds of thousands of lines, or when one has 50 mods installed.  Neither of which is your problem.  Appreciate the pointer and quick response - keep up the great work!

[JPLRepo]

5 hours ago, Deimos Rast said:

@Gordon Dry That's just seems to be a NFE fission reactor.

From the OP below. It actually seems like it might be a bug, since if there isn't supposed to be ESP support, getting shutdown by ESP is probably not working as intended. Also something to consider is the thermal efficiency of the reactor, which might play a role. Lastly, most of Nertea's reactors aren't called "WIP - Need Input" so maybe RO reworked it (although I have/recognize all the modules on it). In the future, you could try something like HyperEdit to just move the ElectricCharge resource to full (it's a great tool).

 

 

@Gordon Dry Well I am not really following what the issue is here. As @Deimos Rast said it would appear RO or something is changing your NFE reactor.
I went through your log and couldn't find anything evil with regard to AmpYear. But I did see lots of Remote Tech log spamming.
All I can really do is test the NFE reactors with AmpYear ESP processing again to make sure this is no bug. ESP does not support the NFE reactors, so it should not be changing them at all. So I will check that. But given I see nothing else in your log AmpYear related not much else I can do.

[JPLRepo]

8 hours ago, panarchist said:

Ah - thanks, I should have went back one more page.  Stock bug, that's unfortunate.  Love you mods, BTW - this one is great, but I'm taking a bit of a frame rate hit - though it's way better than previously.  Never helps when the persistence file is hundreds of thousands of lines, or when one has 50 mods installed.  Neither of which is your problem.  Appreciate the pointer and quick response - keep up the great work!

I have worked out the cause of the bug and a work-around. If you really want to remove AY from your install. Just LEAVE the \GameData\REPOSoftTech\AmpYear\Resources\AmpYearResources.cfg file and remove everything else from the AmpYear folder. This will stop the crashing in the Tracking Station until you recover all vessels that were launched with AmpYear installed. The cause is a stock bug, but by leaving this file, it won't occur. A fix for the stock bug though won't be available probably under 1.2 now given 1.1.3 has entered code lockdown this week (as per the DevNotes).

[panarchist]

1 minute ago, JPLRepo said:

I have worked out the cause of the bug and a work-around. If you really want to remove AY from your install. Just LEAVE the \GameData\REPOSoftTech\AmpYear\Resources\AmpYearResources.cfg file and remove everything else from the AmpYear folder. This will stop the crashing in the Tracking Station until you recover all vessels that were launched with AmpYear installed. The cause is a stock bug, but by leaving this file, it won't occur. A fix for the stock bug though won't be available probably under 1.2 now given 1.1.3 has entered code lockdown this week (as per the DevNotes).

Thanks!  I want to remove it from this install (I have two I use), but only because I have too many processor-heavy mods installed on this game.  I'll continue using it on the other install I have (the two saves have mutually incompatible mods) - I really enjoy the mod.

I'm still using DeepFreeze and JSI-ATP on the save.  Haven't tried TST yet, keep meaning to.  Anyway, thanks again!

[JPLRepo]

1 minute ago, panarchist said:

Thanks!  I want to remove it from this install (I have two I use), but only because I have too many processor-heavy mods installed on this game.  I'll continue using it on the other install I have (the two saves have mutually incompatible mods) - I really enjoy the mod.

I'm still using DeepFreeze and JSI-ATP on the save.  Haven't tried TST yet, keep meaning to.  Anyway, thanks again!

NP. Sounds like I need to do another efficiency round on the code again.

[panarchist]

1 minute ago, JPLRepo said:

NP. Sounds like I need to do another efficiency round on the code again.

It's vastly improved.  Like you stated upthread, there's only so much you can do with a mod that does part scanning.  I use USI-LS, RemoteTech, and a number of other mods with background-processing dlls.  I also had to pull Distant Object Enhancement and E.V.E., both of which are way worse on framerate than the prior version of AmpYear.  Don't consider my results typical, please.

[JPLRepo]

Just now, panarchist said:

It's vastly improved.  Like you stated upthread, there's only so much you can do with a mod that does part scanning.  I use USI-LS, RemoteTech, and a number of other mods with background-processing dlls.  I also had to pull Distant Object Enhancement and E.V.E., both of which are way worse on framerate than the prior version of AmpYear.  Don't consider my results typical, please.

I know it can be improved more... but I also know Squad have plans to change/improve resource/part processing... I think that's all going to be in 1.3 though.

[Errol]

I have found an incompatibility for this mod, submitting this as a bug report. There are no crash logs to post.

Tested on a clean install of KSP 1.1.2 x64

(Semi-)Saturatable Reaction Wheels - Download/Source Is the specific mod that is causing a conflict.

Bug: Having both mods installed stops reaction wheel saturation from modifying effective torque. (RW window still show diminished torque available, but you can still freely use all reaction wheels if there is electricity for them)

Each mod functions beautifully on their own.

Repro steps; build a simple probe with electric charge and reaction wheels, use girders as skid pads, and use rotation to start the vessel spinning. If RW saturable is working after a short time your probe should stop spinning due to diminished torque available and the friction of the surface. 

Cross posting to plugin workshop.

[ultraviolet150]

@JPLRepo

Is it somehow possible for Remotetech to use the stored ReservePower? Currently, If the power runs out, Remotetech shuts down and cant be re-enabled, nor can you transfer reserve power into the batteries to be able to start it back up. It would be nice if there was a feature which had the reserve power keep the remotetech antennas alive. 

[JPLRepo]

2 minutes ago, ultraviolet150 said:

@JPLRepo

Is it somehow possible for Remotetech to use the stored ReservePower? Currently, If the power runs out, Remotetech shuts down and cant be re-enabled, nor can you transfer reserve power into the batteries to be able to start it back up. It would be nice if there was a feature which had the reserve power keep the remotetech antennas alive. 

You're asking on the wrong thread. That would be a request on Remote Tech.

[ultraviolet150]

1 minute ago, JPLRepo said:

You're asking on the wrong thread. That would be a request on Remote Tech.

Fair enough

[JPLRepo]

Just now, ultraviolet150 said:

Fair enough

They will say no probably...

What I need to do is get ReservePower added into the community resource pack first I would imagine.

[ultraviolet150]

2 minutes ago, JPLRepo said:

They will say no probably...

What I need to do is get ReservePower added into the community resource pack first I would imagine.

I honestly know nothing about modding, I just had the thought after one of my sats went dead, but had a full storage of reserve power, yet i couldnt do anything with it.... Quite frustrating. Now I have a dead sat with its reserve power slowly running out... floating away in space. Figured I'd just ask

[JPLRepo]

1 minute ago, ultraviolet150 said:

I honestly know nothing about modding, I just had the thought after one of my sats went dead, but had a full storage of reserve power, yet i couldnt do anything with it.... Quite frustrating. Now I have a dead sat with its reserve power slowly running out... floating away in space. Figured I'd just ask

I'll put it on the list... What i was saying is I should get "ReservePower" added to the community (mods) resource pack. Rather than just defining it in AmpYear alone.
That way RemoteTech can use it regardless of whether you have AmpYear installed or not.. and not crash if you don't have AmpYear installed... if that makes sense.

[ultraviolet150]

1 minute ago, JPLRepo said:

I'll put it on the list... What i was saying is I should get "ReservePower" added to the community (mods) resource pack. Rather than just defining it in AmpYear alone.
That way RemoteTech can use it regardless of whether you have AmpYear installed or not.. and not crash if you don't have AmpYear installed... if that makes sense.

Ah, okay, I see what you mean! Would really appreciate a look into it. And thanks for the speedy replies <3

[Deimos Rast]

Minor minor bug report: When you disable RemoteTech in game via its respective KSC settings options, AmpYear interprets this as a "No Connection" type scenario and goes into lockout mode. This is on the 1.1.2 version of both, and I'll be upgrading in a moment, so it will no longer be apply to my game, but I figured it would still be relevant (having read the changelog).

Glad to see you go your mods up to date so quickly.

Cheers.

[Sandriell]

Just an FYI: The version number is wrong on Spacedock.

[JPLRepo]

2 hours ago, Sandriell said:

Just an FYI: The version number is wrong on Spacedock.

Yeah thanks. Late at night and I made a mistake. Unfortunately spacedock does not let you change it.

[Deimos Rast]

Seeing this alot with the latest version of both AmpYear and USILS.

Cheers.

 

160624T194239.453 [INFO] [AY.USILSWrapper.LogFormatted] 6/24/2016 7:42:39 PM,AmpYear-USILSWrapper,Invoke LifeSupportRecipe Method failed: Object reference not set to an instance of an object

160624T194239.453 [INFO] [RSTUtils.Utilities.Log] 6/24/2016 7:42:39 PM,AmpYear,Wrong USI LS version - disabled.

 

[JPLRepo]

On 25/06/2016 at 11:12 AM, Deimos Rast said:

Seeing this alot with the latest version of both AmpYear and USILS.

Cheers.

 

160624T194239.453 [INFO] [AY.USILSWrapper.LogFormatted] 6/24/2016 7:42:39 PM,AmpYear-USILSWrapper,Invoke LifeSupportRecipe Method failed: Object reference not set to an instance of an object

160624T194239.453 [INFO] [RSTUtils.Utilities.Log] 6/24/2016 7:42:39 PM,AmpYear,Wrong USI LS version - disabled.

 

https://github.com/JPLRepo/AmpYear/issues/32

[JPLRepo]

V1.3.4 Released fixes integration with USI-LS as well as cater for new status in KSP 1.1.3 ith regard to any parts Using ModuleResourceConverter (showing as 0 EC usage even when active in AmpYearV1.3.3).

[Deimos Rast]

so I found a bug, maybe sort of. I'm going over some older mods, and I threw a batch of them in my GameData folder without looking them over and surprisingly the game loaded. Anyway, one of the parts made AmpYear cranky as hell; the "errors" occurred at the info level, not not a full blown exception I guess, but it's a non-stop log spam storm till I kill the part.

Looking over the config (it's a propeller engine), it uses some possibly outdated Firespitter modules, the deprecated velocity curve, and has a stray empty MODULE floating around, which is what I think is causing the real issue. I'm not expecting compatibility, I'm just mentioning it since it seems to expose a niche case scenario in AmpYear's error catching routine, or something (my interpretation), that might be of interest. Or not.

Cheers.
 

160702T230400.998 [INFO] [RSTUtils.Utilities.Log] 7/2/2016 11:04:00 PM,AmpYear,Failure in Part Processing
160702T230400.998 [INFO] [RSTUtils.Utilities.Log] 7/2/2016 11:04:00 PM,AmpYear,Exception: System.NullReferenceException: Object reference not set to an instance of an object
  at AY.AYController.ProcessModuleEngines (System.String prtName, .Part currentPart, .PartModule module, Double altRate) [0x00000] in <filename unknown>:0 
  at AY.AYController.ProcessStockPartModule (.Part currentPart, .PartModule module, Boolean inhasAlternator, Boolean incurrentEngActive, Double inaltRate, System.Boolean& hasAlternator, System.Boolean& currentEngActive, System.Double& altRate) [0x00000] in <filename unknown>:0 
  at AY.AYController.FixedUpdate () [0x00000] in <filename unknown>:0 
160702T230400.998 [INFO] [RSTUtils.Utilities.Log] 7/2/2016 11:04:00 PM,AmpYear,Failure in Part Processing
160702T230400.998 [INFO] [RSTUtils.Utilities.Log] 7/2/2016 11:04:00 PM,AmpYear,Exception: System.NullReferenceException: Object reference not set to an instance of an object
  at AY.AYController.ProcessModuleEngines (System.String prtName, .Part currentPart, .PartModule module, Double altRate) [0x00000] in <filename unknown>:0 
  at AY.AYController.ProcessStockPartModule (.Part currentPart, .PartModule module, Boolean inhasAlternator, Boolean incurrentEngActive, Double inaltRate, System.Boolean& hasAlternator, System.Boolean& currentEngActive, System.Double& altRate) [0x00000] in <filename unknown>:0 
  at AY.AYController.FixedUpdate () [0x00000] in <filename unknown>:0 

 

The dirty config (pruned):

Spoiler

MODULE


MODULE
{
	name = ModuleEngines
	thrustVectorTransformName = thrustTransform
	exhaustDamage = False
	ignitionThreshold = 0.1
	minThrust = 0
	maxThrust = 5
	heatProduction = 300
	useEngineResponseTime = True
	engineAccelerationSpeed = 20
	engineDecelerationSpeed = 20
	useVelocityCurve = True
	PROPELLANT
	{
		name = ElectricCharge
		ratio = 0.1
		DrawGauge = True
	}
	
	PROPELLANT
	{
		name = FSCoolant
		ratio = 0.005
		DrawGuage = False
	}
	
    atmosphereCurve
    {
		key = 0 3500
		key = 1 3500
    }
    velocityCurve
    {
        key = 500 0 0 0
        key = 425 0.2 0 0
        key = 0 1 0 0
    }
	
}

MODULE
{
	name = FSpropellerAtmosphericNerf
	thrustModifier = 1.2
}

MODULE
{
  name = ModuleResourceIntake
  resourceName = FSCoolant
  checkForOxygen = false
  area = 1
  intakeSpeed = 50
  intakeTransformName = thrustTransform //Intake  
}

RESOURCE
{
    name = FSCoolant
    amount = 5.0
    maxAmount = 5.0
}

MODULE
{
  name = ModuleResourceIntake
  resourceName = IntakeAir
 checkForOxygen = false
  area = 0.03
  intakeSpeed = 50
  intakeTransformName = thrustTransform //Intake  
}

//---- blade rotation

//MODULE
//
//    name = FXModuleAnimateThrottle
//      animationName = throttle
//      dependOnEngineState = False
//      responseSpeed = 0.5
//}

MODULE
{
	name = FSplanePropellerSpinner
	propellerName = Spinner	
	rotationSpeed = -500
	windmillRPM = 0.1
	spinUpTime = 100
	useRotorDiscSwap = 1
	rotorDiscFadeInStart = 0.5
	rotorDiscFadeInEnd = 0.5
	rotorDiscSpeed = 30
	rotorDiscName = Disk
	blade1 = Blade
	blade2 = Blade2
	blade3 = Blade3
	
}

MODULE
{
	name = FSswitchEngineThrustTransform
	defaultTTName = thrustTransform
	alternateTTName = alternateThrustTransform
	useNamedAlternate = 0
}

MODULE
{
	name = FSengineHandCrank
}

 

 

[JPLRepo]

4 hours ago, Deimos Rast said:

so I found a bug, maybe sort of. I'm going over some older mods, and I threw a batch of them in my GameData folder without looking them over and surprisingly the game loaded. Anyway, one of the parts made AmpYear cranky as hell; the "errors" occurred at the info level, not not a full blown exception I guess, but it's a non-stop log spam storm till I kill the part.

Looking over the config (it's a propeller engine), it uses some possibly outdated Firespitter modules, the deprecated velocity curve, and has a stray empty MODULE floating around, which is what I think is causing the real issue. I'm not expecting compatibility, I'm just mentioning it since it seems to expose a niche case scenario in AmpYear's error catching routine, or something (my interpretation), that might be of interest. Or not.

Cheers.
 

<snip>

The dirty config (pruned):

<snip>

Could be the empty node, actually, without the curly brackets, surprised the part even loads.
But the error appears to be with the ModuleEngines, yes that config looks very old. It's missing a number of fields.
It's actually failing in AY.AYController.ProcessModuleEngines will a null reference (something isn't defined). I'd say something isn't supplied in the config file... but it's seriously messed up with that empty node. Does it still occur without the empty node? I'll look at tightening up the error processing. Thanks.

[Deimos Rast]

Not sure, I put it aside (haven't been at my main computer much lately).

On another issue, I was looking at the AmpYear MM patch and I think I might have some suggestions on "improving" it. Actually, it'll be easier to just show you how I rewrote it. I never agreed with the "if it ain't broke" mentality.

• Does the RealismOverHaul part of the patch work? It seems like it needs to have the "@" removed otherwise it might over write a random resource.
• Why 80?
• Does the CrewPart have any usage for non-commanded parts (Hiker's Crew Storage for example)?
• You could probably use FOR instead of NEEDS, for no real advantage that I can think of off hand, but you could.
• The important part is that it checks to see if a part already has reserve power....since I might know of a...friend...who has been adding reserve power to all his customized parts (and it's not a measly little 80).
• If the Mechjeb cleaner part doesn't work as is, could change it to :FOR[zzz_AmpYear] or something, since people get mad at the usage of FINAL.

Just food for thought.

@PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[AmpYear]
{
	MODULE
	{
		name = AYCrewPart
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[ReservePower]]:NEEDS[AmpYear&!RealismOverhaul]
{
  RESOURCE
	{
		name = ReservePower
		amount = 80
		maxAmount = 80
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[ReservePower]]:NEEDS[AmpYear&RealismOverhaul]
{
  RESOURCE
	{
    name = ReservePower
		amount = 1000
		maxAmount = 1000
	}
}

@PART[*]:NEEDS[AmpYear]
{
	MODULE
	{
		name = AYPart
	}
}

@PART[MechJebAR202|MechJebPod]:FOR[AmpYear]:AFTER[AmpYear]
{
  !MODULE[AYCrewPart]{}
  !RESOURCE[ReservePower]{}
}

 

[JPLRepo]

3 minutes ago, Deimos Rast said:

Not sure, I put it aside (haven't been at my main computer much lately).

On another issue, I was looking at the AmpYear MM patch and I think I might have some suggestions on "improving" it. Actually, it'll be easier to just show you how I rewrote it. I never agreed with the "if it ain't broke" mentality.

• Does the RealismOverHaul part of the patch work? It seems like it needs to have the "@" removed otherwise it might over write a random resource.
• Why 80?
• Does the CrewPart have any usage for non-commanded parts (Hiker's Crew Storage for example)?
• You could probably use FOR instead of NEEDS, for no real advantage that I can think of off hand, but you could.
• The important part is that it checks to see if a part already has reserve power....since I might know of a...friend...who has been adding reserve power to all his customized parts (and it's not a measly little 80).
• If the Mechjeb cleaner part doesn't work as is, could change it to :FOR[zzz_AmpYear] or something, since people get mad at the usage of FINAL.

Just food for thought.

 

• Try it out. Haven't for a while, as RO just got updated a couple of days ago for 1.1.3 and I have been busy with all the 1.1 patches for about 2 months I've barely played any KSP myself.
• Because I like 80.
• The CrewPart should ONLY be attached to parts with ModuleCommand.
• Probably.
• Sure - and probably it will break all very soon as I am working on a conversion to use the CRP resource instead of the AmpYear ReservePower. - but more on that later.
• Don't undertand this point. Far as I know it works fine.