More clear definition in ECompile when a non-ai based script tries to use the NPC.EM module. Maybe report the .src or .inc. Probably best for the .src, since so many src files can use a .inc anyway.

*winks*

Thanbks Maud!
You're the best!

Yeah, but there is a problem here.

It is probably, more than likely, IMPOSSIBLE to tell if the script is ai based or not without adding something for this.

That's what I was thinking; how would eCompile know that something is supposed to be an AI script or not? It strikes me that any means of finding that out could cause other, more difficult to track down errors, or give false results too often.

The only 'foolproof' way I could think of is scanning npcdesc.cfg files for script entries... but it seems highly problematic to make eCompile dependent on npcdesc.cfg - and what if you compile your scripts on a system that does not have the npcdesc?

Beyond that, what about AI scripts that are never meant to be the 'default' script for an NPC, but which are assigned by script? There is pretty much literally no way to tell the difference between such a script, and just some random script whose entry point ('program') happens to take a single parameter.

Don't think this can be done compile-time. You could look into making it say "Script xxx tried to use npc module, but is not being run on an NPC. Execution of script can not occur" in run-time.

but, is really something like that needed?

if it happens (using npc.em outside of an ai script) it's all scripter's fault, i think there are more important things *IMHO* to implement rather than a error-proof script system

i mean, in c++ noone blocks you from doing dirty things with pointers and such, you will just learn by yourself not to do

Aye with all. The real method would be to report the .ecl that is trying to do it, and leave it at that, if it gets done.

*points up* What he said, too!

I wasn't saying that eCompile should report this error.

All I said, in a different thread, was that I thought the error reported at runtime should be clearer.

Right now it says something about being unable to find module npc. Remember this is at runtime and there is already that error being generated.

That is a rather cryptic message don't you think?
I was thinking that the output line that contains the text "unable to find module npc" be changed to something like "Hey! I can't find module npc. You're probably loading the npc.em in a non-AI script."

bracco wrote:


Yes it is needed. Just because C++ allows crappy coding without providing good error support doesn't mean eScript or POL should. In MY humble opinion eScript is far easier to use than C and easier for new, non-programmers, to learn and use. If you, the developers, want to attact new users why not add the little touches that will make it shine above the competetion?

You can't tell me that changing the error text of that line is such a tremendous thing that it would cause development of the core to come to a halt. I assume the canned error messages are all contained in some array of strings in the source file(s). If so it should be a simple matter to edit that one.

And yes, for you "expert" scripters it probably is a trivial issue but for new scripters (and even some of us veterans) it wasn't clear why the error was being generated because the module was obviously there or else eCompile would not have compiled the script.

Let's remember that error messages should be there to point us toward what the problem is.

i never came accross this error, so i didn't know that it was a cryptic error message for it...

up for the clarification of the error!

anyway, i meant that if it required too much effort it wasn't really one of the top-priority things.

eScript is awesome and very easy imho, but on the downside of being that tolerant you can encounter very very badly coded scripts. just because someone is still learning it, it doesn't mean escript should accept every coding horror out there

Agreed.

But eScript, or the POL VM rather, could atleast give a clearer error message. All this one requires is a text edit of an already existing error message and then on the next recompile of the POL executable it will be less cryptic.

I understand ya can't sniff out every possible error and get an accurate, clear, flawless report on what the eror is. I've been programming since 1976 in one language or another and have seen many many strange error messages. You should see some of the ones the old UCSD Pascal system used to kick out and that was written as a teaching environment.