ace123 wrote:I don't think there is an easy way to delete messages when you leave, since it simply hides/shows when you leave or enter the rooms.
I noticed while testing (mostly because of errors, which prevented me from entering the concourse) that the scripts are preloaded when you land on a base. I was wondering if there was a mainbase.py or some such (besides the mere creation of the base), or perhaps I might work on one, that could be event triggered, when you leave/enter a room, or whether something like that might exist in the C++ code..
OT
I know the room is discovered/tested when you call the TextBox, so what I'm looking for would be perhaps an event generator that could trap when the room state changes) I recall some threads about work on more interactive bases. Was anything on the way in that regard? Anyone remember WC III and IV, might be interesting to have a system that allowed for instance, hallway encounters.
/OT
About having buttons, look at the fixer scripts.
Basically you will want to create an "OK" texture in a certain place. Then, create a Base.Python, which runs a python script when you click "OK". That python script will essentially delete the Textbox, the OK python script and the OK texture.
Was going to check that next. But the yes/no buttons are a bit plain, and doesn't fit the rest of the base screens very nicely. I was wondering if it would be possible to grab button textures or objects like are used on the Cargo Ship and Computer screens. In any case, I'll work on at least getting an ok button in to remove the dialog from the screen.
Also, don't do SetTextBoxText()... that will still slow it down since it has to draw it, Instead call that erase function above.
I don't see how erasing the TextBox would be any faster than Setting the Text to "" (and creating a new TextBox, if you happen to be diplaying another message). The major issue I see it that the TextBox needs to be erased (destructed)
eventually, or it is a memory leak.
If it's only going to be text overlayed with transparent background to show the room behind, I think the smart way to go would be to create an empty TextBox in the bar, the first time a text event takes place there, and then just reuse it until done (no more dialog with either the bartender or fixers), and destroy the TextBox on leaving the base.
In fact, one thing that has me a bit puzzled what why bartenders and fixers aren't related. Fixer ought to be a base class of bartender. the things that differentiate them, There is only ever one (but always one) bartender in every bar, instead of 0-2 as for fixers. The bartender doesn't offer missions with a yes/no proposal, but do still have messages to players. Certain aspects of bartenders could be extended over time, if they inherited from the fixer. Such as multiline messages, interactive response, for branching dialogues, campaign gossip would be more easily supported , and the possiblitly of missions could even be added eventually. Example:
Code: Select all
"I have this customer, who just loves this one very rare wine... it's only available on <planet> in <sector>. Trouble is, I'm running low and can't seem to get any shipments in with all the trouble that going on lately. I'd make it worth your while to go pick up a few cases and bring them back here. What do you say?"
Of course, I'm getting off-topic again... But I think the fixers and bartender scripts do need a bit of a rethink. For now, I'm just going to look into copying the button code and erasing function over from fixers, to make sure the TextBox gets destroyed. I'd also like to know whether anyone thinks the new text display is an improvement on the old, since it's not what was originally proposed. I too, though a real textbox with intregated buttons -- transluscent like on the base cargo and computer screens, but overlaying the bar -- would have been very cool.
I also recommend that you make a function that does Base.TextBox() so that can be use d eventually with fixers and other objects that need to talk.
That doesn't make much sense... Base.TextBox() already exists. it can be called from any of the bartender or fixer scripts. What would be the point of a python script that further encapsulated the the C++ Base.TextBox() that is provide through the python integration? What is needed in the long run, is to unite the various bartender scripts (and possibly integrate with the fixers module a bit more)... they are redundant and odd.
Bartenter-*.py all have the same function named in them, same format. That function calls on a function (in bartender.py) to retrieve a list of strings from a dictionary (also in bartender.py) then passes that info on (to yet another function in bartender.py). That is not an example of good modularization. It's redundancy. the only thing they do different is the list arguement, varies... that is easier to maintain if it were just an assigned variable modified and passed entirely within bartender.py.
Anyhow, I've taken on 3 projects now in the VS world.
1. The bartender/fixer code.
2. Code for editing csv.
3. A script for spam control on the forums.
I also want to look at the campaign writing (not code, not yet anyway).
I'll get the ok button in within the next 36 hours. After that, I'm going to wait for feedback from users, here in this thread.