Ecompile report better for npc.em

[MuadDib]

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.

[Yukiko]

*winks*

Thanbks Maud!
You're the best!

[MuadDib]

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.

[Marilla]

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.

[Austin]

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.

[Bracco]

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

[MuadDib]

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.

[Marilla]

[Yukiko]

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:

[Bracco]

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

[Yukiko]

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.