Dark Side of MonsterHunt mapping

Get some cool tips about how to tweak your UT graphic, gameplay, and much more!
Post Reply
User avatar
sektor2111
Godlike
Posts: 4075
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Dark Side of MonsterHunt mapping

Post by sektor2111 » Fri Feb 23, 2018 12:07 am

Audience: Mappers interested to setup custom stuff into MyLevel - aiming MH game-type, who passed default mapping way of doing.

Intro: If you say that adding actors in MyLevel for a MH map is simple as in a default DM I will tell you to forget this, especially if you are listening other "tutorials" saying to open MonsterHunt.u file for making your MH map. DO NOT open that package if you want to compile some stuff in MyLevel unless you have a good replacement for that original file in your modding/mapping copy of UT - NOT version used as Player :!: Original MonsterHunt.u file (version 503) will NEVER allow you to compile anything in Editor or outside of Editor.
MonsterHunt.u file can be opened ONLY if you have finished doing your custom actors else you'll screw up your work, so it is advisable to not have it defined as "EditPackages=MonsterHunt" as explained in "high-tech" type tutorials and neither in whatever "mapping" forum or such.

You can use another map as a temporary source with a MyLevel already done/compiled but I will tell you a secret(/or not a secret).
Temporary map A has a Weapon/Pawn with a custom skin also MyLevel-ed. If you want that stuff for your MH Map B you have to do some small stunts. You can select Pawn/Weapon from map A being prepared for transportation in your map B without closing Editor. This might NOT BE ENOUGH.
Editor when is switching maps uses to purge garbage. By chance it might purge SKINS/Sounds previously loaded in MyLevel if are not selected/referenced nowhere - not created in that session... In next moment if you add a MyLevel-ed actor with that skin/sound removed but referenced, Editor will freeze or will crash, and if you are forcing a map-save (due to some speed affinity) by chance you will screw up your work - map B. Weapon or Pawn will have a skin which doesn't exist anymore.
In order to prevent this skin lost (sample BerserkStinger from BirdBrainedResearch map - random sample) you have to open Textures Browser and inspect MyLevel package - you can even select one of textures from MyLevel - the same with Sounds if dumb things are happening toward custom stuff. By using this Way of Browsing all MyLevels (textures, sounds, actors) you will gain references preventing Garbage Collector to remove essential parts from MyLevel-ed actors when next map B is being loaded - see log. Also you can setup a SoundEvent in temporary map A and/or a wall using that texture from MyLevel and selecting/deselecting them a bit (will gain some Undo action referenced).
If garbage collector will not purge these needs, MyLevel-ed actor is usable else map goes badly borked, do not try to save it if Editor seems less responsive at this point.

The second easy way is using a MonsterHunt.u file recompiled clean - that's why you don't need to mess your default client. Even client with S3TC textures is not good at mapping so you can take these in account for working in another UT copy special for mapping/modding purpose. For compiling a new U file you need to know some basics about coding packages else first method might be more friendly. A clean file and generally clean packages will not cause pain like those screwed up on purpose or those compiled using hackish methods (OldSkool here).

Any questions goes bellow...

Terraniux
Masterful
Posts: 622
Joined: Mon Jan 05, 2009 8:08 pm

Re: Dark Side of MonsterHunt mapping

Post by Terraniux » Sun Feb 25, 2018 10:22 pm

When did you figure out this problem?

I hope you are not saying I just typed 60 pages of text, in my MH- PDF tutorial to throw it all away. Otherwise I am going to be very pissed lol. :mad2: :roll:
Can you add some info of your post in my tutorial topic? Also, what should I change / write in Tutorial then?

Also, instead of your ' solution ' it merely bypasses the bug. So wouldn't it better if You nelsona fix the actor instead?

Feedback, suggestions and commentary on this topic is welcome indeed.


Edit, this got me thinking.

Should I add a chapter, common and known bugs of the MH-503 actor instead?

Thanks Nelsona. :agree1:

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

Re: Dark Side of MonsterHunt mapping

Post by Barbie » Mon Feb 26, 2018 1:05 am

Terraniux wrote:When did you figure out this problem?
If a mapper uses only stock items, he won't be affected by the problems of MonsterHunt's uncompileable code.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

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

Re: Dark Side of MonsterHunt mapping

Post by sektor2111 » Mon Feb 26, 2018 7:35 am

Terraniux wrote:When did you figure out this problem?
When I happily MyLevel-ed some retarded packages on purpose to fix them without creating mismatches with new packages and other files. Have you ever MyLevel-ed something and re-using it in another map later ? No ? Good. Maybe it's time to check what is about in these MyLevel-s (TEXTURES, SOUNDS over Custom Weapons/Pawns). - Like I said Copy BerserkStinger into an empty MH test cube directly without to open any browser just placing weapon - ENJOY ! (it's a common slogan).
Else making a mutator (out of Editor) for MonsterHunt heads into the same compiling failure. MonsterHunt for coders is not a result of some insomnia, it's a NEED for every MH creator - EVEN mapper. The rest of Stock Users dudes can stay limited at stock for 50 years from now on.
Terraniux wrote:So wouldn't it better if You nelsona fix the actor instead?
Exactly this is what I'm talking about, fixing a BAD stock thing into a MyLevel and... reused in 3 maps - even fixing other CRAPS added before in MyLevel by different MH geniuses - PrecipitationGenerator and the rest. Learn what MYLEVEL is as the very first thing - what has to be fixed is EDITOR itself and MonsterHunt which every single moder/mapper is failing with it into ANY compilation stage thanks to Shrimp's ideas.

NO ONE HAS described these as mentioned by the dude trying to get new pawns and of course neither WIKI so a small description perhaps would be helpful to light up these things when mapper decides to do some stuff OTHER THAN TRASHES from STOCK.

Other questions, more serious after more checks this time...

Terraniux
Masterful
Posts: 622
Joined: Mon Jan 05, 2009 8:08 pm

Re: Dark Side of MonsterHunt mapping

Post by Terraniux » Mon Feb 26, 2018 11:21 am

sektor2111 wrote:
Terraniux wrote:When did you figure out this problem?
When I happily MyLevel-ed some retarded packages on purpose to fix them without creating mismatches with new packages and other files. Have you ever MyLevel-ed something and re-using it in another map later ? No ? Good. Maybe it's time to check what is about in these MyLevel-s (TEXTURES, SOUNDS over Custom Weapons/Pawns). - Like I said Copy BerserkStinger into an empty MH test cube directly without to open any browser just placing weapon - ENJOY ! (it's a common slogan).
Else making a mutator (out of Editor) for MonsterHunt heads into the same compiling failure. MonsterHunt for coders is not a result of some insomnia, it's a NEED for every MH creator - EVEN mapper. The rest of Stock Users dudes can stay limited at stock for 50 years from now on.
Terraniux wrote:So wouldn't it better if You nelsona fix the actor instead?
Exactly this is what I'm talking about, fixing a BAD stock thing into a MyLevel and... reused in 3 maps - even fixing other CRAPS added before in MyLevel by different MH geniuses - PrecipitationGenerator and the rest. Learn what MYLEVEL is as the very first thing - what has to be fixed is EDITOR itself and MonsterHunt which every single moder/mapper is failing with it into ANY compilation stage thanks to Shrimp's ideas.

NO ONE HAS described these as mentioned by the dude trying to get new pawns and of course neither WIKI so a small description perhaps would be helpful to light up these things when mapper decides to do some stuff OTHER THAN TRASHES from STOCK.

Other questions, more serious after more checks this time...

I am aware of the MyLevel bug, I encountered this by accident while using crystals / sounds / etc.. from CM-series into other my other projects. But not the coding part. Unknown boundaries indeed.
Learning someday a bit of c++ will help me big time I think.
NO ONE HAS described these as mentioned by the dude trying to get new pawns and of course neither WIKI so a small description perhaps would be helpful to light up these things when mapper decides to do some stuff OTHER THAN TRASHES from STOCK.
What are you suggesting? Those pages ARE edible, right?

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

Re: Dark Side of MonsterHunt mapping

Post by sektor2111 » Mon Feb 26, 2018 2:39 pm

Terraniux wrote:Learning someday a bit of c++ will help me big time I think.
Umm... There is not needed always too much rocket science MyLevel is doable using UScript which is... not so complex as C++ and with deps around OS, etc. MyLevel is hundred times more simple.
For me was a really piece of cake to setup new A.I. directives in a custom NavigationPoint - these things doesn't exist in UT so I went to do them - BUT NEVER with original MH loaded, Never.

The third method is a... Place-Holder package, a sort of null package called MonsterHunt.u but having only variables and empty lines - no code (like quadshot - thanks Epic for your Nothing). Just for creating relations with MH and helping to expand stuff inside Level.

There is also another problem around MH mapping also not described nowhere that much or at all...
In MH is missing the team-working, people with a bit of tech skill and those having design skill don't seems to cooperate in a mapping task, and that's why we have "MH Stuff" - recall that "Monster-Pack" which I did not asked for sync-key because I don't need to see all those MH works again. What for ? Beside this, it's available for download already without any Key - I have it (just to figure what was that fancy - and even more).
Why team-working ? Because doing a good and stable MH Level is not such an easy task - ALSO A.I. taken in account here. By example, I've started a project which I think I will abandon exactly because I don't have any designer willing to do some stuff (not a polygoniada spree)... as long as I'm less inspired toward ambience - I'm thinking to mix some oldies...

Also small techs explained around "Engine.u" part of UT is not explained, what problems might have combined with ScriptedPawn and how to establish mitigations - this is what I was trying to find everywhere.
Samples:
- Hazard Zone + ScriptedPawn dying + Engine.Counter
- Engine.Mover + Engine.Counter (not the last crap, TriggerControl happily used for NON USUAL DOORS but CRITICAL DOORS, TriggerToggle and bTriggerOnceOnly which I think is mainly useless in MH) - but all I see are the same failures from all time - unexplained;
- etc.
This is damaging type mapping and should be explained - somewhere...

User avatar
Feralidragon
Godlike
Posts: 5082
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Dark Side of MonsterHunt mapping

Post by Feralidragon » Mon Feb 26, 2018 7:05 pm

sektor2111 wrote: The third method is a... Place-Holder package, a sort of null package called MonsterHunt.u but having only variables and empty lines - no code (like quadshot - thanks Epic for your Nothing). Just for creating relations with MH and helping to expand stuff inside Level.
I think what you mean specifically is an "interface" package, with only the necessary classes to be placeable within the editor for mapping purposes, then you would have another package which would have all the code and would depend on that interface, so then you can update the package with the code without updating the interface.
In my opinion, for what it is worth, I think that's actually "the way" of doing things correctly, and not much of an alternative, not only for MH, but for any mod which requires stuff to be placed in a map directly, or that at least allows for such, or even a mod which acts mainly as a dependency to other mods (as a library).

That's how I intend to built any of my own mods in the future, and if MH ends up being rebuilt someday, that's how it should be done as well imo.
Although I believe Higor already started something like this, but I don't how it ended up, if it was finished at all.

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

Re: Dark Side of MonsterHunt mapping

Post by sektor2111 » Mon Feb 26, 2018 8:51 pm

This thing with conforming a new MH with that False borked original MH thing probably will return hidden issues... or heck knows. I had an attempt to do such operation which has ended in unwanted triggering of some actors supposed to not be triggered. I could see teleporters disabled for no reason, Movers opening too early (MH-Forbidden here), And not the last and the most evil thing a warp-zone has been disabled by a Pupae killed in other location - NEVER happening in other MH versions ( and... eheeh..., I've coded a bunch of them ).
Suspects here are/is that TArray or how it says, being miss-aligned due to some bad conforming idea. Since original MH has some nullfied stuff - aka protection, a new MH one having new things will cause net borks and bad objects wrapping causing unexpected occurrences because you cannot conform well an object with a None object or a variable/function with a NONE variable and/or function. See discussion with textures conformed - that's impossible regarding to what others are thinking, a None Texture cannot be conformed with a valid block - Credits.utx here - that's why Epic did not do that because player with null blocks will crash/disconnect after all resulting in the same NO GAME as in mismatching case.
I believe the best of this mismatch prevention it's only simply wrapping errors without to setup nothing new, but nothing else - just fixing stuff (U packages here), main target is stock (those "//fix me" actually cannot be entirely fixed due to Net codes...), but way improved - by example, projectiles any in my server are operational and compatible with vanilla client... UTPG should do this since 2004... ).
In exchange for MH I did what I was thinking years ago, "class Whatever expands MonsterHunt;" more simple than attaching ends and all those specific needs, corrections also are doable with ReplaceFunction and... that's all, it's just working properly and it was compiled using a CLEAN MH package - as MH mappers should Do.

Post Reply