Alter Global Scripts handling #3197
Conversation
|
@volundmush Fixing the unit tests should be what remains for this PR. |
|
@volundmush Ping. This and the other PRs you made often require rather small additions/unit test fixes. |
|
It looks like blongden got to this first - sorry I lost my momentum there. This PR has been superseded. |
|
@volundmush Not sure about that ... Blongden made a fix to make sure global scripts does not start up in the portal; I think this PR covers a different case. |
volundmush
force-pushed
the
fix_global_scripts
branch
from
e0f51db
to
81fd6f3
Compare
Agreed. This incorporates a nicer fix to the same issue, moving the scripts start into the server rather than keeping it in init. |
|
@volundmush Is this ready to re-review? |
…scripts not defined in settings.py
volundmush
force-pushed
the
fix_global_scripts
branch
from
01af0e5
to
bac0e9a
Compare
Brief overview of PR changes/additions
Currently, Global Scripts are started at the end of evennia._init(), which is called by both the portal and the server. The GlobalScriptContainer is also having trouble distinguishing "scripts defined in its settings.py section" from "ALL Scripts which have no db_obj attached" and tries to start them all...
Not only that, but the scripts are starting before at_server_init() and all startup hooks are called, so they might fire off before the game has finished loading critical resources.
Even if it's running on the portal.
To combat this, I moved the GLOBAL_SCRIPTS.start() to the very end of the server startup process, after calling startup hooks.
Motivation for adding to Evennia
The above is definitely not something we want happening.
Other info (issues closed, discussion etc)