Bridge Commander Central
BC Forums => BC Scripting => Topic started by: Bat66wat6 on July 23, 2012, 10:30:40 PM
-
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:
# 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:
# 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().
-
2) Try NewPlayerShip(), see http://kobmaru.de/svn/trunk/scripts/Custom/QBautostart/ShieldGenerators.py
3)
pTimer = MissionLib.GetTimer(...)
...
idTimer = pTimer.GetObjID()
App.g_kTimerManager.DeleteTimer(idTimer)
App.g_kRealtimeTimerManager.DeleteTimer(idTimer)
-
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:
# 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)
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:
MissionLib.CreateTimer(Lib.LibEngineering.GetEngineeringNextEventType(), __name__ + ".UpdateStoredGenHealth", App.g_kUtopiaModule.GetGameTime() + 1, 0, 0)
-
ok, this is a bug then in QBautostart. Can you try the version from KM please?
-
CreateTimer() of course..
-
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.
Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP
-
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.
Foundation.TriggerDef.ET_FND_CREATE_PLAYER_SHIP
Nope, these are the handlers that i'm using.
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
-
init(), exit(), Restart() and NewPlayerShip() are all functions called by the QBautostart extension.
-
init(), exit(), Restart() and NewPlayerShip() are all functions called by the QBautostart extension.
Defiant. I have this http://bridgecommander.filefront.com/file/;39736 (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.
-
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.
-
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?
-
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.
-
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:
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.
####
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.
####
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.
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 (http://bridgecommander.filefront.com/file/;39736) 0.9.1.
-
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.
-
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 :)
-
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
-
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:
-
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.
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.
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.
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.
-
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:
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).
# 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
-
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.
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:
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
-
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:
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:
-
Wrong snippet. It's late over here.
AddPythonFuncHandlerForInstance
-
Wrong snippet. It's late over here.
AddPythonFuncHandlerForInstance
Wrong snippet?
How do I get a function to fire when an already existing button is clicked?
There are no examples at hand of using AddPythonFuncHandlerForInstance(). I've only ever setup handlers for buttons when i've created them.
I've tried:
pSaffiQB.AddPythonMethodHandlerForInstance(App.ET_ST_BUTTON_CLICKED, __name__ + ".CombatEnded")and failed.
-
I thought it was obvious that you should just replace
RemoveHandlerForInstance
to
AddPythonFuncHandlerForInstance
in the sample I posted???
-
I thought it was obvious that you should just replace
RemoveHandlerForInstance
to
AddPythonFuncHandlerForInstance
in the sample I posted???
As dumb as I feel, it's still a no go :doh:
CombatEnded() is not called when the button is clicked.
def GetMenuButton(sMenuName, sButtonName):
pMenu = Lib.LibEngineering.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(pObject, pEvent):
print "COMBATENDED()"
pSaffiQB = GetMenuButton("Commander", "End Combat")
if pSaffiQB:
pSaffiQB.AddPythonFuncHandlerForInstance(App.ET_ST_BUTTON_CLICKED, __name__ + ".CombatEnded")
print "handler added""handler added" appears in the log.
After clicking "End Combat" "COMBATENDED()" isn't present in the log.
-
Why it's not working?
I'm not sure, maybe I missed something. I don't want to go deep into scripts we developed 7 years ago nor I have the time to ask Wowbagger.
What can you do?
You can always do the following:
def EndSim(pObject, pEvent):
pass
def init():
import QuickBattle.QuickBattle
App.g_kEventManager.AddBroadcastPythonFuncHandler(QuickBattle.QuickBattle.ET_END_SIMULATION, MissionLib.GetMission(), __name__ + ".EndSim")
Why we chose to use the following implementation instead of the one which I'm presenting now?
I cannot remember, it was 7 years ago. I'm pretty sure Wowbagger had a good reason.
Notes:
It is imperative that you study the QuickBattle.py, MissionLib.py and scripts located in the Bridge directory. Most of the answers are located there for you ;)
-
Why it's not working?
I'm not sure, maybe I missed something. I don't want to go deep into scripts we developed 7 years ago nor I have the time to ask Wowbagger.
What can you do?
You can always do the following:
def EndSim(pObject, pEvent):
pass
def init():
import QuickBattle.QuickBattle
App.g_kEventManager.AddBroadcastPythonFuncHandler(QuickBattle.QuickBattle.ET_END_SIMULATION, MissionLib.GetMission(), __name__ + ".EndSim")
Why we chose to use the following implementation instead of the one which I'm presenting now?
I cannot remember, it was 7 years ago. I'm pretty sure Wowbagger had a good reason.
Thanks, the function now fires when "End Combat" is clicked just as I wanted. Hopefully whatever the reason came up with 7 years ago for not using this method of implementation wasn't a very good one and I can happily transfer it from the test script to the secondary shield generators script :D
Notes:
It is imperative that you study the QuickBattle.py, MissionLib.py and scripts located in the Bridge directory. Most of the answers are located there for you ;)
Thanks for the tips Sov.
The BC API is so daunting to me not only because I don't fully understand the features and concepts (Object Oriented mostly) of the language it's all written in but mostly because the pre-made framework is so huge I get overloaded with what's in front of me.
Still, i'll try more not to bother you with every little thing of how to do X without going for a walk through the BC .py's :)
P.S: What happened to "USS Sovereign" :lostit:
-
P.S: What happened to "USS Sovereign"
I changed it to my real first name. It's also always fun to confuse people.
-
I changed it to my real first name. It's also always fun to confuse people.
the avatar mate :evil:
-
the avatar mate
You know... you could have at least pretended not to notice... you see... I'm a webmaster which is a rank equal to vice-admin on these forums... I'm just saying... :funny
Now on a serious note, I should change my avatar thanks for reminding me.
The BC API is so daunting to me not only because I don't fully understand the features and concepts (Object Oriented mostly) of the language it's all written in but mostly because the pre-made framework is so huge I get overloaded with what's in front of me.
In all honesty, we all learned it through trial an error, it's not a shame to ask. I'm just trying to point you in the right direction.
-
You know... you could have at least pretended not to notice... you see... I'm a webmaster which is a rank equal to vice-admin on these forums... I'm just saying... :funny
ooops :hide
Now on a serious note, I should change my avatar thanks for reminding me.
i know the feeling.... so do i