by gamejester on Tue Dec 07, 2004 10:37 am Good thinking hjackson, very creative, might have to give it a wirl if Steven does not implement toggles soon.
show/hide - like you say, these buttons are still navigatable so therefore still perform actions.
Girder - no you cannot tell girder to perform a button click, it can only call events directly, so would be no good with your rotating category.
Here is my take on a toggle (which I also am waiting with baited breath for), hang on I go into one here!
Implement it via events and keep buttons generic. How this would work.
1. you need to be able to assign events to events
2. you need a new event command xlobby:button graphic
3. you need a new behaviour for an event - cycle, which remembers the last state of an event.
Example:
1. create your discrete events
lights \ lights on
|_x10:light ON
|_xlobby:button graphic = lightOn.png (this must be the name of a graphic that exists)
lights \ lights off
|_x10:light OFF
|_xlobby:button graphic = lightOff.png (this must be the name of a graphic that exists)
2. Create your toggle (cycle) event
x10 \ Lights (at this layer tick the new tickbox cycle - this could be next to the multithread tickbox which would need to be unticked)
|_xlobby:event = general\lights on (this should present a tree view of events to pick, but display in standard format as seen in the XML)
|_xlobby:event = general\lights off
3. assign the event x10 \ lights to your graphic button in the skin editor
advantages:
1. buttons can have as many sates as you want and cycle through them
2. buttons can toggle
3. buttons are still simple
4. works from remote (grider)
5. events are now cleaner, special events can be set up once and then chained into other events when needed (they do not have to cycle)
example - when I open an overlay I hide 6 labels on 1 of my screens, currently I have to assign the same 6 commands to 4 events, if I could chain events I would group them all in 1 event then assign that event to each of the other 4 events that used that 'hide all' function.
You may also be able to achieve simple animation, if xlobbys multithread and wait actions are not too processor intensive, by making the cycle event cycle until it reached an xlobby:stop event.
Example – an event calls itself and changes the graphics on a button with a 1 second wait between cycles.
Stop event - would have to be introduced in all regualr toggle buttons between actions, or it would just toggle for ever!
Disadvantages:
1. If used in-correctly it would have undesirable effects – good chance of getting stuck in an endless loop. But hey, as long as you have a good save before you mess around and know how to kill things, you will be OK.
|
Please don't force me to use, 