MHGen - Tool for automatically place monsters on Monsterhunt map

[Buggie]

- Travel over lifts (only with properly setup LiftExits)
- Travel over warpzones.
- Not place monsters in vacuum zones.

Updated at first post: viewtopic.php?f=5&t=15125

[Buggie]

- Prevent stuck in endless loop.

Updated at first post: viewtopic.php?f=5&t=15125

[OjitroC]

As a matter of interest, what kind of 'things' in or about a map would prevent MHGen from actually generating 'monsters' in a map?

In a couple of the Single Player maps I tried it on, after removing those actors related to SP, it worked but did not actually place any monsters though it reported there were a number of spots where monsters could have been placed (the number of spots reported were few compared to the size of the maps though the maps themselves were not overly large and it has worked fine in larger maps).

[Buggie]

Map filled with spots by travel actors. If actor not able travel somewhere, then there no spot, no monsters.
If you suspect not full coverage map with spots - turn on debug and look where spots stops appear.
if you need connect two locations for travel on place spots - place LiftExit in both parts and set same LiftTag for them.
This lead to continue fill by travel from one LiftExit to another.

Monsters placed only on Level 0. This mean travel without jump up or down. If on travel need jump somewhere, monster can be placed only at edge.

LiftExit travel work only for Level 0 too.

[Buggie]

- Fix place gasbags on open air.

Updated at first post: viewtopic.php?f=5&t=15125

[Buggie]

- Set Tag of spawned monster to Class.Name.

Updated at first post: viewtopic.php?f=5&t=15125

[sektor2111]

- Set Tag of spawned monster to Class.Name.

Probably not needed... either way "ThingFactory"...

Code: Select all

class ThingFactory extends Keypoint;
...
...
function PostBeginPlay()
{
	local Spawnpoint newspot;
	
...
...
	if (itemtag == '')
		itemtag = 'MadeInUSA';
}	

Pretty wrong if server is hosted in Germany... .

[Barbie]

- Set Tag of spawned monster to Class.Name.

Probably not needed...

Not really needed, but can be useful. We already had this topic somewhere; I've written Buggie a PM:

I'd like to have the tags, because (I guess) that selecting Actors by name AND tag is faster than by name only. I use "FindActorByName()" very often in my MapPatcher.

Should I make a time measuring searching with and without actor tag?

[sektor2111]

Should I make a time measuring searching with and without actor tag?

Nope, it's logic.

[OjitroC]

I have noticed that the tool will place monsters 'beyond' BlockAll actors. I used it on the map UKTown (mh-uktown.zip) which has BlockAlls to stop players going beyond the playable area of the map where there are non-solid buildings as a backdrop/background to the main area. Monsters were placed in this non-playable area. I removed the BlockAlls (or most of them anyway) so I could get everywhere.

I merely raise this 'issue' - I'm not sure how important it is (though on the whole I would think it is not particularly desirable that this happens) nor whether it is something that can be taken into account by MHGen?

[Buggie]

UnrealEd run only partially environment of game. Look like collision hash for actors not work. Same as Moving brush tracker. All of this leads to impossible detect collision with blocking actors for any builders.

[sektor2111]

I see that I have valid reasons to remove these assets which it looks like not all of them can be compiled in my machine - because of recent "fixes". I don't get what was compiled here and How, what linkers are messed up or they are not. When this MHGen is loaded, this is what's happening with that "Boulder1" stupid stock mix.

And this is class-tree Without MHGen...

So far none of my builders do these Goblin specific reactions...
Simply a "NoName" Decoration was going into Projectile Tree and me one, I cannot figure why does this happens.

A few months ago when I worked to another Server-Dedicated UnrealI.u package (fixing and conforming several things) I had to remove BotPack from Editor resources because it was doing errors concerning type Mismatch - Decoration Vs Projectile...

[Buggie]

Look like you got consequences when play with MonsterHunt.u conform.
There must be MonsterHunt items.

scr_1651903200.png (15.12 KiB) Viewed 645 times

[sektor2111]

Nah, it's BotPack with similar "Boulder1" name. Even if I'm removing all builders but Editor loads BotPack, "Boulder1" projectile is listed from BotPack going into a wrong tree - it's Decoration 24/7.

Right now I have removed all dependencies from MapGarbage with BotPack. Editor is opened, no BotPack is loaded and then... Boulder1 is class UnrealI.Boulder1... so right now all operations for UnrealI are doable - without BotPack. All checks and tests doable right now are no longer linked with Botpack, doh... red FlagBase changes, AlternatePath picking simulator, DefensePoints checks, Kicker tweaks, etc - all options are available but MapGarbage won't have any linker at BotPack. All is based on Engine, Core, UnrealI, UnrealShare and compiling using older solutions pointed by Higor for preventing packages dependencies and no MonsterHunt package is triggered here.

MonsterHunt used is old - a clean compiled one not conformed with anything - I did some tests a few minutes ago without any MonsterHunt. When Editor has no BotPack class Boulder1 is projectile or else it goes as decoration under Projectile Tree. Right now I understand what a misery was done with these "names".

Here UT469b has a PLUS - Projectile is projectile, with or without BotPack...

In 440 is difficult to get these wrapped... When BotPack is listed in EditPackages...

Edit: Bingo ! It looks like the order of these EditPackages is affecting these classes...

[OjitroC]

The 469b Editor makes it clear which Boulder1 is which?