GUIs and some other questions

[Nighthawk]

two questions, maybe a bit obvious at this point in BC's life, but I never researched much in this field:

1) I know the hardpoints are recompiled (in the case of an on-the-fly change during a game) when a quickbattle match is restarted, but does it work this way for normal scripts? for what I know, if I change something in another script, I have to restart BC to recompile it, otherwise, it will still use the old .pyc, and if I delete it so the game has to create a new one, it will return "no module named xxx....".
this is more for testing purposes so if I code something and have to edit it, I don't have to restart the whole game.

and 2) is there a way to halt the game between the click on "Start" on the QB menu and the actual loading of set and ships? that's to throw another dialog in the middle, for a small configuration.
in other words, can I listen to a specific event?

[MLeo]

You can listen to specific events, but there exists none between the Start (except the actual button click) and the "mission" (QB is a mission/campaign).
But what type of config can't you do in the main menu/mutators?

Once a module is loaded Python won't look at it again untill requested, ie. a reload. Hardpoints can be safely reloaded (BC does this as well), but not all scripts can be (safely that is), infact, nearly no script can be safely reloaded. Especially not scripts that override stuff.

You aren't supposed to delete the py file.
Most of the time you don't need to delete the old pyc files.

My general work flow is:
Do a change, start BC, verify it (quickly) if it works, if it does, try to break it. If it doesn't (or I break it), do a bit of explorative work in the console (ie. find the fix). Exit BC, do the changes, etc, etc...

No need to delete files.

[Nighthawk]

You can listen to specific events, but there exists none between the Start (except the actual button click) and the "mission" (QB is a mission/campaign).
But what type of config can't you do in the main menu/mutators?

basically, I want to put a middle step between loading ships and playing, so I can adjust settings like position and AI, something that's not too elaborate, but will add a bit on the tactical side. I know that's done with QBGame, but that's not what I aim to.
I'll explain more when I get the basic GUI for it done, it shouldn't be too hard.

Once a module is loaded Python won't look at it again untill requested, ie. a reload. Hardpoints can be safely reloaded (BC does this as well), but not all scripts can be (safely that is), infact, nearly no script can be safely reloaded. Especially not scripts that override stuff.

that's what I thought.
but, if I make the scripts to be QBA-loaded, I could simply restart the mission.

My general work flow is:
Do a change, start BC, verify it (quickly) if it works, if it does, try to break it. If it doesn't (or I break it), do a bit of explorative work in the console (ie. find the fix). Exit BC, do the changes, etc, etc...

mine too, but sometimes it gets too tedious :S

[MLeo]

Those scripts are specially scripted to be able to do that.

Figure out what the eventtype/function combo is that gets triggered by QB when you press Start Simulation.
Have it redirect to a function in a different module (put it in scripts for now). You may only change things in this module, infact, you may not use any global references (constants that are only used in the same module are fine, including import statements). No GUI, characters, back-up function references.

Now you can call "reload" on that function, and the next time you click on Start Simulation that (new) function is called. Since BC will first load the (reloaded) module, then get the function, and then call it. So if you change it (either through reload or through directly setting it) then it will be called by BC.


I would suggest having another script do the resetting of the eventtype/function combo (RemovePythonHandlerForInstance and AddPythonFunctionHandlerForInstance if memory serves me right). Say an autoload script (that will be called only once).
You may need to overwrite a function inside QB (the function that sets up the eventhandlers) but you will need to have your function call that old function first, before doing it's thing.

[Nighthawk]

already on something, heading that way.
I used LibEngineering for the moment, to make a button, to load the files manually. I'll work on the listeners later, but I think I got the event I was looking for.

EDIT: Got it. it works outside QBAutostart, by mutator. I took some structures from DS9FX, but just a few lines

[Nighthawk]

bump for some other question
I built a quick "close window" code so that I can toggle it on and off. looking at QuickBattle.py, I saw it doesn't actually trigger a function when the button is pressed (the "Close" and "Start" buttons on the config panel), but instead sets a listener to a custom event, and then sets the button to fire that event...
not used to this workflow, what's the difference between it and actually calling the function directly?

[MLeo]

It's the BC way (to do this).
Ambiguity (a library from QBReplacement, and later inspired LibEngineering) has hidden this workflow.

One thing you must know, is that the functions always expect 2 arguments, the object that had the handler attached, and the event itself.
These must be valid objects, because most functions take a lot of info out of them. Or atleast call pObject.CallNextHandler(pEvent)

But I'm unsure with what you mean by "calling the function directly" in this context. From the handler function for your new button?

[Nighthawk]

calling it like:

Code: [Select]

def init():
   Lib.LibEngineering.CreateMenuButton("xxxxxxxxx", "xxxxxxxxx", __name__ + ".function")

def function():
   print "called by button"

either that, or ["path.function"], or [variable + ".function"]

[MLeo]

Well, that function hides the creation of an EventType, the creation of an helper function/handler, that, when triggered, will call your function.

"Pure" handler functions have this form:

def handler(pObject, pEvent):
 #Code, mostlikely using pObject and pEvent

[Nighthawk]

ok, I think I got the logic of it.
now... I could make the window as the QuickBattle window, static, holds sub-items, opens and closes when requested and seems to look good. the problem is, it doesn't get unloaded/finished/terminated/destroyed/closed when I click on "Abort Mission".
I couldn't find any events that fire when you end the game. all I could find is the event that ends the fight, if there's one in progress, but not the one (if there IS one) that ends the QB mode.

here's a preview. still lacking some buttons, but you can get the idea.....

[MLeo]

Have you tried hooking into ET_MAIN_MENU_EXIT_GAME_BUTTON (MainMenu.mainmenu) and the App.TopWindow_GetTopWindow().FindMainWindow(App.MWT_OPTIONS) as the target?

[Nighthawk]

yes, but if I listened to that event, it will only close the window when I click on "Quit Game", not in "Abort Mission".
I can also set the options window to be unavailable when you open the TFC window. it's done in quickbattle.py (I think), but it's commented out.

[MLeo]

yes, but if I listened to that event, it will only close the window when I click on "Quit Game", not in "Abort Mission".
I can also set the options window to be unavailable when you open the TFC window. it's done in quickbattle.py (I think), but it's commented out.

Attach your window to the XO screen, then it won't be visible whenever the XO screen isn't visible, and therefor, you only need to handle the case where someone actively closes the window.

[Nighthawk]

I'll put that on a second plane for now....

the next urgent thing would be to fill the fleet list with the friendly group.
I've been reading some of the QB lines, and I think this is what I need...

Code: [Select]

ship = Foundation.shipList[g_iSelectedShipType]
lShipData = [ship, g_iSelectedAILevel, ship.StrFriendlyDestroyed(), ship.StrFriendlyAI(), 'Friendly']
g_kFriendList.append(lShipData)
I need to replace that "g_iSelectedShipType" with something, that points to the friendly group I'll use. I think I can use pMission.GetFriendlyGroup(), but how do I select individual ships inside it? by name or by index number?

EDIT: after that code, I think it comes the code to actually make the buttons, but if I read it well, it adds something to the list, then kills the menu, and then rebuilds it?

[MLeo]

The number comes from the buttons (which is supplied by, for instance, SubMenu, which you can also use through FoundationMenu, which I would really recommend).

As you saw, QB also keeps track of the ships it's about to load (the g_kFriendList and g_kEnemyList) so you can use that. But the actual positioning happens elsewhere (in ChooseNewLocation I believe). So you have to override that as well, or patch into the GenerateShips as well.

[Nighthawk]

yes, I plan to punch trough GenerateShips() somehow.... or something before that, whatever it is that runs after ET_START_SIMULATION

I'll need an OverrideDef somewhere, but that's not urgent now. if I can make it run stable, and outside QBAutostart or QuickBattle.py, it will run when they're merged.

I've been discussing some parts with USS Frontier and Sovvy, in BCS
http://bcs-tng.com/forums/index.php?topic=2647

[MLeo]

From what I've read here and there, my best suggestion for you would be to "break in" at the moment the player clicks Start Simulation, and override that event for yourself. And attach your GUI to the same window your predecessor took (XO window), with that last bit, you don't even need to know about ET_EXIT_GAME. And yes, loads of objects can use (as reciever and sender) events.

[Nighthawk]

so, overriding not the function, but the calling to it.
it's ET_START_QUICKBATTLE what fires after the button is pressed, but that just closes the window, and fires ET_START_SIMULATION. that one changes the viewscreen and plays the loading sequence, and calls StartSimulationAction(). that one is the one that preloads ships. after that, it calls StartSimulation2().
and THAT is where everything is created  :?
so basically, there is where QB begins.

I'm used to that work flow, somehow, (worked with PLCs and relays for a time  ) but I find it too messy for this kind of work.

[MLeo]

Well, first you remove the old handler, then add yours into it's place, when yours is called you do your thing (ie. the window) when the user closes that you do the work of the original and call the original handler that was supposed to be called.

So, your function closes the window, shows your new window, and after that's done call ET_START_SIMULATION

It's either that, or something even more messier, unelegant, and illogical thing to do that is literally breaking into that process, instead of just "wiggling" (sp) into it, and just add another step.

[Nighthawk]

the fleet menu, already done and working, and the formations menu, still on development