had a bunch of dupliated code injectors that are bypassed by the nature of AbstractClassRep::FIELD_SpecialtyArrayField
since those getSpecialFieldOut entries return a const char * from the stringtable, we *don't* want to try and kill those off, since that can lead to trying to delete deleted things from what was designed as a permanent record
classes using AbstractClassRep::FIELD_SpecialtyArrayField use an explicit-writing mechanism, rather than tying things to a variable 'slot', so don't try and concaenate the two
Multiple fixes in files sent by Az but matrix look at function was creating a view matrix that messed up the capture.
Look at function for matrix now returns the correct matrix and bakes looking better
Also adds a check so if we have spawned as just a camera, it scopes down to the client correctly
Correctly has the shortcut calls activate for the spawn override callbacks if no modules or gamemodes are able to respond to them
Reverted to the original calc clip space aabb to fix flickering bug reported by Rod in discord. Unfortunately this reintroduces the original issue of faint shadows showing at all times on the first split. But shadows render correctly where they are expected. A full review of pssm is required for later updates to be made.
Added logic to ModuleManager's findModules method to allow priority sorting as well as pre-filtering by a given module group
Adjusts the %isFine argument for the onMapLoadFailed callback events to %canContinueOnFail for a bit more clarity on what the arg conveys
Shifts the setSpawnObjectType, setSpawnPoint and onPostSpawn call stack to utilize an event manager to allow the setup process for spawners and gamemode prepwork to run in it's own time, if needbe. Such as if a gamemode has to generate a map and there's no guarantees on when it'll b e done for one client vs another
Added getModulesAndGameModesList, callOnObjectList and getNumCanCallOnObjectList utility functions
copies over .in and .cmake files for those cases when libraries themselves need to self-configure
searches for a source/libs/libs.cmake file for any torque-specific confiugurations we need to make for a given library
autoinclude any source/wrappers directory for unique to orque files, which will most commonly be data holder classes and script exposure, as well as adding those dirs to the #include listener list
also ditches forcing warn levels to lowest for libraries since if folks are going to experiment, best tey know about anmy underlying things to avoid
By default this list of variables would be:
%this.spawnClass = "Camera";
%this.spawnDBType = "CameraData";
%this.spawnDataBlock = "Observer";
%this.playerSpawnGroups = "PlayerSpawnPoints PlayerDropPoints";
%this.spawnPoint = "";
%this.spawnLocation = "0 0 0";
Also adds several callbacks so that these values can be overridden by modules and gamemodes, kicked off from the %client.spawnControlObject(); command :
callOnModules("setSpawnObjectType", "Game", %this);
callGamemodeFunction("setSpawnObjectType", %this);
callOnModules("setSpawnPoint", "Game", %this);
callGamemodeFunction("setSpawnPoint", %this);
callOnModules("onPostSpawn", "Game", %this);
callGamemodeFunction("onPostSpawn", %this);
This is to ensure that a game mode can supersede modules, but even modules can dictate spawn behaviors for minimalist implementations and drop-in interop support
