UOX3.org

With its latest release on the CVS (and I'm sure there's an exe floating around somewhere), UOX now supports scriptable commands.

What does this mean? Finally one can fully customize and create their own commands, allowing for vastly improved flexibility on their UOX shard. However, we are lacking one thing currently...

The commands!

Currently 99.9% of all UOX commands are still right in the source! Xuri has done some excellent work creating commands, but more is needed. As commands are written in JavaScript we can sucessfully add them to the official releases and remove them once-and-for-all from the source. While this project would be daunting to one or two people, were there several to step up and take on the task of writing JS commands to take the place of those already in place, it could be done in no time!

Any assistance is appreciated, and anyone with questions feel free to contact EviLDeD, Xuri, or myself with questions about it.

Thanks

A few deterrents when it comes to moving commands over to JScript:

1) Inability to keep variables/Character/Item/Socket-objects (or whatever one wishes to call them) from one function to another unless the new function happens to have the same arguments in it's header.

The only way currently to do this is to temporarily save the variables and/or serials of items/chars as custom tags on the item or character that executes the Jscript, then load them again in the next function. This is very cumbersome, and it's not always possible to remove those custom tags from the characters. If, for instance, you have a command which requires a targeting cursor, and you need to move a variable/object from the initial function to the "oncallback" function - you have to save it as a custom tag on the character before calling the target cursor. But if the user then cancels the target cursor (pressing escape, f.instance) - the script ends and one has no chance to remove the custom tag from the character.

If it somehow were possible to provide (even a limited amount of) custom arguments for the js functions, that would make things a whole lot easier. Or find another way of accomplishing this.

2) Not all item/character properties are currently editable in the JS Engine. Most are, but some are missing. Can't specify which are/aren't right now, but a comparison between the character tags and properties one can set/get in JS engine will show that not all are there.

I will have a look at some possibilities for passing params around (without forcing them to be formal parameters). I'm supposing that JS doesn't support functionality for using the temporary containers we attach to sockets? (As that is how we do most of our data passing in the command & target functions).

Edit:

As for the Item/Character properties, quite likely they are not all in there. I am working on breaking up CItem a bit into smaller more manageable classes, after which I will ensure that all our props are attached to objects in JS.

Well, I do agree that there was quite a bit that needed to be added to move the bulk of commands out to JS.

Happily with almost 70 commands out now, the JS Engine is much more full-featured.

As for permanent variables, when all else fails (IE I can't attach it to a socket or whatnot), just declare a global variable in the script. It remains until the script is terminated, and thus can be set in one function, have code like a targeting cursor go on, and be viable in the next function.

Hm I was of the impression that global variables would be global across script instances, or something?

I'm pretty sure it will only be inside that specific script.

Now it will remain, IE when you haven't thought of using the 'blah command for 10 days that your server has been running, it will still have that global var active and set from when you ran it 10 days ago (unless you reload the JS engine ).

However I highly doubt it would remain constant in another script.

Try it, though.

add myVar = "12345" to one script then open another script and put socket.SysMessage( myVar );

see what it spits out

No, I meant - it would stay global between two uses of the same script by two different players =P

Well, any instance of that script, most likely it will.

However if you're doing something like a targeting event, just make sure you reset to base values (or at least modify those vars) every time before you call a targeting cursor that allows onCallback to be run.

It's certainly not a perfect fix, but socket.tempint, socket.xtext (you could make a string and split it up in the next func), and socket.clickx,y,z should also allow you much flexibility in storing temporary vars.

How does socket.clickx,y,z work? Same way as .xtext and .tempint?

clickX and clickY are SI16's, clickZ is a SI08

socket.clickX = -1;

etc