sektor2111 wrote:Then you can prevent Zone 0 if you think this is the only issue... go figure if you have monsters as long as they are behind a stupid wall in a NON 0 Zone, USELESS locations. Modification which I did in NsTDM attempts to NOT ALLOW monsters out of navigable areas - THIS is the issue.
Near as I can tell, almost the only time this is spawning things behind stupid walls is if you have the bHorde option set true.
If this is a major issue for you or your gametypes, don't use the bHorde option. Code could be added to do checks for each member of the horde, but
it is not worth the effort or extra processing. Any actors that fall off the map, or fail to spawn, are added back the next check.
(Falling off the map, and falling out of the world are 2 different things.)
Preventing Zone 0 spawns was not the only issue.....
It was however an issue.
This no longer spawns actors that "Fell out of the World!".
sektor2111 wrote:
Aside a bit:
.
.
blah blah blah
.
.
Still to solve: Tiny lags caused in player for creatures used. If they are not part of Level by default, player did not pre-cache stuff configured in INI. As result, all firsts appearances in player will cause a very small frame-drop - I would like to find a solution for pre-cache somehow...
That is easily solved. Use something like this:
Code: Select all
function PostBeginPlay()
{
PreCacheLists();
Super.PostBeginPlay();
}
function PreCacheLists()
{
local int i;
local class<Actor> aC;
local Actor pcla;
for (i=0; i<NumItems; i++)
{
aC = class<Actor>(DynamicLoadObject(DropList[i], class'Class'));
pcla = spawn(aC,,,);
if (pcla != None)
{ pcla.destroy(); }
}
for (i=0; i<SPNumItems; i++)
{
aC = class<Actor>(DynamicLoadObject(SPDropList[i], class'Class'));
pcla = spawn(aC,,,);
if (pcla != None)
{ pcla.destroy(); }
}
}
I left that bit out of the SwarmSpawner, as it was already doing enough things in PostBeginPlay, and the "tiny lags" that occasionally happen the first time
an actor class is spawned doesn't bother me that much. (That example will be used in Dropper v2.0 final, which will be out tomorrow I think. Maybe Monday....)
sektor2111 wrote:Edit: The rest of "SpawnMutator" feature might drive into a LULU as long as some "special" mutators have to be added in RUN-LINE (not even in MapVote) and of course, for not being spawned by other mutators. By example I did different things in testing purposes which were working much better VIA "ServerActors=" and/or "RUN-LINE" rather than triggered by map-vote load type and similar ways.
Obviously there will be mutators that should NOT be loaded by the OPTIONAL feature of SwarmSpawner to load a mutator class.
This depends of course upon what that specific mutator is doing.....
Only an insane idiot would think otherwise.....