SwarmSpawn v2.0 - Final(Not)

Search, find and discuss about Mutators!
User avatar
Barbie
Godlike
Posts: 1727
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by Barbie » Sat Jun 04, 2016 9:32 pm

I was just interested and had a look at "SwarmSpawn_v2.0-UT99-Preview2"'s code. There I stumbled over

Code: Select all

var Vector SpawnLocs[4096];
...
function PostBeginPlay() {
...
	for (N = Level.NavigationPointList; N != NONE; N = N.NextNavigationPoint)
		if ((N.IsA('PathNode') || N.IsA('SpawnPoint') || N.IsA('PlayerStart')) && (!N.Region.Zone.bWaterZone || !N.Region.Zone.bPainZone))
			(... filling your SpawnLocs array here ...)

	forEach AllActors(class'Inventory', Inv)
		if ((!Inv.Region.Zone.bWaterZone) && (!Inv.Region.Zone.bPainZone))
			(... additionally filling your SpawnLocs array here ...)
Because an InventorySpot is created for every inventory item and that InventorySpot is already part of "Level.NavigationPointList" you could put this together to

Code: Select all

	for (N = Level.NavigationPointList; N != NONE; N = N.NextNavigationPoint)
		if ((N.IsA('PathNode') || N.IsA('SpawnPoint') || N.IsA('PlayerStart') || N.IsA('InventorySpot')) && (!N.Region.Zone.bWaterZone || !N.Region.Zone.bPainZone))
			(... filling your SpawnLocs array here ...)
A difference of InventoryItem/InventorySpot is the Z component because InventorySpot is placed above the item.

And another suggestion: for setting properties as text I use an extended version:
SetPropertyTextEx
Show

Code: Select all

static function bool SetPropertyTextEx(Object obj, coerce string PropName, coerce string PropValue) {
/*******************************************************************************
Does the same as *SetPropertyText* but logs a warning if function failed.
*******************************************************************************/
	Obj.SetPropertyText(PropName, PropValue);
	if (Obj.GetPropertyText(PropName) != PropValue)
	{
		warn(obj $ ".SetPropertyText(" $ PropName $ "=" $ PropValue $ ") faild for" @ obj $", current property value=\"" $ Obj.GetPropertyText(PropName) $ "\"");
		return false;
	}
	else
		return true;
}
So I can see in the log files if something went bad.

Just my 2 ct.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

MrLoathsome
Inhuman
Posts: 958
Joined: Wed Mar 31, 2010 9:02 pm
Personal rank: I am quite rank.
Location: MrLoathsome fell out of the world!

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by MrLoathsome » Sun Jun 05, 2016 10:02 pm

Good eye Barbie. (I like your current location. I never move without proper hashing, so I picked something different. :tongue: )

That particular bit of code where the list of possible spawnpoints is created has been rewritten a number
of times. Both for this project and some of earlier mutators I was screwing around with. Some of the previous versions
were doing all kinds of crazy stuff. Adding random offsets to the locations. Attempting to spawn a temp pawn there
to validate the location, etc etc.
Both in an attempt to get as many possible locations as possible, and to try and eliminate or reduce the frequency of things
that "fell out of the world!".

During the current v2.0 project I have simplified that a lot. Preview Release III will probably have a version of that bit
which will be very similar to what you just posted. (Hell I might just steal your example and tweak it a bit.)

Thanks for mentioning the InventoryItem/InventorySpot bit there. I was unaware. (I really don't look at maps at all....)
In addition to reducing some redundancy in the spawnpoints list, that info may help me reduce the falling out of the world crap.

Re: SetPropertyTextEX

If I was doing that stuff anywhere other than the SpawnPawn() function I would be inclined to use that.
As it is, the mutator does log the actual values after the attempt to set them, so if you see either a blank
space or a value other than the one you tried to set in that log line you know something has gone wrong.
Just have to look a bit closer to see it.
Think what I have executes faster in this case as it avoids the extra function call. And half of it only happens if bDebug="True".

----------

@heliumcat

The mutator will process the entire ini file sequentially the first pass thru.

bRandMode will only kick in for swarms that have bSpawnOnce="False" and Qty > 0 after the first pass.
You should configure your ini so that only Monsters or items that are destroyable or have a LifeSpan set are in
the list of "Active" swarms that will actually use the bRandMode option.

Re: Weapons.
When a player picks up a weapon, UT actually spawns a new copy of it and gives it to the player.
It is NOT the same actual actor that SwarmSpawner has spawned. The SwarmSpawner will only
count/track the status of the actual pickup it spawned. It ignores any the players have. If they toss their guns
those are also ignored by the mutator. (I think.... :lol2: )
You should be able to spawn weapons that respawn or not. You could have them spawning once and respawning.
Or have them spawn once and not respawn. Or have them spawn once with a lifespan, and they will be gone if you don't find them in time.
Or have them not respawn, and not spawn once, optionally with a lifespan.
In which case they would show up at random locations during the match, as swarmspawner would replace them after they get picked up or destroyed.

If I did it right, this can all be set to happen any way you want regardless of whatever WeaponsStay option you have set in UT for the match.
That setting should just effect weapons that are on the map by default.
Last edited by MrLoathsome on Sun Jun 05, 2016 11:24 pm, edited 1 time in total.
blarg

User avatar
Barbie
Godlike
Posts: 1727
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by Barbie » Sun Jun 05, 2016 11:17 pm

MrLoathsome wrote:Some of the previous versions were doing all kinds of crazy stuff. Adding random offsets to the locations.
Maybe it's of interest: in my experiments with spawning additional PlayerStarts I noticed that the Spawn() function does not necessarily spawns the Actor at the given position but seems to take care of the collision cylinder and varies the given location so that the collision cylinder fits fully into the world.
MrLoathsome wrote:"fell out of the world!"
Would be also of interest: under what conditions does an Actor fall out? If its pivot point is in the void? Or if the collision cylinder enters the void?
MrLoathsome wrote:Attempting to spawn a temp pawn there to validate the location
I've noticed that you use a SkaarjWarrier for it. I would not do such a test, because in this moment you don't know what will be spawned there later. If it is something that is smaller than a SkaarjWarrier, you've given up that SpawnLocation for no reason. If it is something bigger than a SkaarjWarrier, it might fail although the SkaarjWarrier had survived the spawning.
heliumcat wrote:How do you spawn a weapon as if it's dropped and therefore not respawning every time at the same location after you've picked it up?
Setting the flag "bTossedOut=True" should enable singular weapons.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

MrLoathsome
Inhuman
Posts: 958
Joined: Wed Mar 31, 2010 9:02 pm
Personal rank: I am quite rank.
Location: MrLoathsome fell out of the world!

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by MrLoathsome » Sun Jun 05, 2016 11:57 pm

Barbie wrote:
MrLoathsome wrote:Some of the previous versions were doing all kinds of crazy stuff. Adding random offsets to the locations.
Maybe it's of interest: in my experiments with spawning additional PlayerStarts I noticed that the Spawn() function does not necessarily spawns the Actor at the given position but seems to take care of the collision cylinder and varies the given location so that the collision cylinder fits fully into the world.
Yes. For this v2.0 rewrite I have been attempting to let UT itself handle as much as possible, and just code this thing so if the actual Spawn() function
fails, it just tries again. It is working better than expected since I changed my approach.
i.e. working with the engine rather than fighting it. Save the "Brute Force" techniques for the last resort....
Barbie wrote:
MrLoathsome wrote:"fell out of the world!"
Would be also of interest: under what conditions does an Actor fall out? If its pivot point is in the void? Or if the collision cylinder enters the void?
I suspect if I knew the answer to any of these questions, the problem would be gone. :help:
(Don't spent time looking into it yet. Lets see if the next revision can make that go away on its own....)
Barbie wrote:
MrLoathsome wrote:Attempting to spawn a temp pawn there to validate the location
I've noticed that you use a SkaarjWarrier for it. I would not do such a test, because in this moment you don't know what will be spawned there later. If it is something that is smaller than a SkaarjWarrier, you've given up that SpawnLocation for no reason. If it is something bigger than a SkaarjWarrier, it might fail although the SkaarjWarrier had survived the spawning.
This is indeed another good observation. I just picked a default SkaarjWarrior for the validation at that point in the code as sort of
an "average" sized thing. (Larger than most even...)
The issue is complicated by the SwarmSpawners nifty SDS option, which is all working great. It was spawning Micro-Titans in DM-Fetid with about
the number of re-tries I was expecting. I am going to see if just skipping that entire step works. Let the thing figure out in real time if the
actor will fit or not. If it still works ok, then Simpler = Faster = Better. 8) Good feedback there. Made me think a bit. :tu:
Barbie wrote:
heliumcat wrote:How do you spawn a weapon as if it's dropped and therefore not respawning every time at the same location after you've picked it up?
Setting the flag "bTossedOut=True" should enable singular weapons.
I think that is irrelevant for SwarmSpawner. bTossedOut should be handled by the engine elsewhere at that point, and SwarmSpawner no longer cares about
that actor. (The dropped weapon.)
Set your SwarmInfo line with bSpawnOnce="True" and ,SSet0=(SName="Respawntime",SVal="0.0") and that line should be a 'singular' weapon.
You could also set bTossedOut if needed, I think. Ain't tried that yet......
blarg

MrLoathsome
Inhuman
Posts: 958
Joined: Wed Mar 31, 2010 9:02 pm
Personal rank: I am quite rank.
Location: MrLoathsome fell out of the world!

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by MrLoathsome » Wed Jun 08, 2016 8:51 am

BUMP!

Update: Making some progress with this I think.
Should have a vastly improved version of it posted on page one in a day or 3.
Barbie wrote:
MrLoathsome wrote:"fell out of the world!"
Would be also of interest: under what conditions does an Actor fall out? If its pivot point is in the void? Or if the collision cylinder enters the void?
I suspect if I knew the answer to any of these questions, the problem would be gone. :help:
(Don't spent time looking into it yet. Lets see if the next revision can make that go away on its own....)
Been looking at this a bit closer, and now suspect Epic didn't know the answer to these questions either. :roll:
If they did know, they had no good way to prevent it or event FellOutOfWorld() in class Actor would probably not exist.

Took an even closer look and determined that the native code triggers event FellOutOfWorld() when the (Actor.Region.ZoneNumber == 0).
Guess what? You can check that value almost instantly in Uscript. It takes the default code far to long to actually call the event and get the actor destroyed for my purposes here.
SwarmSpawn now adds back any SpawnOnce actors that have fallen out of the world much faster and more reliably.

Also @ Barbie. Your suggested tweak on the bit that builds the list of spawnpoints works perfect as posted.
Actually gets the exact same number of spawn locations as my previous, somewhat redundant code. :tu:

Re: Spawning bots with names.

This ini works with my current development version, when spawning U1 bots in default UT DeathMatchPlus games:

Code: Select all

[SwarmSpawn.SS]
CheckRate=2
bDebugMode=True
bRandMode=False
SwarmInfo[0]=(SwarmClass="Engine.GameInfo",Qty=0,bSpawnOnce="True",SSet0=(SName="DefaultPlayerName",SVal="Fred the Bot"))
SwarmInfo[1]=(SwarmClass="UnrealI.MaleOneBot",Qty=1,bSpawnOnce="True")
SwarmInfo[2]=(SwarmClass="Engine.GameInfo",Qty=0,bSpawnOnce="True",SSet0=(SName="DefaultPlayerName",SVal="Dave the Bot"))
SwarmInfo[3]=(SwarmClass="UnrealI.MaleTwoBot",Qty=1,bSpawnOnce="True")
SwarmInfo[4]=(SwarmClass="Engine.GameInfo",Qty=0,bSpawnOnce="True",SSet0=(SName="DefaultPlayerName",SVal="SkankBot"))
SwarmInfo[5]=(SwarmClass="UnrealShare.FemaleOneBot",Qty=1,bSpawnOnce="True")
SwarmInfo[6]=(SwarmClass="Engine.GameInfo",Qty=0,bSpawnOnce="True",SSet0=(SName="DefaultPlayerName",SVal="Your Mother the Skaarj"))
SwarmInfo[7]=(SwarmClass="UnrealI.SkaarjPlayerBot",Qty=1,bSpawnOnce="True")
Not sure if it works with the Preview Release II version or not. It might.....
**DISCLAIMER - The above example ini is a horrible hack. SwarmSpawner will process horrible hacks without questioning them.
Make sure you know the consequences of your horrible hacks. :tongue:

Tested that file with 227 and the DeathMatchGame gametype, and while it does spawn the bots ok, they are all still named "Player".
Will have to test a bit more to figure out exactly what the difference is. Either the gametype or 227 are doing something a bit different
that clobbers that setting. Spawning bots with this will be sort of "experimental" for now.

Due to the amount of things that need to happen in order to add bots to games "correctly" a dedicated BotSpawner mutator would be the way to go.

It should be able to add U1 bots, UT bots, FerBotz, Mbots, whatever bots, if done correctly. And optionally use either settings from its own config file, or from
the current botconfig info there in the user.ini file. Or both.
Maybe Sektor knows somebody who might be able to adapt the SwarmSpawner source to such a task. :agree1:
(He should wait for this next release however..... Source has changed a bit.)

You might be able to get it all done via SwarmSpawner, but it will require more horrible hacks than the above example....... :pfff: :wth:
Last edited by MrLoathsome on Wed Jun 08, 2016 10:25 am, edited 1 time in total.
blarg

User avatar
OjitroC
Godlike
Posts: 1117
Joined: Sat Sep 12, 2015 8:46 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by OjitroC » Wed Jun 08, 2016 10:04 am

MrLoathsome wrote: Not sure if it works with the Preview Release II version or not. It might.....
Tried it with that ini and it does.

MrLoathsome
Inhuman
Posts: 958
Joined: Wed Mar 31, 2010 9:02 pm
Personal rank: I am quite rank.
Location: MrLoathsome fell out of the world!

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by MrLoathsome » Fri Jun 10, 2016 3:25 am

OjitroC wrote:
MrLoathsome wrote: Not sure if it works with the Preview Release II version or not. It might.....
Tried it with that ini and it does.
Excellent. :tu:

Quick question.

What is the largest ini file any of you may have come up with while testing this so far?

The 1024 max number of Swarms in Preview Release II is WAY too big. For a variety of reasons.

This will be reduced considerably in the next Preview Release. 64 Swarms I am thinking.
Since the next release will be able to spawn clones of itself, if you need more than 64 lines this will not be an issue.
The clones will have separate ini files, and you will be able to set the CheckRate and everything else differently for each.
This will solve several problems at once.

*I have not seen ANYTHING fall out of the world in testing since I added that check on Actor.Region.ZoneNumber. NOTHING.
When this is done, expect a nice update for The Dropper. (One of the reasons for that name,was due to the amount of shit it drops out of the world.... :noidea )
blarg

User avatar
sektor2111
Godlike
Posts: 4171
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by sektor2111 » Fri Jun 10, 2016 6:17 am

The name of "player" shown on Screen Scoreboard etc. is coming from PlayerReplicationInfo.PlayerName or such. If you are using a timer things reacts slower. While PlayerReplicationInfo did not spawn YET those "Boty" creatures won't hold good names. Beside this I think Bot/MBot collects data from their origin (user.ini). Let me see, at game initialization if any Bot enter the game, tick-rate falls a little bit due to reading external stuff which takes time. For Bot task, you should spawn a "tracker" waiting a few milliseconds and then attacking PlayerReplicationInfo assigned to Bot. The rest of tracers around stuff spawned is good to have a simple deal rather than 3 pages of functions. If we are in line with any Path around a NavigationPoint, we are in good area else REGION.ZONE in DM-ZETO does an USELESS Spawn(), those many maths are already harmful and I'm speaking from my MBot bad experiences - don't take a map as an ideal model, there are more dumb ones in some points because they weren't done for SwarmSpawning. There are neutral zones, but where player won't reach (not normally) and monster/stuff brought there is useless. Just look at map closer and you'll figure what happened at my 1on1 vs Monster, at a moment game was broken and nobody FELL OUT OF WORLD it was just dropped in crap completely unreachable, I'm sorry if you don't understand what I mean with my stupid Tracing code. And it is not the only map where monster spawned pushed by engine will get an useless location. CTF-Sprinta if I well recall ? Why should I spawn monster in area where nobody can ever go without cheating ? Barbie has a string problems which somehow is funny and complexity of processes which results in a lot of other bugs to solve which were happily created on demand, I'd rather head to precision and NO FAILURE in bringing these monsters or other stuff REACHABLE by Anyone.

Main FACTOR is: Each PreCached location should have a Trace with some NavigationPoint else monster/stuff spawned in "SkyBox" doesn't fascinating nobody.

MrLoathsome
Inhuman
Posts: 958
Joined: Wed Mar 31, 2010 9:02 pm
Personal rank: I am quite rank.
Location: MrLoathsome fell out of the world!

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by MrLoathsome » Fri Jun 10, 2016 6:59 am

Look closer at what that example ini file does. *It all only happens once for that ini.

SwarmSpawn is changing the value for DefaultPlayerName in Engine.GameInfo before the bots even get spawned.
This is not waiting for the PRI to eventually decide to show up. :sleep:

It really is a horrible hack. :loool:

But it works. It will show fine on Scoreboards or anywhere else. There is no faster way to do it. (Maybe.... :what: )
Only side effect would be if you started summoning more bots at the console, they would probably all have the same name
as the last one that SwarmSpawn had set for Engine.GameInfo.DefaultPlayerName.

Re: Rest of your post there. This mutator does no checks to see if the map is all broken and has Navigation points ect in
totally bogus locations. It will try as hard as it can to work with whatever garbage maps it happens to be running with.

A mutator that would fix pathing, spawnpoints and other shit on defective maps sure would be nice, but this ain't it.
(If you write that, load it before SwarmSpawn in your mutator chain. 8) )
blarg

User avatar
OjitroC
Godlike
Posts: 1117
Joined: Sat Sep 12, 2015 8:46 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by OjitroC » Fri Jun 10, 2016 12:54 pm

MrLoathsome wrote: What is the largest ini file any of you may have come up with while testing this so far?
I haven't used an ini larger than your initial example ini - the rest of the time I have had, at most, two or three weapons plus three or four 'monsters' or ScriptedHumans or bots (mainly because it is just me, no bots, playing and multiples of the 'monsters' can be spawned). I would think 64 lines is more than ample most of the time.

User avatar
sektor2111
Godlike
Posts: 4171
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by sektor2111 » Fri Jun 10, 2016 6:10 pm

MrLoathsome wrote:Re: Rest of your post there. This mutator does no checks to see if the map is all broken and has Navigation points ect in totally bogus locations. It will try as hard as it can to work with whatever garbage maps it happens to be running with.
Nah, usually items were added in locations nearby walls and that can be found by Bot (DM-ZETO - UT_Eightball aka RocketLauncher and ammo around). THOSE are placed correctly, like I said, I have solved these in previous codes and My Flakson doesn't fail the game. Using items as locations IT IS NOT recommended. My example was from functional maps as dumb as they are and/or a visibility check to a NavigationPoint would prevent spawning behind Wall.
But, if you want, I can write a mutator for moving (not making them dynamic - just moving them away) NavigationPoints... is not a wise thing... I know what I'm saying...

User avatar
PVS
Novice
Posts: 16
Joined: Fri May 27, 2016 6:41 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by PVS » Fri Jun 10, 2016 7:52 pm

MrLoathsome wrote:Look closer at what that example ini file does. *It all only happens once for that ini.SwarmSpawn is changing the value for DefaultPlayerName in Engine.GameInfo before the bots even get spawned.This is not waiting for the PRI to eventually decide to show up. It really is a horrible hack.
I'm tested this "horrible hack" too on the current version - almost always works fine, but on some maps and situations - I have the same bots names in scoreboard, for example: 1 "Dave the Bot" and 3 "Your Mother the Skaarj" :)
I think I understand why this is happening, because SwarmInfo[0] not rigidly related to SwarmInfo[1]. Ideally for this task need the following: after change "DefaultPlayerName" in SwarmInfo[0] must expect - when with that new name spawn bot in the SwarmInfo[1], only after that read and perform SwarmInfo[2,3,4, etc]. As I said earlier - need some "time delay" function in SwarmSpawn or maybe other internal command, which would allow to stop work or reading next SwarmInfo[x] line, for example - stop work at some amount of time or waiting check some conditions.

Also, I see, that "horrible hack" changes the "Game Type" line in the scoreboard, here is absolutely not clear - why...
Anyway - thanks, now much better - have different bots names, what all identical "Players", so at least I can see - who wins :). I understand that this is not important task, and few people will be use SwarmSpawn for spawn bots. By the way, for me the bots names are changed a lot correctly if in "DefaultPlayerName" lines use Qty=1 instead of Qty=0.
MrLoathsome wrote:What is the largest ini file any of you may have come up with while testing this so far? The 1024 max number of Swarms in Preview Release II is WAY too big. For a variety of reasons.
It is technically necessary to limit to 64 lines? In my opinion - better have fewer ini-files in the UT root directory. Therefore, I would leave the opportunity to work with large number of lines in SwarmSpawn ini, may well come in handy.
RUSSIAN DESCENT OUTPOST

User avatar
Barbie
Godlike
Posts: 1727
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by Barbie » Fri Jun 10, 2016 8:50 pm

PVS wrote:SwarmInfo[0] not rigidly related to SwarmInfo[1]
I'd solve that in that way, that only one instance is responsible for name changing. If a SwarmInfo is spawned it looks for another instance and stores it, if exist. Any name change then is done by this "base" SwarmInfo.
--Just an idea.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

MrLoathsome
Inhuman
Posts: 958
Joined: Wed Mar 31, 2010 9:02 pm
Personal rank: I am quite rank.
Location: MrLoathsome fell out of the world!

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by MrLoathsome » Sat Jun 11, 2016 3:58 am

@PVS

What value are you using for the CheckRate in this test?

You may need to increase it in order to give the engine to have time to process the settings triggered by the previous line.

CheckRate IS your delay variable. But since this thing processes 1 line at a time, the list gets processed at CheckRate * the number of "Active" swarms.

Barbie has figured out how this can be configured I think. (Or at least is on the right track. :mrgreen: )

I still haven't figured out all the ways this could be used. Testing everything this can do is not going to be possible. :ironic2:

You will have your Main instance of SwarmSpawner that will most likely handle any "SpawnOnce" items, actor replacements or other settings you are doing.
Then you can have that instance spawn a clone that could handle the spawning of the bots and setting their names etc with a different CheckRate.
It could also spawn a 3rd clone to handle the spawning of monsters at yet another CheckRate.
And a 4th, or 5th clone etc, to handle tweaking of weapons/game settings, or spawning of destructible decorations, or more monsters, all at different CheckRates in real time.

Unless you have bRandMode="True", SwamInfo[0] WILL be rigidly related to SwarmInfo[1] in a case such as this where SwarmInfo[0] is setting a class default value and
then SwarmInfo[1] is spawning an actor of that class.

It makes no validation or checks on the CheckRate you supply. 0.01 or anything below that will have it processing 1 line each tick. 1.0 should be 1 line each second.
(More or less, maybe, sorta.... approximately...)
Surprisingly it did not crash when I tested with insanely low values, but it is a waste of CPU time. You will want to set this as high as possible so that is still getting what
you want it to do accomplished in real time without wasting time doing lots of checks where it finds nothing to do.
And higher values are more likely to let the engine apply the previous setting before your next line is processed.

Timing is indeed one technical issue behind why I will be reducing the maximum lines to 64.

If you have an ini with 60+ lines each spawning a monster or swarms of monsters, and a low CheckRate, you are going to just crash or bog down your game quick due to the amount
of stuff being spawned. But if you have everything all in 1 ini file, and do get a large number of lines in there it will just process the list too damn slow.

I took a brief look at having a SpawnDelay setting for each line. Although that is probably technically possible it is just a horrible solution I think.
Implementing that would instantly bloat the mutator up considerably and slow it down in every way I can think of. (I think it runs fast atm....)

Having a few extra ini files is going to be worth it in this case I think.

Think I got the code done. Just need to run a few more tests, and come up with some good example ini files with detailed explanations and there
will be an update.
blarg

User avatar
PVS
Novice
Posts: 16
Joined: Fri May 27, 2016 6:41 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Post by PVS » Sun Jun 12, 2016 2:22 am

Sadly, but I think - I can not properly understand / translate what you guys mean... The only thing for which I use SwarmSpawn - spawn bots, I understand that this is not his main purpose. Spawn monsters, weapons, items, etc. - it is another task for which the SwarmSpawn is written.

I try different CheckRate options of course, but it does not help for this task. I think, I understand how SwarmSpawn works and CheckRate not can help for spawn bots task. I'd rather wait for the latest version for tests and to speak correctly.
RUSSIAN DESCENT OUTPOST

Post Reply