DebugLevel in pol.cfg

[OldnGrey]

In an attempt to reduce debug.log to manageable levels (it grew to 1.3GB at DebugLevel=6 without me noticing.) I tried setting DebugLevel=1

However, this still produces a 10MB startup file, mainly when my npcs try to equip stuff but in lots of other places too.

Ok, I can see those smug scripters telling me my scripts are messy, but now it's time to tell me how, hopefully.

I am slightly amazed at this one:

Config File pkg/world/weather/itemdesc.cfg does not exist.

I am amazed because I have no intention of ever having an itemdesc file there.


But here's one I should be able to fix, but don't know how:

Script Error in 'pkg/combat/item_equip.ecl' PC=2656:
Call to function GetAttributeBaseValue:
Parameter 1: Expected datatype String, got datatype Integer

This one just confuses me so far.
Yes, GetAttributeBaseValue is SUPPOSED to return an integer, so why am I expecting it to be a string? Of course that's in the ecl and it's buried somewhere in all my includes, but I was hoping for some more general information on someone who has conquered this....

[CWO]

Its not saying GetAttributeBaseValue is returning a string, its saying its GETTING an integer (possibly a SkillID?) instead of a string skill name for its second parameter (its 0 based so 1 is actually the second param). Generate listings to find out where its talking about.

[OldnGrey]

Thanks, maybe that makes sense at that.... at least it gives me something to hunt down.

[OldnGrey]

Okay, bear with me on this one.... it just might help someone else too.
We are looking at Program Counter 2656 in the item_equip.ecl file.
Compile from that directory with ecompile item_equip.src -l -f
Here are the relevant areas around the code in the .lst file:

d:/pol/scripts/include/attributes.inc, Line 641
function GetBaseSkillBaseValue(character, skillid)
2649: pop param 'skillid'
2650: pop param 'character'
return GetAttributeBaseValue(character, GetAttributeIdBySkillId(skillid));
2651: local #1
2652: local #0
2653: makelocal
2654: jmp userfunc @2471
2655: Func(2,2): GetAttributeBaseValue
2656: return

Here is the same function in escript in my attributes.inc

function GetBaseSkillBaseValue(character, skillid)
return GetAttributeBaseValue(character, GetAttributeIdBySkillId(skillid));
endfunction

That looks like it came straight from the 094 distro! Can't see the problem just yet.

[CWO]

hmm... thats a wierd one because it would return either error or a string... It does initialize an error at the end + errortext if the skillid doesnt exist right?

var ret := error;
ret.+errortext := "No equivalent attributeid found for skillid " + skillid;
return ret;



it doesnt just return 0 or not at all right?

[OldnGrey]

Ironic. I was already looking at my GetAttributeIDBySkillID function and noticed a default of return -1 if no valid skillid was passed to it. ie a number and not a string..... ah hah!

I did a search through my old script sets and found I was still using the WoD attributes.inc for that function. The Distro was as you said with the return of the errortext.

All I have to do now is figure out why a non-standard skillid was passed to the function. Fascinating, I wonder why Drocket did it that way?

[CWO]

I dont like attributes.inc at all. The only thing I'm ripping from it is the AttributeIDs and replacing the SkillIDs in client.inc with them. Taking out attributes.inc before and just doing the raw stuff right in my script actually boosted efficiency of the script by reducing instructions.

[CWO]

And another thought... make sure the SkillID is passing as an int with CInt(). It could be fine except for the fact that it could be passing as a string.

[OldnGrey]

No doubt.
The point of the exercise was to find why I had so many errors in debug.log and see it through to the end.
With your help I was able to figure out what I was reading. So many thanks for taking the time to teach me something. I'd never looked at a .lst file before in 4 years of scripting.

Getting into the inefficiencies of attributes.inc is another topic.

I did a special compile to see what attributeid was being passed to the function so often. It turned out to be a null value.

[OldnGrey]

Oh, and the outcome of this is a debug.log that only has the itemdesc file complaints and 2 script datatype errors. Dramatic improvement.

[MuadDib]

Debug.log is your very best friend. Trust me. Although it does not catch ALL cases of issues, it catches a lot.

[Marilla]

It also definitely encourages defensive programming, instead of relying on POL just trudging along when it encounters errors, which can lead to strange behaviors that you can sometimes have a difficult time tracking down!

(not that I would know, or anything )


My only issue - and it's a tiny, tiny one - is what OldnGrey mentioned about it listing all the 'missing' itemdesc.cfg files in every package. Being the anal-retentive type that I am, I've actually considered adding empty itemdesc.cfg files to prevent that. But also due to the aforementioned retentiveness, I refuse to do so! Just like I refuse to do this to prevent compiler warnings:

Code: Select all

program DotCommand(who, text)
    who := who;
    Broadcast(text);
endprogram

[OldnGrey]

Your loss Marilla

I spent about 20 hours getting rid of compiler warnings by putting in hundreds of lines like item := item; and by declaring variables carefully to avoid local variable hides global variable of same name. The sight of a clean compile is the result, but a whole weekend spent and all I get out of it is about 2 minutes of gloating!

I am currently busy removing all references to SKILLID in all my scripts. That's a bigger task but one I should have started 2 versions of POL ago. I started by changing the exported checkskill function. Whew that was 117 scripts alone!

No doubt about it, I am prepared to tackle huge projects for minimal results but I do worry about adding an empty itemdesc and npcdesc file in every package. That bothers me because currently on every shard restart it's going to spam about 400K of debug entries. I'd like to hear from a core developer about recommendations for that because surely empty itemdesc and npcdesc files are not good for efficiency even if :*: is only read in once at shard startup.

But from Muad's comment it looks like this sort of obsessiveness is what's needed.