One of most used commands - sendsysmessage() is a pain in the ass to type in.
Any chance of adding a shorter version? For example SysMsg()

(I know I can make an include file with this, but it'd made my scripts messy in a way I don't like)

To be lazy.....

Sendsysmessage() says for itself.

Now I think SysMsg() is also too long.
It should be Msg()

There you go. Now all you need to do is include that with all of your scripts and you can use it as much as you want.

Has anyone tried something like....


uo.em No clue if that would work to be honest, never tried, and already mad at ecompile and adding new cmdline flags to it this weekend anyway. LOL

CWO wrote:

Code: Select all

function Msg(who, message, font := _DEFAULT_TEXT_FONT, color := _DEFAULT_TEXT_COLOR)
   SendSysMessage(who, message, font, color);
endfunction

There you go. Now all you need to do is include that with all of your scripts and you can use it as much as you want.

That's exactly what I had in mind while saying:

(I know I can make an include file with this, but it'd made my scripts messy in a way I don't like)

Anyway it's not a real problem. I just think that there's just no point for this command to be so large if it could be just Msg() and therefore I suggested this as PoL98 feature

Ability to define aliases to module functions sounds like a feature to me.

It could be as simple as aliases.em where each line represents an alias, like
It would be neat if parameter order (and default values) could also be modified alias-wise.

(I didn't give three thoughts to this structure, hopefully someone else can carry on from this before I have to)

Why not simplify alias assignments even more?
I'd imagine this would make parsing much easier. Couldn't eCompile read in the aliases.em file and use it for a substitution list when compiling?

This isn't a bad idea but I can see where confusion might reign if individuals can assign their own aliases. It would make script saring difficult if I use Msg for SendSysMessage and Joe Scripter uses SysM etc. Maybe for those long oft used statements the developers could create standard aliases. This way we'd all be on the same page when using them.

Or better yet...... why not something like Message(who, what, object, default stuff, default stuff, etc) that combines SendSysMessage() PrintTextAbove() etc? Since they all use the same packet

Just an added thought

I vote ALL functions be renamed.

A(...)
B(...)
C(...)

of course, then we limit ourselves to 26 core functions, which wouldn't be enough.
We would need to later move onto A1 A2 A3....

I vote there is not enough obfuscation though to justify the speed of copying and pasting the function name.
Lets change all the arguments to letters too

Example:
MoveObjectToLocation(object, x, y, z, realm_name, flags)
W(a, b, c, d, e, f);
MoveItemToContainer(item, container, x, y)
Q(a, b, c, d);


MuadDib will implement it.
Luth will do the documentation.
I will go take a nap, fly a little, then drink a beer.

That's a job for code completion/omni completion/intellisense, or whatever everybody likes calling it.

Austin: LMFAO!

Mel: Yeah, Nando and I have toyed with the idea of working on an IDE (which would include Auto Completion, etc), but, haven't gotten un-lazy enough to do it yet, hehe

Well, function aliases would surely be interesting. But then, we'd get Yukiko's problem of non-standard scripts. Besides, an include file does the job of function aliases, and tells everyone that a include is missing ("Oh, maybe this strange function A1(x,y,z) is in there!")

If we just changed SendSysMessage() to some other short function, we'd have the problem of breaking 99,99% of all the written scripts for POL. (The other 0,01% just use print(), hope we don't need to change it to prt() ;P)

Talking about long functions, anyone who has ever programmed in C# or Java knows how long it is to print on the console. I can't remember Java right now, but in C# you do something like: (which curiously is the same length as SendSysMessage)

Austin's word list for UltraEdit is a good one, which I hope someone can keep updating. There are also lot of nice IDEs for eScript which might have AutoCompletion too. (never tried any, sorry ).

(And I'm back from vacation, so I'm craving for bugs. Will you guys please get me them? )

Nando wrote:(And I'm back from vacation, so I'm craving for bugs. Will you guys please get me them? )

*sends Nando some crabs*

I once posed my idea for a new eCompile directive which, thankfully, still remains in the forums so I re-post it here. I think this will solve this whole alias issue.

From a post a long long time ago...

How many times have you written the ultimate script and found that it just didn't perform as you had intended or didn't compile at all?

I propose a new internal function I call, DWIM.
This is an acronym for DoWhatIMean. It would use advanced AI and heuristic algorithms to determine what the scripter is attempting to do. Using scripts written by the scripter and the vast amount of public domain scripts that would be stored in the core internal database the DWIM instruction would, using state of the art interpolation and extrapolation algorithms and extensive logic trees, analyze and perform the task that the scripter intended rather than what his/her script was written to do. At first it might not be able to adequately interpret the scripter's desires but it would learn over time as more scripts were written. Perhaps a training mode could be implemented much like voice recognition software is trained to turn the spoken word into text.

I feel implementing this feature would end a lot of the problems we now see in buggy horribly written scripts and would streamline coding in general. Most would admit there is a need for such a function and I for one would put it to good use.

This could be made more useful as a compiler directive or even an eCompile option. An entry in the eCompile.cfg file such as the following could be offered. If it is added to eCompile then ofcourse the heuristics would be incorporated in the eCompile exe. Now that I think about it that's probably better because it keeps the core executable small and compact.

Anyway, that's my proposal.

I welcome your comments.

Totally agreed. I'll place it into the todo list, and we should have it into POL 531.