Magic!

[giwo]

As of the latest UOX3 release (found in the General Forum) I have written a basic script to begin putting magic into the JS.

By-and-large this script is so far a clone of how UOX handles magic, however there are some issues that need to be taken care of before the entire system is ported out.

Firstly, Known issues:

Currently there is no way to have a character attack another in JS.

There are no LoS checks avaiable in the JS engine.

Secondly, Possible Issues:

As my knowledge of the JS engine is still limited, I do not know of any way to have a global-type script that other scripts can call (to centralize common code).
That being the case, we would have to re-write hundreds of duplicate lines of code for every single spell, this to me, is quite silly, as the main handling should be in one place (while still in JS) and the specific spells seperate.

Lastly, User Input:

I, myself, have not played UO for years now, not even on an unofficial (emulator) server. Thus I have NO clue what the state of the spells are, what needs to be added/removed/adjusted. This is where the users come in, before we begin fully implementing the new spells system, lets get it working right. We need to know what is missing, what shouldn't behave as it does, and what works just as it should.

Of course anyone who wants to have a peek at clumsy.js and begin tooling around with it, you are more than welcome to do so, the entire purpose of the JS engine is to put the power into the users hands.

[Galbuu]

This is where the users come in

What users?

[giwo]

While the numbers are few, there are still people around who either use or contribute to the UOX project....

[punt]

Of course anyone who wants to have a peek at clumsy.js and begin tooling around with it, you are more than welcome to do so, the entire purpose of the JS engine is to put the power into the users hands.

If this is truely the case, then why not understand what the users want, and see how to accomplish it? The "limits" of the JS engine are exactly what I described in my earlier post, that need to be exposed, understood, analysised as a whole, and then decided how to accomplish them.
That you "attack" them piecemeal, as they come, versus a stand back and analysis of what is required in context of ALL systems.
You earlier stated in another posts that you could never enision accounts being in the JS. Why not? Power in the user hands and all that. This would seem to be the most "user" modified and desirable customized portion of the entire system (to fit into their shard setup). And accounts are not real time (other then login, which is in a seperate thread anyway).

Conceptually what UOX wants to accomplish is a scripting server. To do that , it would seem to need to analysis what services it wants to be in JS, what services the JS would need (los for example?), and then strip the code down to start that migration. The continued piecemeal, although understandable by those doing it, will not be so understandable to others who pick it up. And you will repeat the .7x experience, of users saying the code is too fragmented. The amount of effort described here, isn't as large as it may seem, as the JS code, would need to be done anyway, to meet the desired stated objectives.

[giwo]

Happily, this post is to discuss the current state of the magic system, what needs to be done, and how to go about new changes, not the account system, the state of UOX, or the purpose of UOX and its future, that is for another post.

Lets keep this one to its topic lest people forget that the point was to create a better working magic system that is entirely customizable.

[punt]

Happily, this post is to discuss the current state of the magic system, what needs to be done, and how to go about new changes, not the account system, the state of UOX, or the purpose of UOX and its future, that is for another post.

Lets keep this one to its topic lest people forget that the point was to create a better working magic system that is entirely customizable.

I would offer, your own statement: "what needs to be done, and how to go about new changes" makes my response applicable, for it states how one may go about approaching the JS , including the users. It may not have been the interperation you expected, or desired, but it is just as valid, given you provided those words. You yourself stated how to do somethign for the magic system, without repeating a lot of code. And to do that, one could easily stated, that considering other factors to be on topic. Otherwise, what context should be used. How to repeast common code aspects, only in the context of magic? And as you stated los, what services should be allowed to be discussed?

Your posts in total, state:

Firstly, Known issues:

Currently there is no way to have a character attack another in JS.

There are no LoS checks avaiable in the JS engine.

Secondly, Possible Issues:

As my knowledge of the JS engine is still limited, I do not know of any way to have a global-type script that other scripts can call (to centralize common code).
That being the case, we would have to re-write hundreds of duplicate lines of code for every single spell, this to me, is quite silly, as the main handling should be in one place (while still in JS) and the specific spells seperate.

So, that is not open for discussion? It was in this thread, so how is it off topic? Same with the statement about putting the "power in the user hands", which is what the accounts was in reference to (again, in this thread, provided by yourself). I don't understand how one can state, that discussion of those two items, both in the orignal post of this thread by yourself, is off topic (again, may be off what you WANTED the discussion to go, that is different). Also note that the comment of "what users" was not flagged off-topic. So what is the critiera.

[Galbuu]

Come on punt, stop using big words.

[Xuri]

Galbuu, don't start anything.

Giwo: It's possible to call other scripts' functions using TriggerEvent - but not sure how to return (or bring) values from one script to another, other than providing variables as TriggerEvent arguments and/or temporarily saving values in custom tags or socket.xText/etc.

[giwo]

Punt: I'll leave discussion on the JS engine and philosophies on how to proceed with it to another post.

Xuri: That may work... any settings we set in magic already have specific places on a character or socket to store them....

I just want to centralize the common code

[punt]

Punt: I'll leave discussion on the JS engine and philosophies on how to proceed with it to another post.

It is only philosophical if one choose to not apply it! Otherwise it is rather applicable.

Xuri: That may work... any settings we set in magic already have specific places on a character or socket to store them....

I just want to centralize the common code

Ok, with the stated objective of centrilize common code, and the stated original proble with common code being the ability to return values back.

If we assume that one would want to apply this capability beyond magic for a moment (moving it out of the philosoical world to applied), then what Xuri suggest may be limiting to specific instances.

Another option is to have the calling method create an object (generic object), and pass it into the "central method". The central method can set propertieis on it for the values desired (one could also just have the called method return this instead of passing it in). This would allow "multple values" be returned in a generic sense, that should be applicable to any system, not just magic.

[dracuskaos]

I moved my Chivalry JS to this other thread, Although it's magic it didn't fit in the conversation.

viewtopic.php?t=1655&highlight=chivalry