From nicolas.weeger at laposte.net  Sun Nov 12 04:07:34 2023
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Sun, 12 Nov 2023 11:07:34 +0100
Subject: [crossfire] Server log messages
In-Reply-To: <1517861a-c021-47b8-ad38-37e4dd69a9b2@crowcastle.net>
References: <1517861a-c021-47b8-ad38-37e4dd69a9b2@crowcastle.net>
Message-ID: <78559d83-e75f-7b6a-089d-38e9ec74ccad@laposte.net>

Hello.


I guess the main issue is that CF has only 4 log levels (error / 
information / debug / monster), so I'm not surprised using "debug" spits 
many many lines.


Also the logs don't distinguish between "this is a runtime issue which 
may lead to real problems" (map not found, out of space, unexpected 
thing happening) and "this isn't logical so should be checked" (hp > 
maxhp for instance).


There are some possible fixes, but they'd need some work, not sure if 
anyone feels like doing it.




> I'm seeing some server log messages that seem to indicate a need to 
> clean stuff up:
>
> 23/10/22 13:46:18 [DD] archetype exceptional beauty has nrof set to 4, 
> which will be ignored
> 23/10/22 13:46:18 [DD] archetype flawless beauty has nrof set to 4, 
> which will be ignored
> 23/10/22 13:46:18 [DD] archetype Blessedness has nrof set to 10, which 
> will be ignored
> 23/10/22 13:46:18 [DD] archetype Assassinating Dragons has nrof set to 
> 10, which will be ignored
> 23/10/22 13:46:18 [DD] archetype Assassinating Trolls has nrof set to 
> 10, which will be ignored
>
> I think those are from the artifacts file, and I would remove the nrof 
> entries, but I'm afraid they might be used somewhere despite the message.


If I remember correctly, the removal of nrof was supposed to be 
temporary, after some treasure generation changes, which is why the line 
was left.


> Also at startup:
>
> [DD] Artifact with no chance: white leather
> [DD] Artifact with no chance: black leather
> [DD] Artifact with no chance: Sirens


Those ones aren't necessarily significant, it means the artifacts can't 
appear randomly, but they can be put specifically in maps or used in 
recipes or treasure lists (I think those 3 do indeed appear in treasure 
lists).



>
> [DD] Monster Valkyrie has hp set higher than maxhp (350>0)
> [DD] Monster Belzebub has hp set higher than maxhp (20000>15000)
> [DD] Monster cave byakie has hp set higher than maxhp (10000>8000)
> [DD] Monster twisted sprite has hp set higher than maxhp (5500>4000)
>
> The HP higher than max might be an error, but it does block some 
> healing, so it might be intentional.  I also see similar messages on 
> some map loads where I assume the correct answer is to also set maxhp 
> to match hp (e.g., Beserker on /scorn/oldcity/oldcity54)


Correct, it's a way to prevent hp regeneration.



> And on some map loads:
>
> 23/10/11 14:03:26 [DD] citylife: adding 6 NPC to map 
> /world/world_105_116.
> 23/10/11 14:03:26 [DD] Merged duplicate skill skill_use_magic_item for 
> farmer
>
> 23/10/11 14:03:26 [DD] citylife: adding 5 NPC to map 
> /world/world_105_115.
> 23/10/11 14:03:26 [DD] Merged duplicate skill skill_use_magic_item for 
> man
> 23/10/11 14:03:26 [DD] Merged duplicate skill skill_use_magic_item for 
> man
> 23/10/11 14:03:26 [DD] Warning: Tried to insert object wrong part of 
> multipart object.
> 23/10/11 14:03:26 [DD] Warning: Tried to insert object wrong part of 
> multipart object.
> 23/10/11 14:03:26 [DD] Warning: Tried to insert object wrong part of 
> multipart object.
>
> 23/10/11 14:08:14 [DD] load_objects on 
> /scorn/misc/battle_arena/entrance took 5679 us
> 23/10/11 14:08:14 [DD] Merged duplicate skill skill_use_magic_item for 
> ticket vendor
>
> I think the duplicate skill has something to do with 'race human,' but 
> I didn't find it.


Duplicate skill may happen if a creature gets a skill through 2 means 
(from race and from treasure list), so not that significant usually.

For the "wrong part of multipart object", it's more significant, and 
should be investigated (but the code corrects that so no crash hopefully).



> And over two thirds of the messages in my log are starting the 
> Move_Fog.py and Moving_Fog.py scripts (2.2 out of 2.8 million lines).  
> It may be a good idea to only issue log messages for python scripts 
> that fail or have some output.


Tracing Python files loading / execution may be needed sometimes, so 
it's probably more linked to the lack of log granularity...




Best regards


Nicolas