My apollogies, I meant SRC as in MXM source.

And POW as in Power is I suspect.

Well, looking at the code, it shouldn't be too hard to add it into ActionScript.

Keep in mind, I reserved '#' as the precursor to numeric functions - I'll figure out support for that and variables.

I am also considering adding "DECLARE" to set variables to be numeric or string based, to hopefully speed things up. If the expressions work out, I'll look into revamping the variable system to handle multiple (simple) types (probably int, float and string)

OK, geniusalz, don't mess with it anymore... I'm incorporating it into ActionScript, as stated by the readme.

Thanks for the framework. I'm adding # as the function precursor, as well as variable and "specials" support.

When I'm done, I'll update the WIP and you can take a gander at the changes I've made.

Ok BJ how about these?

SetFunc <Variable> ImageHeight <ImageFile>
SetFunc <Variable> ImageWidth <ImageFile>

Nah.... for expressions, you use the variables straight.... no % conversions happen.

I've already coded most of it up, and added a virtual interface for grabbing specials and variables from the ActionScript object, via a passed in pointer to the evaluation routine.


Today was a bit hectic, so expect an update maybe thursday with expressions.

But what about eample #4 from the previous post?

SET var4 (%var(%var1%+1)%+2)

Without % signs becomes:

SET var4 (var(var1+1)+2)

Which turns out to be

SET var4 (var2+2)

So won't removing % signs complicate the parser? i.e. "var" cannot go on the operands stack, and its value cannot be resolved, until the whole variable name is calculated, which is "var2".

Edit: I was thinking it could be handled this way (using {} , not % signs):
The calculator throws anything it finds between curly brackets back at the actionscript object (GetEnvValue, I think), and that function would throw anything it finds between round brackets at the calculator. This way, recursive situations like the one above could be handled.

Yes, this becomes:

SET var4 (var{(var1+1)}+2)

I was thinking that I'd evaluate any thing starting with ( as an expression, since I can easily parse to the matching parens. I should be able to fit in the expression evaluation when determine the "true" variable name. The Parens are important, because they, in effect, force numeric evaluation. If var1 was merely a non-numeric string (which is also quite legal in ActionScript), the above evaluates to 1 - but this is also legal:

SET varX 20
SET var1 X
SET var4 (var{var1}+2)

Catch my drift here? This is the nature of the "dynamic" variable naming. It's the thing that's hosed up my ability to optomise the parser, since I can't break this capability without breaking a lot of scripts.

Another thought on dynamic variable naming is the ability to use makeshift pointers:

SET var1 test
SET ptr1 var1

SET somevar %{ptr1}%

Not really relevent to the discussion here, but I wanted to throw it in anyway.

Sounds cool enough

Any updates?

Hopefully today.... this week just turned out too hectic, but the kids just got picked up, and the Wife is out for most of the day.

No you can put out out a new WIP. I'm gonna be gonne for a week in San Francisco.

Okay maybe just one. I don't want to have to play catch up with all you guys.

OK, I'm almost ready to do the release... give me a few to get it together.

Just tried this:

MsgBox "Expressions: I=%(I-1)% (%{Something}{(I-1)}%)"

and it evaluated correctly from my test script.



Took a little work, though... the changes I had to propogate through my variable handling code made it feel like I was working without a net.

You'll notice that the expressions are used where variable names are used. I hope it didn't break anything, but some of the test seem to run OK.

P.S. flattspott - could you make absolutely sure the latest "Concentration" is posted? I keep forgetting my version takes too long counting up the final score when I'm testing. Thanks!

OK, WIP Build 1214 is now up.

This one also has plugin support for "popup" type modules. It doesn't include some of the fancier things I have planned, but it's a start.

Example (in the binaries archive):

Cool. Does the interageted XML script stuff work in the XSM's yet? Or is that just for Dilaogs XML's?

Alright then I'll just have to wait I suppose. Downloaded the new WIP now, then I'm gonna test my Concentration version, make sure it works then I'll post it.

I can't seem to get the XSM to load or even where to find it.

You make a "Plugins" directory under MXM's execution directory. Put the XSM in there, and it will "install" the file to a repository directory in MXM's User folder (UDATA).

If you have Action Menu's turned on in your configuration, it should show up in that menu.

Duh, I figure it just went in the root of MXM since that's the way it came.

PS, I just checked the concentration I have and now it's all jacked up. Probably something I did. It takes so long for me and it goes negative now too for some odd reason. hpf. Wonder what I did this time.

first time for me

Well it still didn't show up. I have the Action Menu turned on, Reset the menu cache too. The files did get installed to E:\UDATA though

: EDIT:

I just reset the cache again and now it works.

Well, the first time you run it, it installs it... then the SECOND time you run it, it's installed, so it loads the info in.

The Plugins won't be tied to the cached menu. Action Menus are built dynamically each time.

cool. im still trying to grasp all of it, but i think im figuring it all out...although a bit slow.

I did however find a bug in the latest WIP. i cant figure out how to type it in the forums..so i just posted a screenshot of it.

Bug screenshots here

Nice one koldfuzion

WOW.... that's a sweet "bug"

Yes, the "Action Menu" is built every time you boot.

I may add a command to force plugin installation, too, so modules can be downloaded directly into the plugins directory and then "installed" so they are available on the next reboot (if not "live")

Yeah, I hate reboots, so building through a menu item called "search for plugins" or automatically while accessing the action menu will be great.

Well, I will be looking at ways of making the menu far more "dynamic" so items can be added.

i know you dont have it all ironed out yet.. just a question regarding the white paper and script categorization.

Categories: (red is not an included category in the white paper.. just my opinion..more on this further down).
1. Utilities (xml) - File Managers, skin downloaders, newsfeed switchers etc.
2. Overrides (xml) - Replace default system functions. Formatting hard drive, Menu Password script, etc.
3. Context (xml) - Selectable only in certain areas. When a game, skin, script is selected in the menu.
3. Games (xml) - in-dash games available.

Classes:
1. Event (xml) - Triggered by a specific event. See below for events available.
2. Context (xml) - Acts on selected menu item.
3. Popup (xml) - These are "standalone" scripts, callable from system menu or regular menu.
4. Skin-specific - default class of scripts included in a skin definition file. Used to perform actions on render targets to be used by the skin.
5. System (xml) - Any misc. scripts that might be called by other scripts.


question I have is, does there need to be a Context category AND class?

on the Game category. I think this might be great for when you get around to putting in the "stop/unload videos" switch. unloading videos would free up more resources and maybe improve execution of more complex game scripts. I dunno, just a thought.


here is aSample XML Download file for the zsm's. Trying to figure out the internet side of this from the result back..before i get too far into it. There are more sample xml's on the site , the (XML) links. Anyone have a beef with the setup? if not.. this will be the format i use. (will put the script version in the xml also.)

I also notice the repository has the GUID in all caps... will this be case sensitive? if so i will update the guid make on mediaxmenu.com and be sure to force it in the code on the website also.

OK, that's a bit to absorb.... the categories was intended more for a descriptive element, rather than an operational element.

The idea was that once a module is "installed" into it's repository path, the user could enable/disable using a dialog all modules in the system. You may wish to filter the selections by category, though.

So the class is more operational - it tells MXM where the script will operate out from. This will be a specific and very defined set of values, whereas with categories, the module designer can declare their own categories... as many as they want (though that would defeat the purpose as a filter, though, if there are too many categories)


As for GUIDs, I'll have to make sure I lower case them when setting them in the repository. They shouldn't be case sensitive, but to be honest, they are merely unique strings... I chose the GUID format because there are ready to use generators available, even on the net. I don't make an effort to encode/decode them in any way.

gotcha, make up our own way to list the scripts on the website because it has nothing to do with the how mxm handles them(depends on the author and script settings) nor does specifying the class on the website provide any benefit.

So instead of all the mumbo-jumbo on the website now.. we can just have utilites, games, and pr0n downloaders I was looking for categories and used yours so that a "complete" xml file doesnt have to be downloaded and only the xml for the interested category would be needed.

Well, that's why I'll make the GUID lower case (when storing to the repository or doing searches), so internally, all my internal searches will be case insensitive.

OK.... tomorrow or Tuesday, I'll update the WIP.

I've added a couple of nice things (have to test them):

1. XML handle "xsmnode" contains the XML from your XSM module, if it exists.

2. GUIDs forced to lower case.

3. <Subscripts> node, containing <script name="somename"> elements with scripts you can call from the main script of the xsm module. They get the xsmmodule XML handle (from which you can build dialogs, of course and use other data).

I'll try and add loading into the context menu before I release the next WIP.

P.S. The Pistons just went up 3-1 agains the Lakers I doubt they'll get respect until they put the Championship away in Game 5.

OK, the above-mentioned WIP is now posted.... 1217.

No context support yet. Turned out to be more than a little bit of coding.

Still, the SubScript support and "xsmnode" access to the XML should allow you guys to start kicking ass on it.

Sweet!

But now I'll have to polish up tetris YET again

Anybody build up a serious module or two yet? I'm curious about feedback...

Still working on the gamesave manager... Any news about unicode? I managed to write a little script that converts unicode to normal text, but it runs quite slow.

Edit: Forgot to add that I also added a sort, but that makes the load even longer. I'm still thinking of an efficient way of sorting it.

Edit again: *vent* ZSM'ed up minesweeper, then found out I have an older ver. Downloading it on crappy dialup now. Hopefully it won't disconnect before download is complete.

I tried out minesweeper with the plugin stuff. It shows up in the action menu, but doesn't do anything when I press A on it. Probably something stupid on my part, but try it anyway.

http://mxm.brokensite.org/Minesweeper.zsm