Less than useful log messages

[ja231c]

Some log messages aren't very useful, such as: ASSERTION: Unknown alpha mode: 2, 0 (e:_skyrimhd\code\gamesln\bsshader\bsshader.cpp line 225)

In the case of this particular one it'll spam the log as long as the object with unknown alpha mode is visible in the render window;

It provides no useful information as I do not know what alpha mode "2, 0" is, nor do I have access to Bethesda's source code, nor can I easily tell what mesh has the problematic alpha mode (the only way to do it is move the camera until the spam stops and then move it back until it starts again and so on)

I suggest reworking it into something that shows the path to mesh and/or editorid of the object and the alpha flags as they are in the Alpha Flags field in NifSkope and show it in the log only once

There is also some other messages that display the name of the root node in NIF, which for modded NIFs tends to be "Scene Root", which is completely useless, such as: TEXTURES: Scene Root : Cylinder is missing a normal map

Replacing the NIF root node name with path would turn this useless message into something that does have an actual use.

[Perchik71]

I'll just cut it out, as I did with the shaders when changed to enb.

[ja231c]

I'd prefer if the messages were still there as they aren't completely useless, just lack necessary information to anything about them

Well, the missing normal map one is kind of useless, but it's not the only message that displays NIF root name, and the other ones aren't really useless. The alpha mode one isn't useless either, it does actually provide some useful information, if in an extremely obnoxious way.

[Perchik71]

Shaders can't carry any information, it's code understandable for a video card. Otherwise it would be eerily slow. Edit: Moreover, the video card simply receives data and displays it on the screen.

[ja231c]

I'm fully aware of what shaders are, I don't see how they're relevant to the log messages I mentioned.

Removing the log messages I mentioned in the previous comment is not acceptable as they do contain information that can be useful.

I think you misunderstood what I meant, I did not mean "I want the log messages you removed back", I meant "I don't want you to remove the log messages I mentioned, I want you to make them useful instead, in the way I described in the original comment".

[Perchik71]

Only you are asking for the impossible. All that's where is, this comparison is exposed globally to the transparency flag. To keep the order of output on the screen.

[ja231c]

Alright, then at least make it not spam the log and just appear when the affected object comes into view, not (presumably) every single frame it's on the screen so that it is still possible to figure out which one that is by moving the camera, just without the excess spam.

Also, what about the other one I mentioned? Anything that could be done to show something more useful in that scenario?

[Perchik71]

Alright, then at least make it not spam the log and just appear when the affected object comes into view, not (presumably) every single frame it's on the screen so that it is still possible to figure out which one that is by moving the camera, just without the excess spam. I'll take a look at how it's done in the game sometime. But I would just cut it out myself, you can see the defective model in the game if the game does not fail. Edit: A duplicate error comparison is possible, anyway, I count the hash every time... as an idea. However, if another message is displayed, the error will pop up again... hmm. Spam protection. That's a thought.

[ja231c]

The point is to not have to waste time loading the game to see if anything looks wrong.

Also, the duplicate error comparison, the way you described, would be useless as it would make it impossible to tell which object caused the error as it would not show the message again unless there's another message, no one needs a log message that says nothing useful and occurs for an undeterminable reason.

Just add a variable, show the assertion, set the variable to true when the object appears, don't show any more assertions of this type as long as it's true; when object leaves view set it back to false, that way the assertion appears once every single time it starts to occur, which results in it's reason being possible to determine.

That or remove it and add a new log message in a place where more information about the problem exists which would actually provide more useful information about the same thing.

[ja231c]

Could you re-open this issue? It is definitively not completed.

[ja231c]

There's also this one, for every non-shadowcasting light marker. MODELS: Found geometry 'marker_light:2' under fade node 'CLONE LIGHT_EDITOR_ID_HERE' with no shader property.

This one is quite interesting actually, as it shows a bug with the non-shadowcasting light marker where it has a geometry with no shader even though it shouldn't;

That being said, in context of light markers, this message it is completely useless and can be removed, in other contexts, maybe not.

Could also include a fixed marker_light.nif with CKPE to fix it properly. fixed_light_marker.zip Here's the fixed light marker, if that's the route you want to go, probably the best way. Note that this is for Skyrim SE, Fallout 4 doesn't have this bug.

[ja231c]

I've got another two:

MASTERFILE: Armor 'ARMOR_EDITOR_ID_HERE' (ARMOR_FORM_ID_HERE) used invalid Biped Object slot UNNAMED_SLOT_HERE for race 'RACE_EDITOR_ID_HERE'.
MASTERFILE: ArmorAddon 'ARMOR_ADDON_EDITOR_ID_HERE' (ARMOR_ADDON_FORM_ID_HERE) used invalid Biped Object slot UNNAMED_SLOT_HERE for race 'RACE_EDITOR_ID_HERE'.

What's an "invalid Biped Object slot" according to the CK?

It's a slot without a name in the race record... which to the best of my knowledge works exactly the same as a slot with a name.

Also, this doesn't display for Additional Races, just the one in the "Race" field, even if the Additional Races also have unnamed slots.

Someone might want to see those though, maybe, an option to turn these on or off in the ini wouldn't be bad.

[Perchik71]

What's an "invalid Biped Object slot" according to the CK? - You're asking me, as one of the developers of the Creation Kit from Bethesda. And this is not the case. Each one has its own name, if you have an updated skeleton, then you need to update it first in the program itself, you will help in the discord. For me, this is not of interest, I took into account some important things from this conversation and closed it.

[ja231c]

It was a rethorical question; I stated right after it what the answer is.

Plenty of mods use those unnamed slots without any issue whatsoever.

The "important things" you took into account from this conversation is "spam protection" - which I explained to you is completely useless the way you implemented it, hell, it is even worse than it not being there! with your spam protection it is completely IMPOSSIBLE to narrow down which object causes the spam.

You missed the entire point! The point was "make it easier to narrow down what causes log message, prefferably without spam", NOT "remove spam".

Also, skeletons do not contain Biped Object slot information, they are completely irrelevant! Skin instances do, but they don't store names, the names appear to be irrelevant for everything except the log message! The only place where the names are even present is the Race record.

I apologize if I appear to be pissed off but to be honest I am, you keep ignoring most of what I'm saying.

Also, what Discord? there is no Discord link anywhere on this repo!

Also, isn't the point of this project to make the Creation Kit less of pain in the ass to use? I think that having more useful log messages definitively fits that.