[Wanderer]

So...

As i use new debug builds they tend to generate massive amounts of warnings that are not really - AFAIK at least - actual problems, errors or even worth capitalized 'WARNING' texts. And yes i do know these won't cause a popup but as certain builds do not generate popups at all this might be nice thing to tweak (can't really call it a fix). So for example little things like subsystems which have name that doesnt match any of the listed in the code, or animation code bits that 'lack' something that code automagically adds. I just think its kinda odd that retail data generates model related warnings and fully functional animation code triggers pagefulls of warning messages.

Code: [Select]

WARNING:  Animation trigger #0 on subsystem 'turret01', for ship 'GTM Hippocrates', has a negative reverse_start value!  Capping it at 0!
Something like replacing the rather dramatic capitalized 'WARNING' with 'NOTE' or something...

[taylor]

For the Xt builds, since the standard popup is disabled, anything that was reported through that popup gets sent to the debug with the "WARNING" prefix.

In most cases, like that animation instance, your data is wrong but the code fixed it internally so that it would actually work.  For the animation issue it will look for a user override first (meaning something in the table providing the value).  If a user specified value doesn't exist then it will attempt to generate a sane value.  Only if the generated value is wrong will it spit out that error, after setting a default value that shouldn't mess up the animation.  The generated value is typically only wrong if your table settings for the animation is wrong, when the timings that you provide in the table don't add up properly (leading to the negative value).

We don't just use the warnings for the hell of it (well, normally ), you are being notified of such things for a reason.  These are things that you as a mod maker not only need to be aware of but also things that you actually need to deal with.  We aren't going to bring less attention to problematic data, so there really isn't going to be any changes here.

[Wanderer]

Ok.. i concede the point about the animation code to you but why is the code whining 'warnings' about standard subsystems whose only fault is to have a 'wrong' (as code sees it) name? Like with for example retail orion and shivan commnode?

Code: [Select]

Warning: Ignoring unrecognized subsystem fighterbay, believed to be in ship capital01.pof

[taylor]

The names are for determining the subsystem type, which helps it do certain things for certain subsystems.  There is no way to differentiate between ones that the code doesn't know about and ones that are simply misspelled, so it just lets you know about anything it doesn't know how to deal with by default and then the dev can figure out whether it is actually a problem or not.  This warning isn't anything new though, it was there in retail.

[Nuke]

i wouldnt mind having warning levels, where warnings are ranked in order of severity. then you have a minimum warning level at which a  popup occures anything below that gets logged or tossed. i tend to like to get rid of the big problems first, then add the polish necessary to keep the debug warnings away. i might not fix a model thats scheduled to be replaced for example. when testing mods its common to have to run the game after each tweak many times. its just sort of a pita to have to click all those errors on a tweak/run cycle. there are ways to keep this from becoming a problem, like running retail builds.

then theres dealing with cutting edge builds, which might have features that you plan on using and other features in stable builds that you want/need to test as well. running under different builds tends to throw different errors depending on your usage of their various features. setting warning levels here would also come in handy, because the bugs technically arent there, the code just doesnt like running a feature thats in another build.

i find clicking through errors a hindrance to the modding process when i have no choice but to use a debug build. yes i know theres errors that need to be fixed, and yes i do fix those but in the latter stages of mod development, when all the placeholders have been removed and the tables refined for a particular target build (which in most cases hasnt even come out yet).

[Wanderer]

In most cases, like that animation instance, your data is wrong but the code fixed it internally so that it would actually work.  For the animation issue it will look for a user override first (meaning something in the table providing the value).  If a user specified value doesn't exist then it will attempt to generate a sane value.  Only if the generated value is wrong will it spit out that error, after setting a default value that shouldn't mess up the animation.  The generated value is typically only wrong if your table settings for the animation is wrong, when the timings that you provide in the table don't add up properly (leading to the negative value).

Point is that its also a tad difficult to set 'proper' value into that field as the animations that happen to trigger that warning are all type 'initial' (turret angle animations)... And judging from the code it does not allow 'reverse_start' string to be stuffed when using initial animations - which is very reasonable actually... So - simply put - it is not possible for a modder to fix that error.

[Wanderer]

Decided to dig this thread for a change...

So... just wondering as there warning messages appear on stable branch fs2_open.log as well (but not as pop up warnings though) could they be fixed? Its true that they are no more than just annoyances for modders but still... There is nothing a modder can do to fix the animation error - as it is not possible to set the 'reverse_start' value game uses the default (-1) - so as people do like using the initial turret angles this means every instance they are used generates whole bunch of following kind of bogus warning entries to the log.

Code: [Select]

...
WARNING:  Animation trigger #0 on subsystem 'turret01', for ship 'GTFR Triton', has a negative reverse_start value!  Capping it at 0!
...
As for the unrecognized subsystem warning... well i guess the retail way of reporting potentially faulty subsystem entries is still ok but does the report about that in the debugging log has to be marked with 'warning' tag? Especially as it is triggered with every instance of fighterbay or other such 'not marked in subsystem types' subsystem... not to mention the subsystem animations...

[taylor]

There is nothing a modder can do to fix the animation error - as it is not possible to set the 'reverse_start' value game uses the default (-1) ...

If it wasn't possible to fix by modders then we wouldn't have the warning in there.  Just set +reverse_delay to 0 and be done with it if the warning bothers you so much.


EDIT:  Nevermind.  Wanderer reminded me that trigger types don't have that setting (ultimately a bug in it's own right), and I remembered that I fixed it once before in the constructor but never committed it.  It shall be fixed.