hey, there’s some strange behavior in the notifier.
for example there are C++ notification categories, as well as pythonic (called DirectNotify), which both accept other notify-levels:
the python version (from direct/src/directnotify/DirectNotify.py) accepts error, warning, info and debug
whereas the C++ version also accepts fatal and spam additionally (at least those are the ones i found out. couldn’t find the C++ file for that)
no big problem so far except the missing documentation, but:
you don’t know which notifiers belong where. or is maybe the capitalisation of categories indicating the notify type? (Uppercase category = python; lowercase = C++)
there are two prc options: notify-level and default-directnotify-level. is the first one for C++ and the second one for python only?
panda’s Config.prc-set options override my custom ones. it should go the other way around
at startup (at ShowBase initialisation) there are some default settings before any config files are read, which makes it impossible to set panda to be all quiet. EDIT: ok, this seems to be not related to notifiers, as there is no category or anything printed:
Known pipe types:
glxGraphicsPipe
(all display modules loaded.)
i think i found the ‘bug’. notification level is set at import time already, not at initialisation time as i expected. i’ll try to load my prc file before importing anything else.
still… how comes the global Config.prc is read before i can even load mine?
It is unfortunate that the two different notify systems are completely unrelated. One day I hope to rectify this.
As to your prc file issue, the problem is that the notify categories are all loaded at application startup time–which happens before the first line of code is executed. So if you load a prc file via the loadPrcFile() call, it’s already too late to use it to change the notify severities. (Though if all you want is to change the notify severities at runtime, you can do this with something like notify.ptr().getCategory(’:pgraph’).setSeverity(NSDebug)).
The intended design of the prc file is really not to load your custom prc files at runtime like this, but to put your custom prc file in a directory named by $PANDA_PRC_PATH, or in the single directory named by $PANDA_PRC_DIR, so that it will be loaded implicitly at application startup. If you do this, then all of your config variables will be accepted, and they will override whatever is specified in the system file.
Ideally, the default PRC_PATH should allow you to place your custom prc files in your own app dir and have them be automatically loaded from there without having to pre-set any environment variables. We haven’t yet figured out the right way to make this work.
looks like the intended way is the only reliable, as otherwise i can never be sure my settings are really considered and i’d have to start with ‘warning’-level every time until my custom levels are read. the bad thing about the panda way is that on the defined path ALL *.prc files are read, which may cause unexpected complications - especially if you put your config files in /etc/yourgame.prc or ~/.yourgame.prc. it would be ok if you create extra directories for those files, but then you’ll still need to tell ppl to not put other files with prc extension into them. works but is semi-perfect, IMHO.