Author Topic: Secondary generators script, close to release testing but...  (Read 3195 times)

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Only a few nagging problems i've found that I can't get around.

(1) The FTech Breen Damper: Doesn't trigger the SubsystemDisabled() event handler. This is annoying because when the damper takes effect both non-primary (.IsPrimary(0) = true) targetable shield generators remain operational (are not greyed out) and the shield display window text remains the same.

Code used:
Code: [Select]
# handler
def SubsystemDisabled(pObject, pEvent):
# do stuff
        pObject.CallNextHandler(pEvent)

def init():
# Multiplayer check
if App.g_kUtopiaModule.IsMultiplayer() and not App.g_kUtopiaModule.IsHost():
return
pMission = MissionLib.GetMission()
# handler definition
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_SUBSYSTEM_DISABLED, pMission ,  __name__ + ".SubsystemDisabled")

(2) Can't get the handlers for ending and/or restarting of quickbattle to work. I need these to reset the shield display window text so it doesn't bug out and say "Primary Active" when you're back in your Galaxy ship or whatever. Although, i'm not very sure what happens to my script and all its variables when quick battle is restarted or ended.

Currently trying to use:
Code: [Select]
# top of script imports
from QuickBattle import Quickbattle

# script code bla bla

def init():
# Multiplayer check
if App.g_kUtopiaModule.IsMultiplayer() and not App.g_kUtopiaModule.IsHost():
return
print "init() ---------------------------------"
pMission = MissionLib.GetMission()
# event handlers
Quickbattle.AddPythonFuncHandlerForInstance(Quickbattle.ET_RESTART_SIMULATION, __name__ + ".RestartSimulation")
Quickbattle.AddPythonFuncHandlerForInstance(Quickbattle.ET_END_SIMULATION, __name__ + ".EndSimulation")

(3) Can't remove inneficieny of the timer being called every 1 seconds even when there are no unused generators shields to go through and heal. Where's the friggin' delete function for timers that were created with MissionLib.CreateTimer().
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Secondary generators script, close to release testing but...
« Reply #1 on: July 24, 2012, 04:52:35 AM »
2) Try NewPlayerShip(), see http://kobmaru.de/svn/trunk/scripts/Custom/QBautostart/ShieldGenerators.py

3)
Code: [Select]
pTimer = MissionLib.GetTimer(...)
...
idTimer = pTimer.GetObjID()
App.g_kTimerManager.DeleteTimer(idTimer)
App.g_kRealtimeTimerManager.DeleteTimer(idTimer)


Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: Secondary generators script, close to release testing but...
« Reply #2 on: July 24, 2012, 10:27:55 AM »
What about (1)?
Only a few nagging problems i've found that I can't get around.

(1) The FTech Breen Damper: Doesn't trigger the SubsystemDisabled() event handler. This is annoying because when the damper takes effect both non-primary (.IsPrimary(0) = true) targetable shield generators remain operational (are not greyed out) and the shield display window text remains the same.

Code used:
Code: [Select]
# handler
def SubsystemDisabled(pObject, pEvent):
# do stuff
        pObject.CallNextHandler(pEvent)

def init():
# Multiplayer check
if App.g_kUtopiaModule.IsMultiplayer() and not App.g_kUtopiaModule.IsHost():
return
pMission = MissionLib.GetMission()
# handler definition
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_SUBSYSTEM_DISABLED, pMission ,  __name__ + ".SubsystemDisabled")

2) Try NewPlayerShip(), see http://kobmaru.de/svn/trunk/scripts/Custom/QBautostart/ShieldGenerators.py
2) NewPlayerShip() was no good. Contrary to its function name it only seems to get called at the start of the quick battle scene (because I explicitly called it from init() ) and when the player transports to another ship in quick battle. The function that I actually found got called, oddly enough, when quick battle ends is NewShip(). Strange huh?

Either way number 2 is off my list and the text window quick battle end / restart issue is fixed.  :yay:


3)
Code: [Select]
pTimer = MissionLib.GetTimer(...)
...
idTimer = pTimer.GetObjID()
App.g_kTimerManager.DeleteTimer(idTimer)
App.g_kRealtimeTimerManager.DeleteTimer(idTimer)

(3) I can't find a GetTimer in MissionLib. Can you show me a simple example of creating and deleting a timer when the timer is created with:
Code: [Select]
MissionLib.CreateTimer(Lib.LibEngineering.GetEngineeringNextEventType(), __name__ + ".UpdateStoredGenHealth", App.g_kUtopiaModule.GetGameTime() + 1, 0, 0)
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Secondary generators script, close to release testing but...
« Reply #3 on: July 24, 2012, 01:03:44 PM »
ok, this is a bug then in QBautostart. Can you try the version from KM please?
-
CreateTimer() of course..

Offline Mario

  • Senior Software Developer
  • Administrator
  • Posts: 2200
  • Cookies: 1707
  • Life is life
Re: Secondary generators script, close to release testing but...
« Reply #4 on: July 24, 2012, 03:58:41 PM »
1. You could try overiding the method with your own from within your own module and trigger that event.
2. Did you try using the event handler? It's triggered when a new player ship has been created.
Code: [Select]
Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP
Acta, non verba.
aka USS Sovereign

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: Secondary generators script, close to release testing but...
« Reply #5 on: July 24, 2012, 07:40:20 PM »
1. You could try overiding the method with your own from within your own module and trigger that event.
2. Did you try using the event handler? It's triggered when a new player ship has been created.
Code: [Select]
Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP
Nope, these are the handlers that i'm using.
Code: [Select]
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_SUBSYSTEM_DISABLED, pMission ,  __name__ + ".SubsystemDisabled")
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_SUBSYSTEM_OPERATIONAL, pMission ,  __name__ + ".SubsystemOperational")
App.g_kEventManager.AddBroadcastPythonFuncHandler(Foundation.TriggerDef.ET_FND_CREATE_SHIP, pMission, __name__ + ".NewShip")
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_OBJECT_EXPLODING, pMission, __name__ + ".ObjectDestroyed")
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_TARGET_WAS_CHANGED, pMission, __name__ + ".TargetChange")
# TestMode / debug / CHEAT event handlers
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_INPUT_DEBUG_QUICK_REPAIR, pMission, __name__ + ".ShipInstaRepair")
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_INPUT_DEBUG_KILL_TARGET, pMission, __name__ + ".ShiftKHit")
App.g_kEventManager.AddBroadcastPythonFuncHandler(App.ET_INPUT_DEBUG_GOD_MODE, pMission, __name__ + ".GodModeOn")

Defiant. I'm using the latest version of QBautostart available. Not sure how KMs version is gonna differ.

Also, if QBAutostart isn't using NewPlayerShip() as expected why is it that without me specifying it as handler it gets called when the player transports to another ship?

Also... guys, what is to be done about the Breen Damper. It disables all these subsystems but doesn't trigger SubSystemDisabled() :wtf
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Secondary generators script, close to release testing but...
« Reply #6 on: July 25, 2012, 06:28:32 AM »
init(), exit(), Restart() and NewPlayerShip() are all functions called by the QBautostart extension.

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: Secondary generators script, close to release testing but...
« Reply #7 on: July 25, 2012, 01:31:44 PM »
init(), exit(), Restart() and NewPlayerShip() are all functions called by the QBautostart extension.
Defiant. I have this http://bridgecommander.filefront.com/file/;39736 installed on my 1.1 along with the full 2008 latest Foundation version.

If that's the same stuff used in KM then there should be no difference, right  :s

You say NewPlayerShip() triggers when the player gets a new ship I won't argue with you. However it's a fact that on my install NewShip() (using Foundation.TriggerDef.ET_FND_CREATE_SHIP) is triggered when:
  • the player starts Quick Battle (after setting it up with Saffi).
  • the player gets his ship at the end of quick battle (when quick battle ends)

Whilst NewPlayerShip() is only triggered when the player transports (using Transport2Ship) to another ship in quick battle.
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Secondary generators script, close to release testing but...
« Reply #8 on: July 25, 2012, 01:58:24 PM »
And I suggested to try the Version from KM, because KM might have a newer version.

ET_FND_CREATE_SHIP is for creation of any ship. It works for you because a few asteroids get (re-)created when you start a new battle.

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: Secondary generators script, close to release testing but...
« Reply #9 on: July 25, 2012, 03:18:12 PM »
I dealt with the timer thing I was after. I never managed to delete the timer per-se but instead only renewed it when their are values in the dictionary of generators to be fixed every 1 seconds.  :)

And I suggested to try the Version from KM, because KM might have a newer version.

ET_FND_CREATE_SHIP is for creation of any ship. It works for you because a few asteroids get (re-)created when you start a new battle.
Asteroids? In the Deep space setting with nothing else in the entire set except the players ship?

Fight in deep space. End battle or get killed and poof, NewShip() fires when your ship is created.

And I suggested to try the Version from KM, because KM might have a newer version.
How painfull. Can't QBautostart just be QBautostart and we can all go to the same place to get the same scripts? Why does KM have to have different versions of everything?
Great men are not peacemakers! Great men are conquerors!

Offline Mario

  • Senior Software Developer
  • Administrator
  • Posts: 2200
  • Cookies: 1707
  • Life is life
Re: Secondary generators script, close to release testing but...
« Reply #10 on: July 25, 2012, 05:16:19 PM »
1. Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP is triggered when a player ship is created and you can use it for qb restart scenarios.
2. To deal with FTech damper you should override the method. Check out 000-Expansion-RepairShip.py file as a sample it is located in autoload folder. It comes with DS9FX Xtended.
Acta, non verba.
aka USS Sovereign

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: Secondary generators script, close to release testing but...
« Reply #11 on: July 25, 2012, 08:54:55 PM »
2. To deal with FTech damper you should override the method. Check out 000-Expansion-RepairShip.py file as a sample it is located in autoload folder. It comes with DS9FX Xtended.
Thanks for the info. I'm hesitant to mess with other peoples scripts not only because I might mess them up but also because it'll expand this mod from just one script to a script and an overide of someone elses work  :idk:

Before I screw about with others work I wanna pay attention to the handlers i'm using and what they do so onto...

1. Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP is triggered when a player ship is created and you can use it for qb restart scenarios.
I took the event you gave me, took the ShieldGen script out of the picture and did some testing in a seperate script.

In the script I used only these handlers:

Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP with handler function PlayerShipCreated()
Foundation.TriggerDef.ET_FND_CREATE_SHIP with handler function NewShip()

Aside from the handler functions above there was only NewPlayerShip() with no specific calls to it in the script; just the function definition. Every function had the same stuff in it (except NewPlayerShip as it doesn't have pObject and pEvent) which was:
Code: [Select]
def functionname(pObject, pEvent):
        print "%functionname%() ------------", App.g_kUtopiaModule.GetGameTime()
        pShip = App.ShipClass_Cast(pEvent.GetDestination())
        if not pShip:
                return
print "Type =", GetShipType(pShip)
if pShip.IsPlayerShip():
print "-----------> Players ship"
print '\n\n'
        pObject.CallNextHandler(pEvent)

Here's the log broken down.

#1 Quick Battle is entered from the main menu. Quick Battle scene loads. There's no evidence in the log whatsoever, no handlers fire.

#2 Quick Battle is setup through Saffi's menu and game starts with selected ships.
Quote
####
NewShip() ------------ 1492.89257813
Type = CardHybrid
-----------> Players ship
####
####
PlayerShipCreated() ------------ 1492.89257813
Type = CardHybrid
-----------> Players ship
####
####
NewShip() ------------ 1492.89257813
Type = Freighter
####
^ As you can see NewShip() and PlayerShipCreated() are called for the same ship.

#3 I AddShip a Sovereign into the scene and transport to it using Transport2Ship from QBautostart.
Quote
####
NewShip() ------------ 1554.71875
Type = Sovereign
####
####
NewPlayerShip() ------------ 1586.49072266
Type = Sovereign
Okay.

#4 Now... I end combat through Saffi's menu and am greeted with an invisible ship, no bridge and Player still listed as a target with every targetable property set to 0 health.
Quote
Traceback (innermost last):
  File ".\Scripts\QuickBattle\QuickBattle.py", line 2579, in EndSimulationEvent
    EndSimulation()
####
####
  File ".\Scripts\QuickBattle\QuickBattle.py", line 2628, in EndSimulation
    RecreatePlayer()
####
####
  File ".\Scripts\QuickBattle\QuickBattle.py", line 2284, in RecreatePlayer
    vLocation = pPlayer.GetWorldLocation()
####
####
AttributeError: 'None' object has no attribute 'GetWorldLocation'
PlayerShipCreated() ------------ 1734.5703125
####
Interesting, no?

#5 Now I go through all the above steps up until #4 and then End Combat. It plays out exactly as it did in #1 with NewShip() firing first and then PlayerShipCreated() next both for the same (players) ship.

So in conclusion:
> Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP fires only at the start and end of a Saffi setup QB. Not good if the player has AddShip installed and can have battles before setting up a Saffi battle.

> Foundation.TriggerDef.ET_FND_CREATE_SHIP fires for every ship type object whenever it's created, even if it's the players ship. Good for setting up anything that's added. Makes ET_FND_CREATE_PLAYER_SHIP redundant as .IsPlayerShip() and a simple variable can be used to determine if the ship has or hasn't been setup.

> NewPlayerShip() only ever fires when the player transports to another ship. Useful but misleading because of its name.

Right? I don't doubt Defiants claims of how NewPlayerShip() runs in KM but i've ran all these handlers with stock ships in 1.1 with Foundation (latest on BC files) and QBautostart extension (latest on BC files). The log is there and it doesn't lie.

For Your Info Defiant i'm running Foundation from BCUT version 1.7.5.0. QBautostart from your filefront http://bridgecommander.filefront.com/file/;39736 0.9.1.
Great men are not peacemakers! Great men are conquerors!

Offline Defiant

  • Posts: 398
  • Cookies: 1105
    • BC: Kobayashi Maru
Re: Secondary generators script, close to release testing but...
« Reply #12 on: July 26, 2012, 03:13:21 AM »
How painfull. Can't QBautostart just be QBautostart and we can all go to the same place to get the same scripts? Why does KM have to have different versions of everything?
Because when working on KM I often found bugs in the Mods that I fixed right in place.

Offline JimmyB76

  • Posts: 6423
  • Cookies: 421
Re: Secondary generators script, close to release testing but...
« Reply #13 on: July 26, 2012, 07:03:55 AM »
How painfull. Can't QBautostart just be QBautostart and we can all go to the same place to get the same scripts? Why does KM have to have different versions of everything?
Because when working on KM I often found bugs in the Mods that I fixed right in place.
and i for one am thankful that you did and took the time and effort to!  :)  :thumbsup:
cheers!

Bat66wat6, im sure defiant will put out QBA 1.0 when/if he feels like it...  in the meantime youre getting *alot* of help from BC's finest scripters...  and you will likely be BC's next finest scripter if you choose to do so after your current mod (if your intent is to release it)...
so please just chill and have patience and just be glad and thankful that youre getting help from the best in the business... and try not to complain too much about why isnt what... sovvy and defiant dont have to help, they are kind enough to...  they could stop right now and then where would you be?  
so take a breather dude and try to maintain gratitude and respect and show appreciation, because your annoyance is really sometimes showing through in your words lately, even if you dont mean to do so or are even aware of it...  scripting is terribly annoying, we all know that lol  

hopefully youll next script (should you decide to do one) wont cause as much grief for ya, youve already learned quite a bit so far :)

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: Secondary generators script, close to release testing but...
« Reply #14 on: July 26, 2012, 10:16:38 AM »
Because when working on KM I often found bugs in the Mods that I fixed right in place.
Okay, that's understandable :) Now I can see how mods aren't frequently dubbed 1.1 and KM compatible and why so many mods are only made for KM.

With this new knowledge in hand i'm lost as to how to proceed with this version difference. You reckon I should just take KMs QBautostart and overide the 0.91? That way anyone who gets the mod also gets a free KM upgrade to their 1.1 autostart

Bat66wat6, im sure defiant will put out QBA 1.0 when/if he feels like it...  in the meantime youre getting *alot* of help from BC's finest scripters...  and you will likely be BC's next finest scripter if you choose to do so after your current mod (if your intent is to release it)...
so please just chill and have patience and just be glad and thankful that youre getting help from the best in the business... and try not to complain too much about why isnt what... sovvy and defiant dont have to help, they are kind enough to...  they could stop right now and then where would you be?  
so take a breather dude and try to maintain gratitude and respect and show appreciation, because your annoyance is really sometimes showing through in your words lately, even if you dont mean to do so or are even aware of it...  scripting is terribly annoying, we all know that lol  

hopefully youll next script (should you decide to do one) wont cause as much grief for ya, youve already learned quite a bit so far :)
:sam: I just read through the thread and I can see why it I come across as complaining and ungrateful. No lying that i'm inexperienced and don't understand everything, that I make incorrect assumptions and when I don't understand what i'm being asked to do my response posts can be read as negative in tone.

I am and have always been grateful for Defiant and Sovereign's help. I never even expected them to still be here after all this time. I'm well aware that they can dissapear anytime they want and, frankly, i'm surprised they already havn't given the decline of the forums.

There's no disrespect meant in my words. Lately though I just want my posts to be straight to the point because I tend to ramble and give unnecessary information making it harder for Sovereign/Defiant to help. If i'm clear in what my problem is, what i'm doing currently and what I want to do it's easier for all involved in the thread  :)

In my last post above I was just illustrating how 0.9.1 QBautostart actually works so I could dispell any doubt in my or Defiants mind as to how it works on 1.1. No insult to Defiant at all but having made so many mods and KM being his crown jewel the behaviour of older out-dated scripts is easily forgoten; if i'd made a better version of x i'd forget the version before as well  :P
Great men are not peacemakers! Great men are conquerors!

Offline JimmyB76

  • Posts: 6423
  • Cookies: 421
Re: Secondary generators script, close to release testing but...
« Reply #15 on: July 26, 2012, 03:02:50 PM »
i just gave ya a bunch of cookies :)
keep it going, dude!!  i do hope after this mod youre doing, it will make you enthusiastic take on a new scripting idea :D  :thumbsup:

Offline Mario

  • Senior Software Developer
  • Administrator
  • Posts: 2200
  • Cookies: 1707
  • Life is life
Re: Secondary generators script, close to release testing but...
« Reply #16 on: July 26, 2012, 03:57:00 PM »
Quote
Thanks for the info. I'm hesitant to mess with other peoples scripts not only because I might mess them up but also because it'll expand this mod from just one script to a script and an overide of someone elses work

Before I screw about with others work I wanna pay attention to the handlers i'm using and what they do so onto...

You could have at least taken a look at the implementation first. It is a safe override since you're not directly altering the source code. Implementation goes as follows:
1. "Override the method"
2. Call the base method
3. Fire your custom event in your script

Your only other alternative is to alter the source code.

Quote
Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP fires only at the start and end of a Saffi setup QB. Not good if the player has AddShip installed and can have battles before setting up a Saffi battle.

That's what I recall you asked for.

Quote
Foundation.TriggerDef.ET_FND_CREATE_SHIP fires for every ship type object whenever it's created, even if it's the players ship. Good for setting up anything that's added. Makes ET_FND_CREATE_PLAYER_SHIP redundant as .IsPlayerShip() and a simple variable can be used to determine if the ship has or hasn't been setup.

That's why you grab obj ids and check if the player ship triggered the event and skip it.

Quote
NewPlayerShip() only ever fires when the player transports to another ship. Useful but misleading because of its name.

As Defiant said try the latest version. There is some custom functionality in the LoadQBAutostart, but in reality it uses App.ET_SET_PLAYER event. Try attaching to that event directly instead of using NewPlayerShip or Restart or handle both QB Autostart events since both are tied to that stock event.
Acta, non verba.
aka USS Sovereign

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: Secondary generators script, close to release testing but...
« Reply #17 on: July 26, 2012, 06:46:18 PM »
Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP fires only at the start and end of a Saffi setup QB. Not good if the player has AddShip installed and can have battles before setting up a Saffi battle.
That's what I recall you asked for.
True, that's what I asked for. My excuse for being a dumbass at the time is I thought it would fire whenever the players ship is created regardless of pre-Saffi QB or start/end of real QB. Sorry  :idk:  :doh:

As Defiant said try the latest version. There is some custom functionality in the LoadQBAutostart, but in reality it uses App.ET_SET_PLAYER event. Try attaching to that event directly instead of using NewPlayerShip or Restart or handle both QB Autostart events since both are tied to that stock event.
I took what you said and figured QBautostarts special functions (like NewPlayerShip()) are unpredictable across 1.1/KM so dropped them entirely.

Simplicity being the word here's what I got now in the testing script.

Init() handlers:
Code: [Select]
App.ET_SET_PLAYER, pMission, __name__ + ".PlayerShip")
Foundation.TriggerDef.ET_FND_CREATE_SHIP, pMission, __name__ + ".NewShip")
App.ET_OBJECT_EXPLODING, pMission, __name__ + ".ObjectDestroyed")

PlayerShip(None,None) is called at end of init() as I wasn't able to get a handler that fires at start of qb scene (before Saffi setup).
Code: [Select]
# players ship has been created OR player has transported to another ship
def PlayerShip(pObject, pEvent):
pShip = MissionLib.GetPlayer()
        if not pShip:
                return
# check if not already setup (transported to another ship)
# setup players ship
if pObject and pEvent:
pObject.CallNextHandler(pEvent)

# ship or starbase created, skips player as it's handled by PlayerShip()
def NewShip(pObject, pEvent):
        pShip = App.ShipClass_Cast(pEvent.GetDestination())
        if not pShip:
                return
if pShip.IsPlayerShip():
return
# do some check if need be then -> setup the new ship
        pObject.CallNextHandler(pEvent)

def ObjectDestroyed(pObject, pEvent):
        pShip = App.ShipClass_Cast(pEvent.GetDestination())
        if not pShip:
                return
# do some checking, do relevant stuff
        pObject.CallNextHandler(pEvent)

It all works really well. The only problem i've found is I can't find a handler for when the game deletes ships when you "End Combat".
I have tried:
App.ET_OBJECT_DELETED
App.ET_SHIP_ACTION_AI_DELETED
Great men are not peacemakers! Great men are conquerors!

Offline Mario

  • Senior Software Developer
  • Administrator
  • Posts: 2200
  • Cookies: 1707
  • Life is life
Re: Secondary generators script, close to release testing but...
« Reply #18 on: July 26, 2012, 07:09:10 PM »
Quote
PlayerShip(None,None) is called at end of init() as I wasn't able to get a handler that fires at start of qb scene (before Saffi setup).

ET_MISSION_START, this is also when KM's calls init() functions across all scripts located in the qbautostart directory.

Quote
It all works really well. The only problem i've found is I can't find a handler for when the game deletes ships when you "End Combat".

In our scripts we at BCS-TNG used the following when we had the requirements to detect end combat:
Code: [Select]
pSaffiQB = GetMenuButton("Commander", "End Combat")        
if pSaffiQB:
        pSaffiQB.RemoveHandlerForInstance(App.ET_ST_BUTTON_CLICKED, __name__ + ".CombatEnded")

def GetMenuButton(sMenuName, sButtonName):
        pMenu = GetBridgeMenu(sMenuName)
        if not pMenu:
                return

        # Grab the starting button.    
        pButton = pMenu.GetButton(sButtonName)
        if not pButton:
                pButton = pMenu.GetSubmenu(sButtonName)
                if not pButton:
                        return
        return pButton

def CombatEnded(pObj, pEvent):
        pass
Acta, non verba.
aka USS Sovereign

Offline Bat66wat6

  • Posts: 144
  • Cookies: 34
  • Running custom BC 1.1
Re: Secondary generators script, close to release testing but...
« Reply #19 on: July 26, 2012, 08:16:32 PM »
ET_MISSION_START, this is also when KM's calls init() functions across all scripts located in the qbautostart directory.
I tried ET_MISSION_START, it didn't work. However, since QBautostart calls init() 10/10 times at the start of the QB pre-saffi stage and it only requires PlayerShip(None,None) with some minor modification to PlayerShip to accomodate this call... there isn't really a need for a handler because we *know* at that point init() is being called at when you're being prompted to setup a QB session through saffi.
...
Right  :s

In our scripts we at BCS-TNG used the following when we had the requirements to detect end combat:
Code: [Select]
pSaffiQB = GetMenuButton("Commander", "End Combat")        
if pSaffiQB:
        pSaffiQB.RemoveHandlerForInstance(App.ET_ST_BUTTON_CLICKED, __name__ + ".CombatEnded")

def CombatEnded(pObj, pEvent):
        pass
:s  
Removing the handler that hasn't been created in the script? How do I setup handlers for buttons that already exist?

I've only ever used:
App.g_kEventManager.AddBroadcastPythonFuncHandler(EVENT, pMission, __name__ + ".FUNCTIONNAME")
And making buttons:
pButton = Lib.LibEngineering.CreateMenuButton("BUTTONNAME", "Tactical", __name__ + ".FUNCTIONNAME")

Why pSaffiQB.RemoveHandlerForInstance ? Where's the adding of this handler?
 :lostit:
Great men are not peacemakers! Great men are conquerors!