Page 6 of 7

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Sun Jun 19, 2016 12:06 am
by sektor2111
MrLoathsome wrote:Sometimes, you will still need to use that.
Huh ? I'll burn it alive, Watch this:

Code: Select all

function (stupid) tick (Float WC)
{
  if (bDeleteMe)
    GoTo BottomOfSea;
  if ( Something == None )
   AccessSomething(); //Trendy code
   bIsFancy=True;
.... //other bullshit codes

BottomOfSea: //No lines beyond this point just close it
}
I have already defined regenerators different and the rest of returns have been morphed to "LabelBottomDestination". Those stupid MonsterSpawn pawns when gets damage from a kill zone don't even call "Level.Game.Killed" and randomly server is magically quitting because of return's insanity - happens like it is stopped by a hidden admin. If I look well Pawn dead and supposed to be eliminated is using return and such cases. The rest I believe is blabbering... I'm hoping to wrong but... I have already encountered mutator stuck at using return excessive in mutate command - I won't go that way anymore.
Of course, Iterators need a little cheap hack.

Code: Select all

Function Something(Actor A)
{
foreach AllActors (class 'Actor', A)
{
    if (A.ISA('Freak'))
    {
       bFound=True;
       break;
    }
}
if (bFound)
   GoTo EndOfWar;
...
OtherCraps();
...
EndOfWar:
}

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Mon Jun 20, 2016 6:02 am
by MrLoathsome
Good stuff there Sektor. :tu:

There is of course more than one way to "Burn that Alive". :mad2: :mad2: :mad2:

Here is how to do it without a GoTo statement:

Code: Select all

event Tick(float DeltaTime)
{
	if ( ThePlayer == none || ThePlayer.bDeleteMe )
	{
		Destroy();
//		return;    // return statment Burned Alive per Sektor's request.
	} else {   **  All Your Tick Stuff Here **  }
}
This way requires the addition of one "else" and 2 brackets. 6 characters.
"return;" is 7 characters. "Goto + a reasonable label name" is probably more than 7 characters. I win! :lol: :lol2:

Does it execute faster than a Goto statement? Are there advantages or disadvantages to either?
Only Wormbo knows.... :agree1:

Although this is a bit off-topic, I like it. Good way to kill a bit of time while waiting for feedback on Preview Release III.

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Mon Jun 20, 2016 6:10 am
by sektor2111
Agree with this way, yes, you have won. :wink:

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Mon Jun 20, 2016 8:19 am
by Barbie
sektor2111 wrote:get rid of "return;"
Anything wrong with that? oO

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Mon Jun 20, 2016 8:52 am
by sektor2111
Like I said... I screwed up some mutate command when I've been toying with a mutator + see MonsterSpawn behavior on some test sessions...
I made return, return, return, and suddenly mutate was refusing to cooperate - let me guess, I have triggered a return address from a stack. While I see UT related stuff, Pawn has return when health < 0 and NOT in other case of taking damage.
I'm not trying to inject a new rule, I'm just saying that for me "return;" won't be used an longer from now on because I see 2 times stuff getting rammed.

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Mon Jun 20, 2016 10:39 am
by MrLoathsome
Maybe try your mutator with something other than MonsterSpawn to add monsters? (If you could find such a thing somewhere... :what: )

Not that I have ever noticed anything wrong with MonsterSpawn. Used it for years and years. Still use it AND SwarmSpawn at the same time on one
of my servers.

Perhaps you will have different results as there are probably differences in how they both do things.
Or perhaps you should just use "return" in moderation? Like with Vodka. :barf:

Or perhaps you have found some quirk in UT that only shows up under some conditions.

Or perhaps UT has found some quirk in your mutator. :roll:

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Mon Jun 20, 2016 11:21 am
by Barbie
It seems that there will be at least one "return" in every function - used as function termination. Have a look at this example of DC-Pawns2.Shooter.Trigger:

Code: Select all

function Trigger( actor Other, pawn EventInstigator ) {
	if( EventInstigator==None || EventInstigator.IsA('ZombiePawns') )
		Return;
	EnemyTriggerer = EventInstigator;
	GoToState('Active');
}
It is compiled to
ByteCode.jpg
where the opcode 0x04 is "Return" and 0x0B is "Nothing". I've underlined these with red.

PS: Maybe open a separate thread for this?

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Mon Jun 20, 2016 12:58 pm
by sektor2111
So are two different opcodes after all.

Else I know what I saw in that mutate command. When I removed return it was working normally all the time.
Barbie wrote:PS: Maybe open a separate thread for this?
Agree...

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Wed Jun 22, 2016 4:08 am
by Barbie
Another remark for checking if a spawn() was successful:

Code: Select all

function bool SpawnPawn(class<Actor> aC, Vector Location, int SwarmNum) {
...
tP.AActor = Spawn(aC,,,Location);
if (tP.AActor == None)
	// omg, spawn faild
If another mutator has replaced that Actor, the condition »tP.AActor == None« will be true although something has spawned. So this is not a reliable test if a spawn was successful; it's just a test if the actor you may have spawned still exists.

A possible solution could be that you catch your fresh spawned Actor in IsRelevant(), which it is called before CheckReplacement(), set the properties there and finally set a global variable that informs your SpawnPawn() that the work has been done - or not.

(I run into that problem with patching maps in a very late state where Actors could not be found by name because my mutator has replaced them earlier.)

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Thu Jun 23, 2016 2:59 am
by MrLoathsome
I will look at that when I get around to touching up the final.
Currently the actual spawning routines in PR III seem to be working very well.

If another mutator is causing problems via replacements, you could try using the SwarmSpawn's new
bReplace option.

I was hoping for a bit of feedback regarding if anybody has discovered any problems with bReplace
or using this to spawn other mutators ect.
Of if anybody has seen it produce an Accessed=None error in the log. :evil:

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Thu Jun 23, 2016 2:30 pm
by sektor2111
The older version which I was using has made me to rewrite some stuff. While I was trying to use Brutes in CTF-Coret log file was pretty nasty in that time. I said, when you'll get it finished I'll do a conversion for a state type mutator. I got rid of the most timers used, and things are acting different now - so to speak I like this way.

Re: SwarmSpawn v2.0 - UT99 Preview Release II

Posted: Thu Jun 30, 2016 3:40 am
by Barbie
MrLoathsome wrote:Took an even closer look and determined that the native code triggers event FellOutOfWorld() when the (Actor.Region.ZoneNumber == 0).
Just found that in the wiki, too:
wiki wrote:FellOutOfWorld ( )
This is called when an actor enters zone 0. Zone 0 is the region of non-subtracted space in your level. Actors can enter this zone through BSP errors or if they are of a type that does not collide with the world.

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Thu Jun 30, 2016 5:46 am
by sektor2111
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.

Aside a bit:
Here comes the myth with some EndPoint of inventorySpot good for kids and believers which was heading to place Ammo around walls in the most of stock Levels. Actually an InventorySpot is like a PathNode for pawns Seekers and if you try to fool me then I'll point finger to MHBotyman and Botyman tools (which can be improved of course) and which are proving that Navigation has a another criteria of functionality. Okay, and then because of these stock type ammo placed nearby walls and dropping hordes behind normal play-zones I have added that slow check in order to gain SAFETY of a good spawn. Using XCGE things are improved a lot... so monsters brought in game won't camp behind a crappy wall totally isolated.

The rest of old errors were coming from some collision debate for a Pawn which never spawned, example (Behemoth, Titan in maps style CTF-Coret and similar from 300K contest). I got bad lags and then I have checked logs. I had to fix those things so an update with old code for me is a fallback which I don't need. Code changed exist is NsTDM3 so other zone 0 discussions are pointless since problem has been solved for a couple of months.

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...

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.

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Sat Jul 16, 2016 10:29 pm
by MrLoathsome
Barbie wrote:Another remark for checking if a spawn() was successful:

Code: Select all

function bool SpawnPawn(class<Actor> aC, Vector Location, int SwarmNum) {
...
tP.AActor = Spawn(aC,,,Location);
if (tP.AActor == None)
	// omg, spawn faild
If another mutator has replaced that Actor, the condition »tP.AActor == None« will be true although something has spawned. So this is not a reliable test if a spawn was successful; it's just a test if the actor you may have spawned still exists.

A possible solution could be that you catch your fresh spawned Actor in IsRelevant(), which it is called before CheckReplacement(), set the properties there and finally set a global variable that informs your SpawnPawn() that the work has been done - or not.

(I run into that problem with patching maps in a very late state where Actors could not be found by name because my mutator has replaced them earlier.)
If you have another mutator running that replaces actors OR are using the SwarmSpawner's new bReplace option to replace an actor that you are also having
SwarmSpawner add more of, this is user error. This is an ini configuration issue. If you want more of that specific actor, use SwarmSpawner to add more of
the replacement class, NOT the class that is being replaced.

SwarmSpawner does NOT override CheckReplacement(); :roll:

Re: SwarmSpawn v2.0 - UT99 Preview Release III

Posted: Sat Jul 16, 2016 11:03 pm
by MrLoathsome
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..... :roll: It was however an issue. :loool:
This no longer spawns actors that "Fell out of the World!". 8)
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..... :what:
Only an insane idiot would think otherwise..... :omfg: