Author Topic: BC 1.1 - Secondary shield generators  (Read 4778 times)

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #80 on: September 24, 2011, 04:50:08 PM »
I respect your knowledge and position within the BC modding scene so I don't mean to come across as rude or unappreciative when I say:

The script already appears to work for the QB Scimitar AI (in my version of BC at least). I mean I am in QB and the enemy AI Scimitar's Primary/Secondary shields are working so telling me that the use of a dictionary over a list is good because it allows the script to work with AI isn't self-explanatory.

Of course I will now use the dictionary data type now that I know you meant "working with AI" in the context of the script being able to store multiple shield values of not just the two shield generators of a single ship but the shield values for multiple ships.

Anticipating the scripts completion I thank you (USS Sovereign) and Defiant for all of the time you have spent with me on this. I also thank anyone else who chipped in to guide this newbie through the perils of the Python trail in BC.


EDIT:
No doubt anyone with more experience could have done this script much better than me in a fraction of the time but what the hell. It's been an experience and I guess everyone has to start somewhere. In retrospect I didn't really do much by myself, the script was generously given to me by  :angel Defiant :angel then he and  :angel USS Sovereign :angel told me how to do just about everything. It's not a complaint, just an acknowledgement.

I will reply back when the script is done.
Great men are not peacemakers! Great men are conquerors!

Offline JimmyB76

  • Posts: 6423
  • Cookies: 421
Re: BC 1.1 - Secondary shield generators
« Reply #81 on: September 24, 2011, 05:36:15 PM »
every excellent scripter started off one day from being brand new...  it is all about patience, and diligence and the desire to know more, and youll find yourself getting better and better!
shame you werent around the bc scene a few years ago when Sov was teaching new scripters alot about BC scripting...  over at BCS forums, there was about a dozen people he taught in many lessons from the very basic to more and more complex, there was a forum called Scripter Training Corps - youd have excelled im sure!   the forum is still there, just archived... 

just keep at it, what youre doing, and keep asking questions, and youll learn so much in the process and perhaps it could be the beginning of something youll enjoy doing and then wind up make alot of cool scripts for the BC community :)

personally, when youve finished this script im hoping youll release it for everyone to enjoy :)

Offline Mario

  • Senior Software Developer
  • Administrator
  • Posts: 2186
  • Cookies: 1706
  • Life is life
Re: BC 1.1 - Secondary shield generators
« Reply #82 on: September 24, 2011, 05:37:39 PM »
It is self-explanatory, you just don't see or understand the connection. The usage of lists as storage is pretty much used when you plan to develop a tech which is exclusive for the player ship or limited to 1 ship instance. Usage of a dictionary means that you plan to develop a tech which can be used by the AI. It is blindingly obvious that you cannot use a list to fetch and store data for multiple ships.

You might want to also check if the shields are actually on. There are times from players perspective when the shields will not be turned on and you might not want to trigger your code.
 
Code: [Select]
pShields.IsOn()
Acta, non verba.
aka USS Sovereign

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #83 on: October 01, 2011, 12:24:52 PM »
I have to start off with an apology, I said i'd reply back when the script is finished and now I am replying back with an unfinished script. :doh:
I also have to apologise for how long I have been abscent since my last post. I have been trying to put in as much work on the script as I can but my full-time education has priority.

And I can't forget the MOTM nomination from USS Sovereign. :eek No emoticon available can express the surprise that hit me when I got the PM from JimmyB76. All I can say is it's very flattering but I don't consider myself ellegable given: the script was generously given to me by Defiant and I have done very little of the work by myself.

------------------------------------------------------------
Now moving onto the script.
(The script and a ConsoleTrackerDump.txt are attached)

I have made, what I consider to be, some big leaps since my last post and now. I have put down the all-important conditional statements logic that determines what shield generator is currently active and what shield generator is going to take over (if any), or turn off the shields altogether.
I have also worked out the FOR loop that goes through the players shields and stores and/or applies the new shield values (if necessary) when generators become operational/disabled.

To be straight to the point and try not draw out the post to an essay (a habit of mine) I will hand out the reasons and problems for why the script is ready for use.
WARNING: The script is quite messy since I threw in print statements all over the place to find out what's going on. I've also constructed quite a tree of IF ELSE IF ... statements, although hopefully the comments will keep you on track.

PROBLEMS WITH THE SCRIPT:

1) Innaccurate shield values being assigned due to incorrect ShieldPercentage value.
When a generator goes offline I store the values of all it's shields so they can be loaded and applied when (IF) that generator comes back online. In order to do this however I have to store the current values and NOT the maximum HP file values.

First I need the percentage strength of the current shield being worked on in the FOR loop. I do this differently depending on whether the script is running for the first time or not.
For the first run I get it on line 146 with:
Code: [Select]
ShieldPercentage = ShieldGenerators[0].GetSingleShieldPercentage(Shield)After the first run I get it on line 163 with:
Code: [Select]
ShieldPercentage = pShields.GetSingleShieldPercentage(Shield)
Then I take this percentage value and use it to calculate the current strength of the current shield.
I do this on lines:
173 (storing current secondary generator shield values)
Code: [Select]
pSecondaryShieldVals[Shield] = pSecondaryGen.GetMaxShields(Shield) / 100 * ShieldPercentage * 100186 (storing current primary generator shield values)
Code: [Select]
pPrimaryShieldVals[Shield] = pDisabledObject.GetMaxShields(Shield) / 100 * ShieldPercentage * 100
As you can see I am using the standard mathematical percentage formula: ((number / 100) * percentage) to work out what the real strength of the current shield is based on the current percentage value stored in variable ShieldPercentage.

The ShieldPercentage variable isn't very reliable. If you look at line 317 of ConsoleTrackerDump.txt you will see that in the scenario the shield generator is being disabled because both fake generators are offline; the primary generator has just been disabled and secondary is also offline.
The script should be using ShieldPercentage to calcualte the current strength of the current shield and store it, instead though because ShieldPercentage is 1.0 (100%) the maximum shield strength is being stored instead of it's current ingame damaged strength.

1a) Tactical display not correct. The ingame strength of all shields is shown as 100%, even when the correct values are loaded.

I put this down as 1A because it's tied in with the ShieldPercentage problem. Most of the time you will find, if you ran the script and looked at the log from Console Tracker, that the current strength of the shield is being calculated, recorded, loaded and applied correctly.
However you will go back ingame and see that the shield display gives all shields in GREEN status, implying 100% strength when in fact they are just as weak or strong as when the generator was disabled. Having downloaded Defiants ShieldPercentages mod I have double confirmation of this as every shield gives it's percentage value at 100%

I wonder, can I calcualte the current percentage strength value of the shield as well as the shield strength values? If so could I use it to manually set the SingleShieldPercentage value and thus force the tactical display to show the correct percentage strength?

There is a:
Code: [Select]
pShields.GetSingleShieldPercentage(Shield)but is there?
pShields.SetSingleShieldPercentage(ShieldPercentage)


IMPROVEMENTS & TO-DO:

2) Expand the scope of the script through the use of dictionaries and objectIDs, allowing it to work with an unlimited number of ships & shield generators in QB.

I will need a data structure something such as:
Code: [Select]
[allShips]
  [ship]
    [primaryGenVals]
    [secondaryGenVals]
  [ship]
    [primaryGenVals]
    [secondaryGenVals]
  [ship]
    [primaryGenVals]
    [secondaryGenVals]
  [ship]
    [primaryGenVals]
    [secondaryGenVals]

I would then need to access it in a way similar to:
allShips[shipID[primaryGenVals]]
allShips[shipID[secondaryGenVals]]

How can I possibly write the script to manage a potentially unlimited amount of ships, and further more, continue to accurately decide what generators on each ship are ON/OFF and take appropraite action?

Bear in mind that the script is called when: player gets a new ship, a (any) subsystem is disabled or operational.

(MAYBE) TO-DOs
3) Cover the CTRL + SHIFT + R scenario.

Do I need to reset shield strengths for both generators or it's gonna trip over when they force repair both generators at the same time. How do I know if the player hits those three keys?

4) Add a delay value that is accessible through the Foundation plugin so the user can choose how long it takes for the shields to switchover.

I simply have no idea how to add a real-world time delay to a script.
What if an insanely large amount of time is given for the switchover?
What if during the delay between switchover a generator is repaired or disabled? Such as primary getting disabled, a delay of N seconds starting then the primary comes back online - OR the secondary (which is all set to takeover) is disabled?

It's nice to open up the script a bit and allow some room for configuration. I personally think that there should be absolutely no delay between switchover because you will be in a warzone and it'd be a serious design flaw for there to be a delay between generator switch-overs.

5) Foundation technologies?

Will shield modifiers work or will it have problems working on ships that use Primary and Secondary shields?
Can I allow users to apply different technologies to different generators? E.G: Regenerative shields when primary is active but normal shields for secondary?
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: BC 1.1 - Secondary shield generators
« Reply #84 on: October 01, 2011, 03:51:58 PM »
Not replying to everything right now because I lost myself somewhere belong your post.

1. Shield settings do usually work. My guess is that there is still an error in the script..

2. Just look at dictionarys, you can use a ships id or name as keys.

3. You can use Game.InGodMode(), but I would ignore it because God mode is non standard and in god mode you can't die anyway.
Time is expensive, better concentrate for the important parts.

4. Same as 3. Get it working before expanding it.

5. When your script is done get some users to test it woth other mods.

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #85 on: October 01, 2011, 04:17:57 PM »
Sorry about the post length. I look at it myself and think "woah, that's long".

I am burnt out right now and won't look at another line of Python until tomorrow; my eyes hurt and this room must be => 30 degrees C.

Your most probably right about the ShieldPercentages thing I droned on about in 1)
The fact that the MAX super strong values are being stored when both targetable generators are disabled and there should be no shields. It shows that I messed up somewhere in the conditional statements, a very frustrating error considering the time I went running over and over that IF ELSE tree :facepalm:

The tactical display thing I don't want to drone on about. However I am sure that even when the script applies to correct stored values, the display shows everything at 100%  :lostit:

I promise I will look at dictionaries myself and make a real effort to get to grips with them. However can you just assure me that you can construct so many lists of values inside a single variable like that?
I will need to be able to add and remove lists from the master allShips to facilitate the creation and destruction of ships. Don't want the script to waste memory by keeping values of dead ship objects (ships destroyed in battle).

Your right about prioritising, a required skill of paramont importance in computing. However the CTRL + SHIFT + R stays on my list because I want to cover as many angles as possible. Don't want this script to ruin someones gaming session because I was lazy.
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: BC 1.1 - Secondary shield generators
« Reply #86 on: October 02, 2011, 02:36:40 AM »
Line 109:
Code: [Select]
pShields.GetProperty().SetDisabledPercentage(100.0)
This value is a number between 0 and 1.

Line 173:
Code: [Select]
# using it's percentage, store the current  shield value of secondary shield generator
pSecondaryShieldVals[Shield] = pSecondaryGen.GetMaxShields(Shield) / 100 * ShieldPercentage * 100
What are you doing here?

MaxShield is a value, e.g. strength of 10000 hitpoints, ShieldPercentage a number between 0 and 1.
So when the Shield is on 50% you store 10000/100 * 0.5 * 100 = 5000.
The formula is actually the same as just doing pSecondaryGen.GetMaxShields(Shield) * ShieldPercentage

ok now you have the value, later line 190 you restore it:
Code: [Select]
ShieldStrength = pSecondaryShieldVals[Shield]
..
pShields.GetProperty().SetMaxShields(Shield, ShieldStrength)
...
pShields.SetCurShields(Shield, ShieldStrength)
What happens here?

1. Somewhere lowered your shield value to 50%. Max Shield was 10000, so you save the value of 5000 in line 173.
2. In line 190 you restore the value later. But instead of setting MaxShield to 10000 and CurShield to 0.5 you set both to 5000!

-

In Python everything is an object. Dictionaries are there to map objects, so yes. You can even store dictionaries in dictionaries.

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #87 on: October 03, 2011, 07:01:26 PM »
Ha HAA! YES! Success!
  :angel Defiant :angel

What was I thinking? Setting both the MaxShield and CurShield to the same values. No wonder the shield percentages were coming out as 100%

The shield values are being swapped, stored, loaded and now also displayed in the tactical display correctly.

Now... how can I cover the CTRL + SHIFT + R ? I already tried it on the current version and well...it doesn't like it. A leap of faith is how i'd describe the scripts execution when you hit the three button combination.

It would be nice to get all the logic down and cover all the angles before using dictionaries and object IDs to permit any number of ships with Primary/Secondary shields.

Speaking of the dictionaries, is there an event handler for the destroy ship event?
When I get round to expanding, I will need one if I am to remove the values of a ships shields from the master dictionary - if not removed the dictionary will grow and grow.
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: BC 1.1 - Secondary shield generators
« Reply #88 on: October 04, 2011, 06:43:23 AM »
God mode:
Look at TacticalInterfaceHandlers.py for godmode.

Destroy:
See http://kobmaru.de/svn/trunk/scripts/Custom/QBautostart/BorgEmergEscape.py for Exploding event.

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #89 on: October 05, 2011, 03:04:32 PM »
Just so you know I havn't abandoned the script here's an

UPDATE:
 :yay: The script can now handle a potentially unlimited number of primary/secondary generator ships! :yay:
The script now uses a dictionary and the unique ID of each object(ship) to store shield values. Also, when a ship with Primary/Secondary shields is destroyed it's shield values are removed from the dictionary.


CURRENTLY:
CTRL + SHIFT + R doesn't want to play ball :nono:
I setup a working event handler for the insta-repair event (ctrl+shift+r) but when it calls RedefineShieldGenerators() it doesn't get past the first print statement. This is (i think) obviously because GetAllShieldGenerators() is being naughty and returning an empty retList (list of fake shield generators).
Why does GetAllShieldGenerators() work 99% of time, but break when ShipInstaRepair() calls it?

Check out the attached log file, it gets really wierd from line 330 (when the ctrl+shift+r handler fires) onwards. The handler fires three times (when I hit insta-repair once ingame!) but RedefineShieldGenerators() dies before it does anything because of:
Code: [Select]
if NumTotalGenerators == 0:
                return
Great men are not peacemakers! Great men are conquerors!

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #90 on: October 09, 2011, 09:48:56 AM »
I know I know it's a double post, sorry. :P

I sorted out the stupid problem I mentioned. Every event handler other than ShipInstaRepair() was using:
Code: [Select]
pShip = App.ShipClass_Cast(pEvent.GetDestination())to cast the pShip argument for GetAllShieldGenerators() However the pEvent for ShipInstaRepair() is what I technically describe as "weird" so long story short I had to cast pShip for GetAllShieldGenerators() using:
Code: [Select]
pShip = App.ShipClass_Cast(pShip.GetTarget())
------------------------------------
My approach to covering CTRL + SHIFT + R is simple. Use the ShipInstaRepair() event handler to reset all the shield values for both fake generators to their maximum values & force fake primary to become the active generator. I do this by simply calling RedefineShieldGenerators() with the firstScriptRun (3rd arg) as 1.

The handler works just how I want it to, despite firing multiple times even though I hit CTRL+SHIFT+R only once ingame!


NOW

Some things to let you know.
#1: In the QB scenario (for simplicity & the log size) there is only one ship with primary/secondary generators; a scimitar.
#2: It is SubsystemOperational() that really screws things up.

The log reflects that I:
(1)disabled the (targetable) primary generator,
(2)disabled the (targetable) secondary generator.
(3)Hit CTRL+SHIFT+R,
(4)then disabled the (targetable) primary generator.
(5)Exited game.

Going by the attached log.
(1)
Line 106 to 178 - Primary gen is disabled, it's values are stored and secondary takes over.
(2)
Line 182 to 224 - Secondary gen is disabled, it's values are stored and the real hidden gen is disabled.
(3)
>Line 228 to 281 - ShipInstaRepair() fires for the first time. RedefineShieldGenerators() is called and runs as it should; re-setting all shields to their max values, making the fake primary gen the activeShieldGen.
 :lostit: !LOOP START! :lostit:
Line 285 to 337 - ShipInstaRepair() fires. RedefineShieldGenerators() is called and runs as it should.
Line 341 to 393 - ShipInstaRepair() fires. RedefineShieldGenerators() is called and runs as it should.
Line 397 to 449 - ShipInstaRepair() fires. RedefineShieldGenerators() is called and runs as it should.
Line 453 to 505 - ShipInstaRepair() fires. RedefineShieldGenerators() is called and runs as it should.
Line 509 to 561 - ShipInstaRepair() fires. RedefineShieldGenerators() is called and runs as it should.
Line 565 to 617 - ShipInstaRepair() fires. RedefineShieldGenerators() is called and runs as it should.
 :lostit: !LOOP END! :lostit:

>Line 565 to 617 SubsystemOperational() fires. RedefineShieldGenerators() is called (firstScriptRun = 0) which proceeds to overwrite the dictionary values for the Secondary gen with 0 and make fake Primary gen the activeShieldGen.
>Line 697 to 706 SubsystemOperational() fires. RedefineShieldGenerators() is called (firstScriptRun = 0), but it knows Primary is already on so does nothing.

(4)
Line 710 to 782 - Primary gen is disabled, it's values are stored and secondary takes over.
TA - DA! Ingame evidence that the script has fallen flat on its face, Primary offline, Secondary online and no shields!
(5)
Line 783 to EOF - I destroy the scimitar and exit game!

---------------------------------------------------------------------------------------
Why is there a loop with ShipInstaRepair() ?
How do I stop SubsystemOperational() from firing and screwing things up! ?

*Previews post* Wow! That is long!  :doh: Sorry
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: BC 1.1 - Secondary shield generators
« Reply #91 on: October 10, 2011, 03:34:01 AM »
Do you reset your global values on repair?

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #92 on: October 10, 2011, 08:31:55 AM »
I had to do a little guess work on what you meant by
Quote from: Defiant
global values on repair?
so don't shoot me if I guessed wrong.  :idk:

I assume you are talking about the master allShips dictionary array because that is the only (intentionally created) global variable, that I know of, in the script. I don't set the shield values to 0 when ShipInstaRepair() fires. All it does is call RedefineShieldGenerators() to reset all the shield values for the repaired ship to their HardPoint MAX values.

The log shows clear evidence that RedefineShieldGenerators() does its job correctly.
>Line 228 to 281 - ShipInstaRepair() fires for the first time. RedefineShieldGenerators() is called and runs as it should; re-setting all shields to their max values, making the fake primary gen the activeShieldGen.

When RedefineShieldGenerators() is called from SubsystemOperational() it gives an argument firstScriptRun = 0. This is what screws things up.
I DO NOT want the operational handler to get involved when ShipInstaRepair() fires because ShipInstaRepair() does all the work that needs to be done.

Because RedefineShieldGenerators() is called with firstScriptRun = 0 after the shields have been setup, it goes crazy with the shield values (setting them to 0).
>Line 565 to 617 SubsystemOperational() fires. RedefineShieldGenerators() is called (firstScriptRun = 0) which proceeds to overwrite the dictionary values for the Secondary gen with 0 and make fake Primary gen the activeShieldGen.
Just need to stop the Operational handler getting involved when CTRL+SHIFT+R handler has done it's work and there should be no problems. ... I hope  :(
Great men are not peacemakers! Great men are conquerors!

Offline KrrKs

  • Posts: 461
  • Cookies: 25
Re: BC 1.1 - Secondary shield generators
« Reply #93 on: October 10, 2011, 11:49:47 AM »
It has been some time since I tried scripting something, so this is most likely not the optimal approach,
but you could add a global boolean per Ship.
If InstaRepair is called it could set this Boolean to false, and initiate a Timer that sets it back to true after a short time (or the other way around).
In SubsystemOperational() you could then check the this variable to see if InstaRepair was just executed on that ship.

But I don't know how repeated usage of that Timer would influence BC's Stability.

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #94 on: October 10, 2011, 02:35:12 PM »
Giving a specified amount of time in which the Operational handler can't fire.... hmmm. I'm not exactly in a position of BC Python power to crush your idea since i'm a noob beginner. However, I see problems because the handler would be unable to fire when another ships primary/secondary shield generators become active. It would effectively be saying to the script "this ship is more important, ignore everyone else for X long".

Also, do the event handlers stack up? I mean if an event (such as CTRL+SHIFT+R) causes lots of Operational handler fires, don't they all stack up and wait their turn? It certainly looks that way at the moment because the Operational handler fires twice when both generators are currently disabled and the user hits CTRL+SHIFT+R.

My problem is I don't have any insight into how BC handles things. I've done some event driven stuff in VB ( :facepalm:) but have no view of the environment the script is being executed in; other than QuickBattle, of course..
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: BC 1.1 - Secondary shield generators
« Reply #95 on: October 12, 2011, 02:22:43 AM »
Uhm, why do you even call RedefineShieldGenerators() on instant repair?

My guess is that you do not need to do anything special. Just clear your globals for this ship and handle it like you get a clean new one and set your shield values to the primary one.

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: BC 1.1 - Secondary shield generators
« Reply #96 on: October 12, 2011, 06:41:58 AM »
That is correct, all I need to do is set the globals for the ship to their max values and set primary as the active shield generator. This is exactly what RedefineShieldGenerators() does when you call it with the 3rd argument as 1 (firstScriptRun = 1).

RedefineShieldGenerators() is the only function that actually *does* anything to the shield values, and it runs just fine like I wanted when instant repair handler calls it.

I need a way to stop the operational handler firing when instant repair fixes the shield generators because when it calls RedefineShieldGenerators() it calls it with firstScriptRun = 0. As a result the Redefine function gets it wrong and overwrites the shield values like I explained

>Line 565 to 617 SubsystemOperational() fires. RedefineShieldGenerators() is called (firstScriptRun = 0) which proceeds to overwrite the dictionary values for the Secondary gen with 0 and make fake Primary gen the activeShieldGen.
>Line 697 to 706 SubsystemOperational() fires. RedefineShieldGenerators() is called (firstScriptRun = 0), but it knows Primary is already on so does nothing.

(4)
Line 710 to 782 - Primary gen is disabled, it's values are stored and secondary takes over.
TA - DA! Ingame evidence that the script has fallen flat on its face, Primary offline, Secondary online and no shields!
(5)

Note that when the operational handler first fires and sets the primary generator as the active shield generator, it IS ALREADY the active shield generator because RedefineShieldGenerators() has already ran (firstScriptRun = 1) and set everything up correctly.


EDIT:
14/10/11
UPDATE
Not sure if this is the best way (most efficient) but I got a function down that checks if ShipInstaRepair() has just ran by first checking if both generators are operational. Then it runs through all the shield values in allShips for the given ship to see if there all at max strength.

The function returns 1 (true) if InstaRepair() has just ran or 0 (false) if it hasn't. I use it ShipInstaRepair() to stop it calling RedefineShieldGenerators() over and over to the same thing again and again! I also use it in the operational handler so it doesn't run the redefine function and mess up the values.

What do you think?
Code: [Select]
# check if ShipInstaRepair() has already ran by checkingif both generators are operational & all shields at full strength
def InstaRepairAlreadyRan(pShip):
ShieldGenerators = GetAllShieldGenerators(pShip)
if ShieldGenerators[0].IsDisabled() or ShieldGenerators[1].IsDisabled():
return 0
else:
lShields = GetPrimarySecondaryGenNames(pShip)
pPrimaryGen = MissionLib.GetSubsystemByName(pShip, lShields[0])
pSecondaryGen = MissionLib.GetSubsystemByName(pShip, lShields[1])
pPrimaryGen = App.ShieldClass_Cast(pPrimaryGen)
pSecondaryGen = App.ShieldClass_Cast(pSecondaryGen)
shipID = pShip.GetObjID()
i = 0
while(i < 6):
if not allShips[shipID][0][i] == pPrimaryGen.GetMaxShields(i):
return 0
if not allShips[shipID][1][i] == pSecondaryGen.GetMaxShields(i):
return 0
i = i + 1
return 1

It seems to work quite well from what both the log, and ingame, gives out.

Line 376 down, the secondary shield values  :)

Hoping to keep the script tight and quick (less lag!) I was hoping for something less crude than looping through every shield value. I can live with it but is there a better way?


EDIT:
14/10/11 two

You can use CTRL+SHIFT+K to disable a generator without damaging any of the shields, as a result my InstaRepairAlreadyRan() function returns 1 (true) and SubsystemOperational() doesn't run when the generator comes back online!
Damn it!  :banghead:
Great men are not peacemakers! Great men are conquerors!