SwarmSpawn v2.0 - Final(Not)

Search, find and discuss about Mutators!
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!

SwarmSpawn v2.0 - Final(Not)

Post by MrLoathsome »

OK. This is now working the way I want it too. (I hope.... :omfg: )
It now works with U1 227.

Code: Select all

5:03 PM 7/12/2016  -  SwarmSpawn v2.0 - Final.   By MrLoathsome

Mutator spawns Actors into your games.  (Most of them, Most actors and Most games...)

Can also make almost any change that you could do with a Set command.

Install:  Place all the int, ini and u files into your UnrealTournament/System directory.

Use:  Select mutators "Loathsomes UT Tweak" (UT2U1), and SwarmSpawn v2.0 and play.
*Make sure the Loathsome UT Tweak is first in the mutators list.
**The Loathsomes UT Tweak is only required for this when you are spawning U1 weapons or Pickups/Inventory.
(Although if you are running UT you should use it all the time.   It is not needed for U1/227.)


The SwarmSpawn code has been completely reworked for v2.0.
Too many optimizations to list.  (Again...)
It will now skip over bad lines or lines with bad classes in the ini and continue processing the file.

-----------------

*Changes for v2.0 Final:

Now only supports up to 64 SwarmInfo lines in the ini.
(With 16 optional SSet= variables for each.)

5 SwarmSpawn "Clones" are included.   (SSx2 - SSx6)
SwarmSpawn can spawn those if you need more than 64 lines and/or different
CheckRate settings for multiple config files.

Many improvements to the info provided in your logfile if bDebugMode=True

bRandMode option added.

Can now spawn multiple functioning mutators.

The SDS option for each line will now also adjust the PickupViewScale option if applicable.

-----------------------------

Basic SwarmSpawn.ini file configuration example:
---------
[SwarmSpawn.SS]
CheckRate=3.33		// Checks one active swarm every 3.33 seconds.  Valid range varies upon the size of your list....
bDebugMode=True		// Will dump a LOT of info into your log file.  Recommend set False once your ini file is working.
bRandMode=False		// Randomly check the list of "Active" swarms after all Init processing is complete.  (If True...)
SwarmInfo[0]=(SwarmClass="Botpack.SuperShockRifle",Qty=2,bSpawnOnce="True",SSet0=(SName="Respawntime",SVal="2.0"))
SwarmInfo[1]=(SwarmClass="UnrealShare.Cow",Qty=4,SSet0=(SName="LifeSpan",SVal="120.0"))
SwarmInfo[2]=(SwarmClass="UnrealShare.Barrel",Qty=4)
SwarmInfo[3]=(SwarmClass="UnrealI.Pupae",Qty=6,SDS=0.60,bHorde="True")
--------

SwarmInfo[0] in this example will spawn 2 SuperShockRifle's at random locations on the map.  The bSpawnOnce option should
be set True for most weapons or other pickups.   That way they will respawn at the same location for
the duration of the level, and will also be excluded from the list of items to check for respawning by the
mutator.   The optional SSet0= variable sets them to respawn in 2 seconds.

SwarmInfo[1] will spawn NaliCows, 1 each pass thru the list.   The optional SSet0= entry there
makes them vanish after 2 minutes.  (Sorta like MonsterSpawn, but without the sound/visual effects.)

SwarmInfo[2] will spawn wooden barrels.   When they get destroyed, SwarmSpawn will add them back at a random location.

SwarmInfo[3] will spawn swarms of 6 pupae at a time.  They will be at 60% of normal pupae size.  (SDS = SwarmDrawscale)
The bHorde="True" option will cause the mutator to try and spawn the entire QTY in one group.  Or as many as are needed, if some
are still surviving from the previous spawn.

Recommend keeping SwarmInfo.Qty LESS than 250.  Higher values can fool the engine into thinking infinite loops are happening.
(Which they aren't....)  
If you want more than 250 spawned, use 2 or 3 lines to add them.

*Spawning mutators.

In order for this to successfully spawn a mutator class and get it added to the mutator chain correctly you
must have that SwarmInfo line written like this:

SwarmInfo[8]=(SwarmClass="BN4.BN",Qty=1,bSpawnOnce="True",bIsMut="True")
SwarmInfo[9]=(SwarmClass="BMSG.BM",Qty=1,bSpawnOnce="True",bIsMut="True")
SwarmInfo[10]=(SwarmClass="SSx2.SS",Qty=1,bSpawnOnce="True",bIsMut="True")

You MUST have bSpawnOnce="True",bIsMut="True" options set in the line for this to work.

Note included SSx2 and SSx3 examples.  (SSx4, SSx5, and SSx6 mutators also included, but no ini files....)

The SSxN "clone" mutators are IDENTICAL to SwarmSpawner, except for the name, and the name of its ini file.
Has to be done this way.   If you try to use SwarmSpawner to spawn a copy of itself, the results are not good.
Each copy needs to have its own, private ini file.

If you need even MORE options for CheckRates/lists etc do the following:

1.  Copy the SSx2 folder to SSx7  (or whatever)
2.  Edit the SS.u file in the Classes folder.   Do 1 global Find/Replace.  Replace "SSx2" with "SSx7".
3.  Save the file and compile.

You now have another copy of the thing that you can spawn with the others.

If you play around with running multiple copies of it in this way, be SURE that you do not
configure your ini files in such a way as to create a loop.  (You will find out quick if you do....)


The bReplace option:

SwarmSpawner now also includes a global replace option.   It will also allow you to adjust settings
for your replacement actor/class.

Your SwarmClass will be the replacement class.   The value for SName in SSet0 will be the name of the class you are replacing.
You can use the other optional SSet entries to adjust settings for the replacement class.

These 2 lines will replace all RocketLaunchers and Rocket ammo on the level with Stingers and Stinger Ammo:

SwarmInfo[0]=(SwarmClass="UnrealShare.Stinger",Qty=0,bSpawnOnce="True",bReplace="True",SSet0=(SName="Botpack.UT_Eightball",SVal=""))
SwarmInfo[1]=(SwarmClass="UnrealShare.StingerAmmo",Qty=0,SDS=0.750,bSpawnOnce="True",bReplace="True",SSet0=(SName="Botpack.RocketPack",SVal=""),SSet1=(SName="bRotatingPickup",SVal="True"))

You do want to set Qty=0,bSpawnOnce="True",bReplace="True" for this to work.

Be sure you do not have SwarmSpawner adding classes that you are also replacing via another mutator or SwarmSpawner
itself.   If you do this, you may end up with LOTS of extra actors.  This can be avoided by configuring your ini
files correctly.



Included example ini files:

SwarmSpawn.ini - This will spawn 4 U1 bots into your game and attempts to get their names set.
It also loads 3 mutators.   BadNews4, a slightly updated version of BMSG.BM and SSx2.

SSx2 spawns a few items on its timer, and also makes a few minor gun adjustments and replaces the RocketLaunchers and Ammo with Stingers.
And also loads the SSx3 mutator.

SSx3 contains 4 lines that will adjust the ammo used by all stingers on the map every 10 seconds.

SwarmSpawn_SkaarjWeaps-UT.ini - This will add 5 Skaarj with UT guns and 5 Skaarj with U1 guns into your game.

SwarmSpawn _SkaarjUTWeaps_227.ini - This is for use with Unreal 227.  This adds 5 Skaarj with UT guns into your U1 game.

SwarmSpawn_Zombies5.ini - Adds a bunch of Zombies to your game if you have the Zombies5 package.

SwarmSpawn_Titans.ini - Attempts to get 24 Titans of various sizes into your maps.  This is a good test of the performance increase with
this latest SwarmSpawn version.

Enjoy!

Big thanks to all of you who have been testing or offering suggestions for this.
The feedback has been a huge help in getting this finished up.
You do not have the required permissions to view the files attached to this post.
Last edited by MrLoathsome on Fri Aug 12, 2016 4:06 am, edited 5 times in total.
blarg
User avatar
OjitroC
Godlike
Posts: 3746
Joined: Sat Sep 12, 2015 8:46 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by OjitroC »

I used this in five or six games on different maps, first with your SwarmSpawn.ini (minus the boulders after the first go) and then with a modified .ini with different monsters. Everything worked well - checked the log after each game and found nothing untoward. Haven't yet tried altering the projectile classes of the weapons but will do that later. The mutator certainly opens up a wider range of possibilities for altering various properties in going beyond the previous version. So thanks for this.

It might be worth noting, although perhaps it is obvious, that it is crucial not to make typing errors in the .ini - when modifying the .ini I got a monster class name wrong and nothing at all spawned when I started the map.

The only way, at the moment, to use different configurations of monsters, weapons or whatever is to set up multiple versions of SwarmSpawn.ini (giving them different names or saving them in a location other than Unrealtournament\System) and then use whichever version one wants to in a particular map by renaming it SwarmSpawn.ini. I wonder how possible it might be to have a simple interface in the mod menu, with a list of SwarmSpawn.ini files (named SwarmSpawn0.ini, SwarmSpawn1.ini, etc) from which one can choose the .ini to use? In essence the mutator would search the \System folder, looking for files named SwarmSpawn*.ini and list them. Just a thought - I have no idea how easy or difficult this might be to achieve.
User avatar
FXANBSS
Skilled
Posts: 231
Joined: Thu Dec 26, 2013 7:03 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by FXANBSS »

This topic can fit better in UnrealSP.org, guys loves monsters there.


TRIVIA: Did you know that in EXU2, there are over 600 custom monsters? You CAN'T put all them in your mutator, but don't worry, we have different monster spawning mutators, like the MonsterSpawn 304.
BTW, i use SwarmSpawner and MonsterSpawn for maximun Insanity.

Talking about EXU2, there is a new G59, now you can update it, for your server.
Here is the topic to save your time:
http://unrealsp.org/viewtopic.php?f=37&t=3984


Oh, check how insane is my config. Oh yeah. Needs some SSet stuff but it's for later.

Code: Select all

[SwarmSpawn.SS]
CheckRate=20
bSpawnAtStart=False
SwarmInfo[0]=(SwarmClass="Jigoku.G59AdvancedSkaarjFiend",Qty=66)
SwarmInfo[1]=(SwarmClass="Jigoku.G59Agidyne",Qty=99)
SwarmInfo[2]=(SwarmClass="EXU.DemonSkaarjMaster",Qty=66)
SwarmInfo[3]=(SwarmClass="EXU.SuperCharger",Qty=33)
SwarmInfo[4]=(SwarmClass="Jigoku.G59RoyalDemonSkaarj",Qty=99)
SwarmInfo[5]=(SwarmClass="FXBPawn.FXBSunBarrelSlith",Qty=3)
SwarmInfo[6]=(SwarmClass="Jigoku.G59TonatiuhMH",Qty=3)
SwarmInfo[7]=(SwarmClass="Jigoku.G59RoyalDemonSkaarjLord",Qty=77)
SwarmInfo[8]=(SwarmClass="Jigoku.G59MagatsuBot",Qty=33)
SwarmInfo[9]=(SwarmClass="Jigoku.G59MagatsuBotAlpha",Qty=33)
SwarmInfo[10]=(SwarmClass="Jigoku.G59MagatsuBotBeta",Qty=33)
SwarmInfo[11]=(SwarmClass="Jigoku.G59MagatsuBotOmega",Qty=33)
SwarmInfo[12]=(SwarmClass="Jigoku.G59Morax",Qty=5)
SwarmInfo[13]=(SwarmClass="Jigoku.G59MagatsuNova",Qty=55)
SwarmInfo[14]=(SwarmClass="Jigoku.G59MagatsuGuardian",Qty=66)
SwarmInfo[15]=(SwarmClass="Jigoku.G59DactylCore",Qty=33)
SwarmInfo[16]=(SwarmClass="Jigoku.G59MoraxII",Qty=4)
SwarmInfo[17]=(SwarmClass="Jigoku.G59ErisI",Qty=3)
SwarmInfo[18]=(SwarmClass="Jigoku.G59ErisII",Qty=3)
SwarmInfo[19]=(SwarmClass="Jigoku.G59ErisIII",Qty=3)
SwarmInfo[20]=(SwarmClass="Jigoku.G59Naberius",Qty=2)
SwarmInfo[21]=(SwarmClass="Jigoku.G59NaberiusCoop",Qty=2)
SwarmInfo[22]=(SwarmClass="Jigoku.G59TheBlackKnight",Qty=3)
SwarmInfo[23]=(SwarmClass="Jigoku.G59Tonatiuh",Qty=3)
SwarmInfo[24]=(SwarmClass="EXU.Archdemon",Qty=4)
SwarmInfo[25]=(SwarmClass="EXU.HellFighter",Qty=5)
SwarmInfo[26]=(SwarmClass="EXU.HarmonicDisruptor",Qty=4)
SwarmInfo[27]=(SwarmClass="EXU.Hellbomber",Qty=2)
SwarmInfo[28]=(SwarmClass="EXU.Thunderhead",Qty=2)
SwarmInfo[29]=(SwarmClass="EXU.Firefucker",Qty=1)
SwarmInfo[30]=(SwarmClass="EXU.BarrelSlith",Qty=11)
SwarmInfo[31]=(SwarmClass="EXU.LargeMargeMerc",Qty=11)
SwarmInfo[32]=(SwarmClass="EXU.FourHundredthPawn",Qty=4)
SwarmInfo[33]=(SwarmClass="Jigoku.G59BaalBerith",Qty=1)
SwarmInfo[34]=(SwarmClass="EXU.FusionAnnihilator",Qty=5)
SwarmInfo[35]=(SwarmClass="EXU.ExtremelyExtremeShockBerserker",Qty=11)
SwarmInfo[36]=(SwarmClass="EXU.AdvancedDoomOrbSB",Qty=2)
SwarmInfo[37]=(SwarmClass="EXU.SniperCharger",Qty=11)
SwarmInfo[38]=(SwarmClass="EXU.VerminBagger",Qty=7)
SwarmInfo[39]=(SwarmClass="EXU.ShadowCreature",Qty=99)
SwarmInfo[40]=(SwarmClass="EXU.ShadowManta",Qty=99)
SwarmInfo[41]=(SwarmClass="EXU.ShadowSquid",Qty=99)
SwarmInfo[42]=(SwarmClass="EXU.BigShadowCreature",Qty=22)
SwarmInfo[43]=(SwarmClass="Jigoku.G59Hastur",Qty=3)
SwarmInfo[44]=(SwarmClass="Jigoku.G59RoyalSkaarjFiend",Qty=66)
SwarmInfo[45]=(SwarmClass="EXU.RageReactor",Qty=3)
SwarmInfo[46]=(SwarmClass="EXU.BiohazardBomber",Qty=2)
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by sektor2111 »

OjitroC wrote:Haven't yet tried altering the projectile classes of the weapons but will do that later.
You might forget this if you don't know weapons, some of them have hard-coded projectiles ignoring properties, so good night
OjitroC wrote:The only way, at the moment, to use different configurations of monsters, weapons or whatever is to set up multiple versions of SwarmSpawn.ini (giving them different names or saving them in a location other than Unrealtournament\System) and then use whichever version one wants to in a particular map by renaming it SwarmSpawn.ini. I wonder how possible it might be to have a simple interface in the mod menu, with a list of SwarmSpawn.ini files (named SwarmSpawn0.ini, SwarmSpawn1.ini, etc) from which one can choose the .ini to use? In essence the mutator would search the \System folder, looking for files named SwarmSpawn*.ini and list them. Just a thought - I have no idea how easy or difficult this might be to achieve.
Source code is there so you can do what I did: SwarmSpawn_1, SwarmSpawn_2,... SwarmSpawn_X. What can do a MENU in a dedicated server ? Nothing, it's useless.
User avatar
OjitroC
Godlike
Posts: 3746
Joined: Sat Sep 12, 2015 8:46 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by OjitroC »

sektor2111 wrote:Source code is there so you can do what I did: SwarmSpawn_1, SwarmSpawn_2,... SwarmSpawn_X.
Thanks for that, I'll give it a try.
sektor2111 wrote:What can do a MENU in a dedicated server ? Nothing, it's useless.
TBH I don't play on-line so was only thinking about it for off-line use.
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

Post by MrLoathsome »

sektor2111 wrote:
OjitroC wrote:Haven't yet tried altering the projectile classes of the weapons but will do that later.
You might forget this if you don't know weapons, some of them have hard-coded projectiles ignoring properties, so good night
sektor2111 is quite correct.

For example:
While both the UT_Eightball and UT_Flakcannon have the ProjectileClass and AltProjectileClass variables defined and initialized, they do not
even use them and have the projectile classes hard-coded in the script.

SwarmSpawn will indeed set the variables to whatever you want, and it will look like it should work according to the debug log, but
those guns will just ignore the settings.

It probably wouldn't take much effort to expand the lists beyond 256 if needed.
Adding any menus for selecting or configuring ini files, would take a bit of work....

I sort of like it in its current lean and mean state.
blarg
User avatar
heliumcat
Skilled
Posts: 185
Joined: Mon Apr 01, 2013 11:47 am

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by heliumcat »

Is there a way to actually randomize the Swarm order, as in when the match starts the first Swarm spawning is not always "SwarmInfo[0]=..." followed by "SwarmInfo[1]=..." and so on?
User avatar
OjitroC
Godlike
Posts: 3746
Joined: Sat Sep 12, 2015 8:46 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by OjitroC »

heliumcat wrote:Is there a way to actually randomize the Swarm order, as in when the match starts the first Swarm spawning is not always "SwarmInfo[0]=..." followed by "SwarmInfo[1]=..." and so on?
I'm not sure but I don't think this would make a difference at the start of a match since, as far as I can tell, there is no noticeable difference in the spawning time between each swarm so that each swarm spawns more or less straightaway.

It might later on if the CheckRate could be set for each swarm or different Respawntimes are used for each SwarmClass.

-------------------------- Edit ---------------------------------------
@MrLoathsome
I have encountered a problem with the replacement projectiles for the Stinger and the RIpper in your sample ini - I set up a new ini with these weapons in and included a Stinger with the configuration in the ini (primary projectile razors and alt projectiles rockets) and one with the opposite configuration (primary rockets and alt razors). After working for a while in two or three maps, the projectiles ceased to be altered from the default projectiles for those weapons.

I have gone back to the original sample ini and used it in the same map that I first used it in. Now both the Stinger and the Ripper no long fire the altered projectiles.

I notice the following in the UT.Log of the last game I played
Spoiler
ScriptLog: SwarmSpawn: Swarm #15 UnrealShare.Stinger Needs: 1
ScriptLog: SwarmSpawn: DM-Halls_of_RedemptionV2.Stinger9 spawned....
ScriptLog: Attempted settings: DM-Halls_of_RedemptionV2.Stinger9 ProjectileClass Class'Botpack.Razor2
ScriptLog: Actual values: DM-Halls_of_RedemptionV2.Stinger9 ProjectileClass Class'UnrealShare.StingerProjectile'
ScriptLog: .
ScriptLog: Attempted settings: DM-Halls_of_RedemptionV2.Stinger9 AltProjectileClass Class'Botpack.RocketMk2'
ScriptLog: Actual values: DM-Halls_of_RedemptionV2.Stinger9 AltProjectileClass Class'Botpack.RocketMk2'

In the ini the relevant entry is
Spoiler
SwarmInfo[15]=(SwarmClass="UnrealI.Stinger",Qty=1,SSet0=(SName="ProjectileClass",SVal="Class'Botpack.Razor2"),SSet1=(SName="AltProjectileClass",SVal="Class'Botpack.RocketMk2'"))
An UnrealShare.Stinger is actually being spawned with the primary projectile the UnrealShare.StingerProjectile rather than the Botpack.Razor2. However, as I say, the altprojectile RocketMk2 wasn't spawned either.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by Higor »

Sometimes, the goal of having the projectile class on a variable, even if the weapon is hardcoded... is to tell bots and other pawns how to aim or what to expect after they shoot.
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

Post by MrLoathsome »

@Ojitro

Could you post the entire SwarmSpawn.ini file you were using at the time?
**Edit 2: Just looked at your SwarmInfo line there again, and see what your problems are.
1 it looks like you are missing a single quote there on the ProjectileClass line. (maybe not, my eyes are going bad...)

For Weapons and Pickup items that will automatically respawn, (most of them) you should have the bSpawnOnce="True"
option set. Not only does that enable them to be in the same spot for the duration of the level, but it also causes the
timer to just skip over those lines after all the Init stuff is done. The main timer also skips any lines with Qty=0 as they
are only executed during the Init.

Now if you DO want your extra weapons spawning at random locations during the match, you should use these 2 lines:

Code: Select all

SwarmInfo[15]=(SwarmClass="UnrealI.Stinger",Qty=0,SSet0=(SName="ProjectileClass",SVal="Class'Botpack.Razor2'"),SSet1=(SName="AltProjectileClass",SVal="Class'Botpack.RocketMk2'"),SSet2=(SName="bRotatingPickup",SVal="True"))
SwarmInfo[16]=(SwarmClass="UnrealI.Stinger",Qty=3,SSet0=(SName="Respawntime",SVal="0.0"))
Note by placing the Respawntime adjustment on the line that is spawning the 3 extra stingers, it should have no effect on any
stingers that are in the map by default. But the default guns should fire the changed projectiles, since that happens globaly
for the class via the Qty=0 option.

I had those Stinger/Ripper settings enabled for dozens and dozens and dozens of tests, and never noticed that
happening.

*Edit. Just got done with at least 15 matches on my DM test server. Stinger and Ripper settings never stopped working for me.
One of the maps was the DM-SpireVillageDemon-v3.unr map, which has all the default U1 weapons on it instead of UT guns.
The Stinger that is placed in the map by default also shot rockets and ripper blades, just as it should.

Only minor glitch I noticed with that was that not all of the Stingers spawned were rotating. So I added this: SSet2=(SName="bRotatingPickup",SVal="True")
Now they should all rotate, except in cases where the initial spawn of them falls out of the world and get added back by the timer code. Then they may
not rotate until they have been picked up once... (I think.)
Higor » Tue May 17, 2016 4:40 pm - Sometimes, the goal of having the projectile class on a variable, even if the weapon is hardcoded... is to tell bots and other pawns how to aim or what to expect after they shoot.
Higor makes a very important point here. Always think about what other aspects of the game your changes might have an effect on.
Some changes will work just as you want. Others might work, but may generate a few warnings in the log, or confuse the bots, or who knows what else.
That would depend upon the changes you are trying to make. This thing can easily be used to make changes that will crash your game or generate lots of
horror in the log file if unwise settings are used.

During testing, I found a cool way to crash the game every time with one of Higor and Smirftsch's favorite errors:
Spoiler
Critical: FCollisionHash::ActorLineCheck
Critical: CheckWithActors
Critical: ULevel::MultiLineCheck
Critical: ULevel::Trace
Critical: UObject::ProcessEvent
Critical: (SS DM-Curse][.SS0, Function SwarmSpawn.SS.Timer)
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=0)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UOpenGLRenderDevice::ShutdownAfterError
Exit: Exiting.
Just set a ParentBlobs bCollideActors and/or bBlockActors to true, and your game will crash with this most every time.
(Think just bCollideActors="True" is enough to do it....)
blarg
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by sektor2111 »

Yes, I did such timer...
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

Post by MrLoathsome »

sektor2111 wrote:Yes, I did such timer...
Indeed?

Did you glance at my timer code there? Did I do it right? :mrgreen:

Note how if your SwarmSpawn.ini file contains no "Active" swarms it will just turn off the timer
nicely after all the post init and timer post-post init stuff is done.
(It attempts to work with the tendency of some extra spawned actors to "fall out of the world".)

Another timer optimization is how it throttles back to checking at 4x the Checkrate if it doesn't need to spawn anything
after 2 passes thru the list of "Active" swarms.

The previous version of this, and the spawning mutator included with the Zombies5 still had a bunch of core code in the
SpawnSwarm() and GetSpawnPoint() functions that I had not looked at very close. Old functions from the original TWT zombies source that seemed to be working ok
before so I never messed with them.

I looked at them closer this time. Added log lines. They had much horror.
Multiple, redundant traces and collision checks. A double nested "do while" loop that had a re-try check in it that failed every time and did
ALL the checks 10 times for every pawn spawned. Twice sometimes... My closer look revealed an abomination. A crime against humanity even. :loool:

I replaced pretty much ALL that with 1 very close range RadusActors check, and some other tweaks. I think any "retry" code in there
is now working the way it should. (There is still a loop that happens if ((Qty > 1) && (SwarmInfo[x].bHorde)). Hard to spawn a Horde without a loop.....)

Pretty sure it also avoids spawning anything on a Mover, WaterZone or PainZone.
(Although things can/will sometimes still fall into the water/lava etc if they happen to spawn over/above them. Or get bumped in right after spawn...)

Come on sektor, look at that code and tell me where the craps are. I am counting on you. :tongue: :tu:

Any of you reading this who happen to be using the previous version, or even worse the mutator included with Zombies5, should
switch over to this ASAP. I will include some Zombies5 example ini files when I post the final of this thing.
blarg
User avatar
OjitroC
Godlike
Posts: 3746
Joined: Sat Sep 12, 2015 8:46 pm

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by OjitroC »

I've altered the original .ini I used quite a bit to try to identify what the problem is. However I tried the following ini this morning after several checks for typing errors

Code: Select all

[SwarmSpawn.SS]
CheckRate=0.66
bDebugMode=True
SwarmInfo[0]=(SwarmClass="Botpack.ripper",Qty=0,bSpawnOnce="True",SSet0=(SName="AltProjectileClass",SVal="Class'Botpack.flakslug'"))
SwarmInfo[1]=(SwarmClass="UnrealI.Stinger",Qty=2,bSpawnOnce="True",SSet0=(SName="ProjectileClass",SVal="Class'Botpack.Razor2'"),SSet1=(SName="AltProjectileClass",SVal="Class'Botpack.RocketMk2'"))
SwarmInfo[2]=(SwarmClass="UnrealI.Stinger",Qty=2,bSpawnOnce="True",SSet0=(SName="ProjectileClass",SVal="Class'Botpack.RocketMk2'"),SSet1=(SName="AltProjectileClass",SVal="Class'Botpack.Razor2'"))
SwarmInfo[3]=(SwarmClass="TKR_MonsterPack.SkaarjASMDInfantry",Qty=2,bSkipPreCache="True")
SwarmInfo[4]=(SwarmClass="TKR_MonsterPack.SkaarjBioInfantry",Qty=1,bSkipPreCache="True")
The altered Ripper works fine, firing flakslugs as the altprojectile. However the Stingers fire only the default projectiles and not any of the projectiles in SwarmInfo[1] and [2]. The relevant part of the UT.log is

Code: Select all

ScriptLog: SwarmSpawn: Begin Init - Spawnpoint count: 292  Number Swarms: 5
ScriptLog: SwarmSpawn: Swarm #0 Botpack.ripper
ScriptLog: SwarmSpawn: DM-Koy_Fitha.ripper1 spawned....
ScriptLog: Attempted settings: DM-Koy_Fitha.ripper1 AltProjectileClass Class'Botpack.flakslug'
ScriptLog: Actual values: DM-Koy_Fitha.ripper1 AltProjectileClass Class'Botpack.flakslug'
ScriptLog: .
ScriptLog: Destroying:  DM-Koy_Fitha.ripper1
ScriptLog: .
ScriptLog: SwarmSpawn: Swarm #1 UnrealShare.Stinger
ScriptLog: SwarmSpawn: DM-Koy_Fitha.Stinger2 spawned....
ScriptLog: Attempted settings: DM-Koy_Fitha.Stinger2 ProjectileClass Class'Botpack.Razor2'
ScriptLog: Actual values: DM-Koy_Fitha.Stinger2 ProjectileClass Class'Botpack.Razor2'
ScriptLog: .
ScriptLog: Attempted settings: DM-Koy_Fitha.Stinger2 AltProjectileClass Class'Botpack.RocketMk2'
ScriptLog: Actual values: DM-Koy_Fitha.Stinger2 AltProjectileClass Class'Botpack.RocketMk2'
ScriptLog: .
ScriptLog: .
ScriptLog: SwarmSpawn: DM-Koy_Fitha.Stinger3 spawned....
ScriptLog: Attempted settings: DM-Koy_Fitha.Stinger3 ProjectileClass Class'Botpack.Razor2'
ScriptLog: Actual values: DM-Koy_Fitha.Stinger3 ProjectileClass Class'Botpack.Razor2'
ScriptLog: .
ScriptLog: Attempted settings: DM-Koy_Fitha.Stinger3 AltProjectileClass Class'Botpack.RocketMk2'
ScriptLog: Actual values: DM-Koy_Fitha.Stinger3 AltProjectileClass Class'Botpack.RocketMk2'
ScriptLog: .
ScriptLog: .
ScriptLog: SwarmSpawn: Swarm #2 UnrealShare.Stinger
ScriptLog: SwarmSpawn: DM-Koy_Fitha.Stinger4 spawned....
ScriptLog: Attempted settings: DM-Koy_Fitha.Stinger4 ProjectileClass Class'Botpack.RocketMk2'
ScriptLog: Actual values: DM-Koy_Fitha.Stinger4 ProjectileClass Class'Botpack.RocketMk2'
ScriptLog: .
ScriptLog: Attempted settings: DM-Koy_Fitha.Stinger4 AltProjectileClass Class'Botpack.Razor2'
ScriptLog: Actual values: DM-Koy_Fitha.Stinger4 AltProjectileClass Class'Botpack.Razor2'
ScriptLog: .
ScriptLog: .
ScriptLog: SwarmSpawn: DM-Koy_Fitha.Stinger5 spawned....
ScriptLog: Attempted settings: DM-Koy_Fitha.Stinger5 ProjectileClass Class'Botpack.RocketMk2'
ScriptLog: Actual values: DM-Koy_Fitha.Stinger5 ProjectileClass Class'Botpack.RocketMk2'
ScriptLog: .
ScriptLog: Attempted settings: DM-Koy_Fitha.Stinger5 AltProjectileClass Class'Botpack.Razor2'
ScriptLog: Actual values: DM-Koy_Fitha.Stinger5 AltProjectileClass Class'Botpack.Razor2'
ScriptLog: .
ScriptLog: .
ScriptLog: SwarmSpawn: End Init - Number Active Swarms: 2
I then tried using just SwarmInfo[1] and [2] as above, with the same result - just the normal\default Stingers spawn. I also swapper the Skaarj Infantry to UT weapons carriers, thinking it might be something to do with the ones carrying Unreal Weapons, but the result was the same.

Perhaps previously I had two Stingers with different projectile configurations both with Qty=0 but that is no longer the case - I now understand that having a weapon with Qty=0 will alter all of that weapon placed in a map, as with the Ripper above, as well as any of that weapon in the SwarmSpawn.ini.

Maybe the problem is having two Stingers with different projectile configurations? Having either

Code: Select all

[SwarmSpawn.SS]
CheckRate=0.66
bDebugMode=True
SwarmInfo[0]=(SwarmClass="Botpack.ripper",Qty=0,bSpawnOnce="True",SSet0=(SName="AltProjectileClass",SVal="Class'Botpack.flakslug'"))
SwarmInfo[1]=(SwarmClass="UnrealI.Stinger",Qty=0,bSpawnOnce="True",SSet0=(SName="ProjectileClass",SVal="Class'Botpack.Razor2'"),SSet1=(SName="AltProjectileClass",SVal="Class'Botpack.RocketMk2'"))
SwarmInfo[2]=(SwarmClass="UnrealI.Stinger",Qty=3,bSpawnOnce="True")
SwarmInfo[3]=(SwarmClass="UnrealI.SkaarjGunner",Qty=1,bSkipPreCache="True",SSet0=(SName="WeaponType",SVal="Botpack.UT_FlakCannon"))
SwarmInfo[4]=(SwarmClass="UnrealI.SkaarjInfantry",Qty=1,bSkipPreCache="True",SSet0=(SName="WeaponType",SVal="Botpack.minigun2"))
or

Code: Select all

[SwarmSpawn.SS]
CheckRate=0.66
bDebugMode=True
SwarmInfo[0]=(SwarmClass="Botpack.ripper",Qty=0,bSpawnOnce="True",SSet0=(SName="AltProjectileClass",SVal="Class'Botpack.flakslug'"))
SwarmInfo[1]=(SwarmClass="UnrealI.Stinger",Qty=0,bSpawnOnce="True",SSet0=(SName="ProjectileClass",SVal="Class'Botpack.RocketMk2'"),SSet1=(SName="AltProjectileClass",SVal="Class'Botpack.Razor2'"))
SwarmInfo[2]=(SwarmClass="UnrealI.Stinger",Qty=3,bSpawnOnce="True")
SwarmInfo[3]=(SwarmClass="UnrealI.SkaarjGunner",Qty=1,bSkipPreCache="True",SSet0=(SName="WeaponType",SVal="Botpack.UT_FlakCannon"))
SwarmInfo[4]=(SwarmClass="UnrealI.SkaarjInfantry",Qty=1,bSk
works.
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: SwarmSpawn v2.0 - UT99 Preview Release

Post by sektor2111 »

Old code had troubles at Inventories, in stock maps the mostly are placed around walls, for this reason a lot of monsters were outside of game area, another measure was that trace-type check in order to gain the right zone. I used SwarmSpawn a lot and that's why I figured bad Levels occurrences. Looks like a Pawn has spawned at a moment, was added at a bad location, pawn attempting to be Moved and Removed (deduction) making timer to crash. Then deal was a bigger monster for pre-caching locations in order to no longer mess with a bad spot. To mention a reason for not using Inventories. PulseAmmo from NovemberCE, miniammo, those are spots which doesn't even worth an effort to get in precache, locations are simply too small to not speak about ShockCore/s behind that Box and HealthVial/s. I had 100+ reasons to remove InventorySpot from any spawning attempt.
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

Post by MrLoathsome »

@OjitroC

Interesting results. Will have to check into what is going on with that.
I would have thought that if there was a conflict of some sort with using different settings like that
on 2 different lines, that the last set of settings applied would just override the previous line.

Curious how all of them would revert to the defaults in this case. :???:

Those Actual values reported in the log ARE the values for those variable retrieved from
the actual spawned actor itself after the attempted settings are applied.

Maybe your log file is trying to deceive us all. :omfg: :?

For now I would just recommend only trying 1 set of modified values for each specific class.
If I track down a way to make separate ones work reliably that would motivate another update.
At which point I will also implement heliumcat's suggestion as that should be easy and is a good idea.

*Edit:

Ran a few more tests and stared at the code a bit. Looks like I screwed something up in the pre-cache bit so
it seems to only be processing the 1st SSet for each Swarm in some cases, which is causing these odd results.

Pretty sure I can get that corrected. We will find out. Stay tuned.
blarg