Print

[BenJeremy]

QUOTE (j0hnnyb0y84 @ Sep 19 2003, 01:32 AM)

I don't know if this has been requested or already has plans on being implemented, but adding left and right D-pad functionality would be useful IMO in the menu options.  I was working on a Dreamcast menu, but I was limited by this. Keep up the good work BJ!

"Horizontal menus" are done using Text Gadgets, instead of menu gadgets. There is a tag to tell MXM that the text block is being used as a menu, and to orient things left/right. The idea was to put conditional arrows on each side, as well. It's not smooth scrolling, which is much more complicated in a horizontal orientation.

[flattspott]

I was wondering BJ, is it possiblt to add two buttons to a single script section? For example in my EEPROM test script. Obviously backing up wouldn't really need it. But the restoring part could benefit from it. What I want to do is make it so the user (me I suppose) has to push something like white and black at the same time to be able to restore the EEPROM. The would also be ideal for future versions of Media X Menu when you get BIOS flashing working.

[flattspott]

And another thing, is there a limit that you know of with the ActionScripts. Cause I was dabbling with making a super installer with evox but gave up because it would not reconize any actions over 99. Yes this is a lot of actions but it needed them.  I think I was trying to use somewhere around 180 custom actions. Would that be an issue with MXM? In evox the Actions are numbered so I could have tested it out but using just and an [Action_100] to see that it wouldn't work.

In MXM though they go into the menu items they're for so they're not numbered, thus making it so I have to actually type out 100 plus actions to see if there's a limit.

[BenJeremy]

QUOTE (flattspott @ Sep 19 2003, 10:49 AM)

I was wondering BJ, is it possiblt to add two buttons to a single script section? For example in my EEPROM test script. Obviously backing up wouldn't really need it. But the restoring part could benefit from it. What I want to do is make it so the user (me I suppose) has to push something like white and black at the same time to be able to restore the EEPROM. The would also be ideal for future versions of Media X Menu when you get BIOS flashing working.

Well, I need to add functions for readign the state of the ports.... you could do your own input using that.

I might add a parameter to not wait on input (only do a query of the current state) and give you a variable or two showing what's pressed at the moment. That will give you complete access to all of the raw input.

I intend to have the Left and Right Triggers work as "shift" keys int he normal scheme, though. The IR remote cannot have "shift" keys, and the keyboard will have the usual suspects (ALT/CTRL/SHIFT).

I'm still working on the details, but the keys will be user configurable soon, for the regular operation (ActionScripts will be able to Translate what's input using a second step).

[BenJeremy]

QUOTE (flattspott @ Sep 19 2003, 11:12 AM)

And another thing, is there a limit that you know of with the ActionScripts. Cause I was dabbling with making a super installer with evox but gave up because it would not reconize any actions over 99. Yes this is a lot of actions but it needed them.  I think I was trying to use somewhere around 180 custom actions. Would that be an issue with MXM? In evox the Actions are numbered so I could have tested it out but using just and an [Action_100] to see that it wouldn't work. In MXM though they go into the menu items they're for so they're not numbered, thus making it so I have to actually type out 100 plus actions to see if there's a limit.

ActionScripts in MXM are not numbered. They are named (I'll give you a secret here, too... you can override internal ones by defining your own.), so the only limit is memory.

As you can see in my examples, CallScript can be very useful.

If somebody develops a nice installer script, I'll consider adding it to the internal routines.

My intention this weekend is to have MXM recognize that the hard drive is not formatted, and offer up to install from the disc it's running on. Each partition format should basically ask for confirmation, and that could be done as a generic script that accepts an argument for the drive. Similarly, the restoring of a drive's contents from a directory in the disc would also be part of the routine.

I think it would be cool to insert a DVD with MXM on it and have it know, without even selecting, that the system needs setup.

[flattspott]

You completly read my mind, I have been thinking the same thing for a while. You put the disc in a with a new or unmodded HD and you get a completly different menu structure than if the box was already modded. It would be a smart disc. So things like formating could be tucked away from the postmod menu after you use the disc the first time but you could still have a option to go back to the clean install menu to do all the dirty stuff.

QUOTE

back to the clean install menu to do all the dirty stuff.

No pun intended.


And let me get this strait wth the CallScript stuff. Basiccally with these I will be able to use ActionScripts for multiple menu items. Like if I had two Submenus for formating a Retail and an Upgrade HD. I could use one ActionScript to format them both identically (no f partition)even though they're called from 2 seperate menus.?

[BenJeremy]

QUOTE (flattspott @ Sep 19 2003, 11:37 AM)

You completly read my mind, I have been thinking the same thing for a while. You put the disc in a with a new or unmodded HD and you get a completly different menu structure than if the box was already modded. It would be a smart disc. So things like formating could be tucked away from the postmod menu after you use the disc the first time but you could still have a option to go back to the clean install menu to do all the dirty stuff. QUOTE back to the clean install menu to do all the dirty stuff. No pun intended. And let me get this strait wth the CallScript stuff. Basiccally with these I will be able to use ActionScripts for multiple menu items. Like if I had two Submenus for formating a Retail and an Upgrade HD. I could use one ActionScript to format them both identically (no f partition)even though they're called from 2 seperate menus.?

Yes.

MXM looks for a
For example, I internally defined "_DisplayMessageBox" - a script to do all the steps to display a simple message box and await input. Calling it is simple:

CODE

CallScript _DisplayMessageBox "The Prompt Message"

The ActionScript named "_DisplayMessageBox" is loaded in, and the variables %0% (set tot he name of the script) %1% (Set to the first argument) and %ArgCount% (Set to 1, in this case) are added to the local environment... which is NOT cleared when calling scripts... HOWEVER, the local environment is restored after the called script returns (Use the global environment to return values, until I create a better mechanism).

You could have a dozen menu items calling the same scripts... that's not a problem at all.

For example:

In MXM.xml:

CODE

: CallScript _DisplayMessageBox "Do you want to format %1%?$eol$Press "Y" to proceed" IF %_GP_Y% <> 1 goto CancelIt BeginDraw UseCurrent MessageBox "Formatting %1% Drive$eol$Please Wait" EndDraw Format %1% SET _LastError 0 CallScript _DisplayMessageBox "Done Formatting" GOTO Done :CancelIt SET _LastError 1 CallScript _DisplayMessageBox "Operation cancelled" :Done :

Then, in your menu item, you might have:

CODE

CallScript PromptFormat F: CallScript PromptFormat G:

[BenJeremy]

QUOTE (DBZRacer @ Sep 19 2003, 01:55 PM)

Great example BJ... I had a hell of a time last night trying to figure out how to use Callscript. This should make things a lot easier. My only request right now when you have time would be full examples like what you just did for all the new script commands.  I'm one of those guys who are more visual and reverse engineering code from examples works best for me...

Feel free to post "How do I..." messages here, and I'll try and give concrete examples. Perhaps somebody could begin documenting this into a Scripter's guide?

[BenJeremy]

Oh... and likewise, if you have an idea or have an actual script that would be handy for the "internal" scripts, feel free to post those as well, and I'll include them in MXM.

[flattspott]

Okay I am pretty clear about all this ActionScript stuff except for one thing. The part you posted %ArgCount%, %1% and %0%. I'm still not 100 percent sure about this part. Could you explain this to me in simple terms.

I have my thoughts of what they do based your post but I'm still a bit confused.
_________________

And could you give an example of how the color names are used.
Lastly, about the Internal Scripts portion. This would only be of use if say I made a really cool script then MXM would need to be recompiled with it, right? So for the average joe it isn't something to worry about?

[BenJeremy]

QUOTE (flattspott @ Sep 19 2003, 02:56 PM)

Okay I am pretty clear about all this ActionScript stuff except for one thing. The part you posted %ArgCount%, %1% and %0%. I'm still not 100 percent sure about this part. Could you explain this to me in simple terms. I have my thoughts of what they do based your post but I'm still a bit confused.

%ArgCount% %0% and %1% are environment variables... when you "CallScript" MXM makes a "backup" of the lcoal environment (there are two sets of veriables, local and global), then sets the variables abocve to the appropriate values before launching the called script.

That means that when your script executes, it will 'inherit' all of the local environment variables set by the parent script, and also know what arguments were passed on the script line. When the Called script exits, the LOCAL environment is restored from the copy we made before launching the called script, which means any changes to the LOCAL variables are lost.

Global environment variables are any variable that is proceeded by an underscore "_" character... %_GP_A% is an example - all scripts see this regardless. You could return a value from your script by using %_Return% for example.

All variables do a simple text substitution, so:

SET TestVar "Some Value"

Makes %TestVar% equal to "Some Value"...

and

SET TestVar "Some %TestVar% Value"

makes %TestVar% equal to "Some Some Value Value"

Basically, they can be substituted just about anywhere. Arguments and special tokens can be quoted or unquoted - the parser doesn't care much, except it expects spaces to separate tokens, so if text requires a space, QUOTE IT. If you need to display a percent sign "%", just double it up: "%%" Same goes for the dollar sign "$" - which is used for GadgetString Variables and specials, like $eol$ (End of line)

[BenJeremy]

QUOTE (flattspott @ Sep 19 2003, 02:56 PM)

And could you give an example of how the color names are used.

Color Names:

Currently, I only support a few names, as defined. Text and boxes default to the system colors for message boxes, if they are not specified.

CODE

: BeginDraw UseCurrent Box 100 100 150 100 DarkRed White EndDraw Input :

This draws a dark red box, bordered by a white line, at X,Y=100,100 and the box is 150 pixels wide, by 100 high (scaled as if in a  640x480 screen)

In the near future (tonight, maybe?) I'll enhance the colors to accept numbers, both decimal and hex so you can do raw ARGB as well.

[flattspott]

That's what I thought.

[BenJeremy]

QUOTE (flattspott @ Sep 19 2003, 02:56 PM)

Lastly, about the Internal Scripts portion. This would only be of use if say I made a really cool script then MXM would need to be recompiled with it, right? So for the average joe it isn't something to worry about?

Actually, there is an "initial" list built from the internal.xml file, that is actually included in the MXM default.xbe file, but if you define scripts in the MXM.xml file, you can add to the internally available scripts (or even override already defined ones compiled in).

So yes, the "average joe" could screw things up. Perhaps I'll come up with something there, but the idea is to be able to expand it downt he road, as you guys think of new things to do.

[flattspott]

On the Color stuff, can we not put the size stuff? Like so,

BeginDraw UseCurrent
Box DarkRed White
EndDraw
Input

Cause how am I spose to know how big the Box needs to be? It seems to me that MXM does a good enough job by itself sizing the boxes to the text.