MH-TheFifthVortex

[Buggie]

On complex map like that too many things can going wrong. So this is not an option.
For example that disco need bDynamicLight flag. Which clear after every rebuild light.
Nali near water need LoopAnim flag. Which too hidden.
Eyes on wall need bStatic = false and DrawType = DT_SPRITE. Light not fit. TriggerLight fit, but set DrawType to DT_NONE. So I subclass it.
And this stuff about which I know now. I am sure exist another stuff, about which IDK.

Also in Beta8-9 "fixed" HOM in water on part1 map. It is bad partitioning BSP/CSG tree. So game think - you from this point can not see this part of BSP tree. So not draw it.
Same rules applies for any brush here. Even for moved brush. So this not fix problem. But actors draw anyway. So I place one Panel with same texture in void.
It very reduce HOM. But in some places of texture where it dark HOM occurs again. So I place on back second Panel and shift relative to first Panel.
Now it is visible instead of HOM. Wrong lighted, but more better from HOM.

[sektor2111]

See screenshots above. Spawnpoint not connect with AlarmPoint after YOUR PATHS.
All paths green.
Before YOUR PATHS work. After YOUR PATHS - not work.
If this need place higher why before YOUR PATHS it is work?

A few points
- THERE ARE NO GREEN PATHS in EDITOR 436 out of XC assets - if EDITOR 436 shows them RED Monster is not moving anywhere - I'M TALKING about ORIGINAL Editor - take a break with these greens not showing data because I know how to make BLUE paths from RED paths I did this before in NORMAL MAPS not in this Trash, and no SpawnPoint is needed in stage - that is only what you think.
- NavigationPoint placed HIGHER is not a goal so by Moving it HIGHER it doesn't even need any CONNECTION - I should move it because I can move things in Editor if you can't but I wasn't aware of that area with Skaarj - I'll drop an eye later.
- You are just demonstrating that you cannot manage this charge at all - just like that - because you don't understand FindPathToward which is C++ not Uscript.
- ANY navigation node placed higher than creature's head it's not an entry point for routecache but a nearby node IF REACHSPEC from node allows roaming VIA collision data and reachflags.
- It's possible AFTER XC works to have paths "smaller" and then Skaarj won't navigate properly - but it can be ADJUSTED after testing map, but not when tester is crashing and unable to play or to test anything in detail.

But when this charged Level is crashing mainly everything I cannot work at these. These REDS can be turned in BLUE or else those Skaarj won't move anywhere. And this is not the only spot that needs corrected MANUALLY. What is wrong in image ? Simply, almost EVERYTHING. AlarmPoints are for monsters but not RED paths. Monster won't move through Red Paths. ALL these must be fixed. Not the last thing, DevPath should have a fast response or else Monster won't even blink to alarm.
SpawnPoint doesn't need anything than making it "UnReachable". ActorReachable is another C++ code called by ALL Pawns. See what does that means.

Then if you ask me about ideas. It's not about ideas - ideas are already DONE, it's about making THESE MAPS to work in MonsterHunt and not THE MAP. If you play MonsterHunt and you know some stuff maybe you have hear about Andromeda levels and Server-Travel trigger written for MonsterHunt. Of course, such Server-Travel must be a bit studied if Server-Travel held mutators or not. Else it will need to be fine tuned with a CONFIG file where admin must add Game-Type - not all MonsterHunt is MonsterHunt (right Barbie ?) as long as MonsterWaypoint does Accessed None out of original MonsterHunt linked in references. There we need writing which MonsterHunt are we using, and what Mutators should be taken in account for next Episode - like ActorCLP but... having more than a server-travel task - not exactly reacting based on map-name and reacting triggered instead of those SP Teleporters.
Something like this:

Code: Select all

[MHTravelTrigger.TravelTrigger]
TravelType[0]=(MHGameType="",Mutators="")
TravelType[1]=(MHGameType="",Mutators="")
TravelType[2]=(MHGameType="",Mutators="")

Probably an external package for common use would be recommended and information provided in a document. Multi-servers might run multiple MH versions and then trigger should do the right travel loading all specific mutators.
Then Every single map should be adjusted and renamed with "MH-" Prefix and left as separate Levels with such triggers. MIXING all like here I doubt to see them ever working - this is UE1, boys (I witnessed such things done before ruining alarms, no worries...).
Then... Non-Static actors which are Static by default must be corrected for network games using bNoDelete or else they won't be seen by old clients.

Another time maybe I'll write Server-Travel stuff... Now I have to solve other problems.

[Buggie]

I place Spawpoint higher. Obviously it not fix issue.
I load Beta7. Skaarj want run on path and after that try attack me.
I load fix with YOUR PATHS and with spawnpoint placed higher (or not - does not change anything). Now Skaarj simple attack me. Not run by path before that.

So you don't seem to have an understanding of how it works or how to fix it if you insist on things that don't change anything.

[sektor2111]

I place Spawpoint higher. Obviously it not fix issue.

Because paths are RED and your rebuild caused new BLUEs reachspecs - that's why.
NEEDS:
#1 SpawnPoint higher
#2 BLUE paths
Both points must be respected.

So you don't seem to have an understanding of how it works or how to fix it if you insist on things that don't change anything.

That's you, navigation code is in C++ which you don't seems to be aware about what is wrong and how to be fixed. MIXING these SP maps was wrong by default - also you did this not me. Do you have BLUE Paths or not ? See image from above post - you don't even read what I was posting. If path is Blue, there can be another reason, movement calculation, or still path is having a small collision data for Skaarj. By any matter if this point must be connected for other reasons, adding ONE reachspec would solve problem and in all rooms where is needed instead of charging more data. But map must be handled in Editor which is not easy to do... else I would get into game and testing paths directly, then I can figure an alternate solution, always exist a solution but the problem must be known directly not only in Editor.
To reveal the truth, when is about making paths I'm wiping floor with many of you "mappers" and YES, I KNOW what is wrong here and how to solve these but not when your UNR junk is crashing my Editors because you don't have an understanding about MAX_Points and what does that means. I wrote "PathsLinker" which for you is not used because you don't know what to do with it - that thing would solve these ALARMS, I'm not bullshitting - but... let me handle map normally in Editor first...
UModel.h

Code: Select all

....
//
// Model objects are used for brushes and for the level itself.
//
enum {MAX_NODES  = 65536};
enum {MAX_POINTS = 128000};
class ENGINE_API UModel : public UPrimitive
{
#ifndef NODECALS
	DECLARE_CLASS(UModel,UPrimitive,0,Engine)
#else
	DECLARE_CLASS(UModel,UPrimitive,CLASS_RuntimeStatic,Engine)
#endif /*NODECALS*/
....

When you, boys, are trying harder to get over 65536 and 128000 this is demonstrating your own lack of Knowledge, not me, I'm not mixing maps.
To be honest I'm not sure if this "MAP" is an objective to me. I'll do my own ConversionS.

I see at a moment in Editor 70200+ Nodes trying to get into a 65536 array (Map rejected from even being Saved) this math would surprise me if it would fit without losing data (zone leaks, non-colliding walls) or causing bad memory corruptions. Surprise me with something logic here and making map to work normally and then, I'll fix ALL paths. I think I'll setup here two small demo maps just to show you that I KNOW what I do or what I'm talking about. One with bug created on purpose, the other one out of bugs and you can see if sektor is talking craps or not.

EDIT:
And now: Two sample maps with AlarmPoints for SkaarjAssasins. Demo Deathmatch bNoMonsters=False - 1 Player.
This map has Skaarj spawned, running and killed (I'm sorry for him - R.I.P. Skaarj)

DM-Alarm_Good.7z

(4.07 KiB) Downloaded 9 times

In other hand, another sample which in Editor looks identical, but it doesn't work as supposed with the same settings.

DM-Alarm_Wrong.7z

(4.05 KiB) Downloaded 6 times

NONE of these two have paths loaded in SpawnPoint. "TheGood" map works exactly as it is out of SpawnPoint connected. The other one won't work for this type of monster.
Equation: Explain why "TheWrong" map doesn't work, why these are different even if they do have the same settings for alarms.
Answer: It's all about REACHSPECS properties or internal data - not very seen in Editor. Exactly these problems were created for some reason in "Vortex Map" and these can be found in game, Editor won't show you the bugger, just like that. As long as I could not check these in detail it's normal to see bugs escaped, and yes, they can be solved.

[Buggie]

Path is BLUE. Screen from v436:

Also I not rebuilt paths after you. So all same as you send.

[sektor2111]

In previous sample I presented a bad map with BLUE paths - that alarm doesn't work for similar reasons, it needs fixing which is hard to do when Editor is closing or crashing. Also here SpawnPoint goes the closest reachable node from Pawn, it needs moved and Path size enlarged (collision data from reachspec) or else Skaarj is not running for alarm, it's just attacking like in above map DM-Alarm_Wrong. Even Blue sometimes has data for Krall, SkaarjTrooper not Warrior. Warrior is bigger and then if path says 32 × 44, pawn having 34 × 46 or something like that won't move there because result from "CalcMoveFlags" does the rejection.

I'm not sure if you understand that such alarms in SP maps must be tested in game - Editor might be cheating - but this game it's crashing and lagging. I cannot test anything and so neither fixing on my side.

I'll write another time tutorials for testing AlarmPaths because for monsters it's not like for Bots - if map is permitting to do test before crashing.

[Buggie]

Now I move AlarmPoint close to spawnpoint like on your maps and all start work.

Also we finished near 1 hour ago Beta7 map with 6 players in total. No any crashes.
So bad paths not so bad.
---
Do not try rebuild map. Use v469 editor. Rebuild only light if you want. Or (maybe) paths.
You can not proper rebuild geometry without special tricks.

[sektor2111]

I get it - I'm suspecting a space computing problem then...

Getting over paths, I wanna find if... water zones are indeed water zones and the rest of other zones...

[Buggie]

All water zones which must be water zones - is water zones. All zones which must be not water zones - not water zones.
Tested many times.
Some places look like water zones, but not water zones. Copied from original map. At least two of them near spawnpoint which we talked above.
3 triggers over water imitation for produce water step sounds.

---
Also Beta1 is internally build near 500. Because I test many-many things. One of them - proper work of zones.
And if in one zone exists many zones actors then I too lazy remove it because they same and which pick up engine does not matter.
Also this done for allow reverse actions if something going wrong with zones.

Initially 5 maps of course not fit to 63 zones limits.
I hardly work on it. And now 59 zones. And this count include 4 warp zones added by me. So in fact 5 maps use 55 zones.
For me this reached not easy.
There many pipes. For water and not only. Even some air zones connected together.
And 1 additional zone added after all for fix HOM for one warp zone pairs. So in fact 5 maps use 54 zones after hard optimization.
----
It looks like you think I just opened 5 maps, copied the content into one map, hit build and posted the result.
I will disappoint you. It doesn't work that way.

Each map was examined first. They were then rearranged where possible to take up the smallest possible space.
Then the transitions between the maps were studied and a plan was drawn up how they would be connected.
Then the calculation and arrangement of these blocks on a single map was made. Moreover, taking into account the saving of zones. If it were possible to connect all the maps, I would connect them. So it turned out to be possible only for two of them.
The other two use seamless portals.

To connect the second map and the third, it was required to rotate the second map ninety degrees.
Do you think it's easy to select, hold down the shift key and drag the mouse?
No matter how it is.

Movers won't spin at all. Their key positions remain the same. But that's half the trouble.
if transformations are applied to the brush, then during rotation it distorts, and does not rotate.
If you merge transformations and normalize the brush, the texture alignment is destroyed.
And given how bad things are with texture alignment in UnrealEd, this isn't the kind of job you want to do.

Even connecting two maps is not easy.

Portals are also problematic. Even in the initial stages. Initially, I was generally going to put a flickering wall with teleportation, since it did not occupy the zones, which were already few.
But in the end, free zones were found and portals were made.
The portals do not allow sound and light to pass through, therefore, to create the illusion of continuity, a copy of the second part of the level in terms of light and sound was created behind the portal.
Therefore, many players will not even notice that there is a portal there.

The problem with portals popped up even after finishing working with them. It turned out there is a bug in the portal scripts. And on a dedicated server, the player turns twice.
If the portals are codirectional, this is not a problem. but oh me both portals turn the player 90 degrees.
Because of this, we had to create a fixed version of the portals so that everything worked fine on dedicated servers.

Back to the beginning.

Each map has been optimized to the maximum separately. The number of nodes is minimized. The number of zones is minimized.

To reduce the number of zones, all zone actors were examined, identical actors were found, and merge candidates were identified. Possible ways of merging and ways were studied.
Also, after the merge, the result was monitored and the number of nodes was monitored.

A plan was drawn up and the main characteristics of each level were recorded.

Then every two maps were copied together and their joint work and transitions were checked.

And there the glitches began. Separately, 10 zones and 8. In the bag 16 or 22. Zones appeared out of nowhere. Or rearranged zones to work when previously worked. etc.
All this was decided.

Three brushes were simply damaged. More precisely, one was damaged, and then its copy-paste was made in two other places.

To find the problem area, I had to remove pieces of the level using the dichotomy method, rebuilding the map every time.

Later, in the same way, a duplicate of the actor was found, which was created in some way.

After that, all levels were copied together and partial assembly and debugging began. Some were hidden, the visible was collected and tested.
Conflicts in tag and event names have been fixed. All logic was tested and so on.

And again there were inexplicable glitches with zones and the number of nodes. Simple additive arithmetic doesn't work here.

Skyboxes were a separate pain. A custom actor was written for them to switch them. The most similar skyboxes were found and reduced.

Each zone was assigned its own skybox, where it was needed. All of this was also tested.

Then it turned out that the map was built in 70k nodes and could not be saved. Search for a solution. The solution was found.

Now you need to built in a special way. Going to. Hooray? No, no hurray.
Most Movers become invisible. We are studying the issue, looking for a solution. It turns out that we need a stock of free nodes.
65k is the limit for all nodes. Both statically and dynamic. Nobody knows how many dynamic ones.
Therefore, there is a brutal optimization and recapture of the number of nodes.

Almost every additive brush has been tested as semi-solid and then rebuilt and node count checked.

Victory? No. Now we hit the limit of the number of points. The editor closes in any 3D view. The game crashes at the start.
We study the issue. We are looking for a brush with a huge number of dots, we redo them into simpler options.
Victory.

We test and get crashes by the total number of points after seeing a certain number of movers.
We start to optimize them.

To know the number of points, an UnrealEd hack was performed to display the number of points instead of the number of brushes.

We sorted it out with the limits.

The assembly now takes 40+ minutes, is non-trivial and contains several steps / passes.

Then we start checking and testing all the logic.

Only after that we add monsters, weapons, inventory.

We go through parts of the map and the map as a whole many times to check the balance and that everything works as it should.

Etc.

Only after that the first beta is released.

So it wasn't just opened, copied, pasted, and assembled. Not at all.

And that's not even all the adventure. I have not mentioned some of the problems, I have already forgotten about some of them.

----

Naturally, I used the same editor as the others. Everyone who worked with him knows that he can crash at any time.

Only I had it much more often, because I worked at the border of the limits and did non-trivial things.

[sektor2111]

Does it worth floating around limits and a hard working time ?
Server using mods will get closer to a crash - which is not that critical. When it goes into lock-down state out of response, that's more nasty, will be needed a manual forced End Task or External Task Control. And then, not everyone will be happy here. Idk, I think it's 100 times easier to develop a Server-Travel trigger, which 100 mappers can use and creating 30 Episodes for a single story, releasing unlimited creativity. Not everyone is capable to do a hackish build or is happy with lags...
It's just a small suggestion. We do have MapVotes managing a Server-Travel, Coop mods which can be taken as resources. I doubt to not be possible making a trigger doing the link through Episodes and keeping players in the same battling zone when action runs in the same area of said Unreal story.
Given the hard way of building such a Level, any future fixing work goes difficult to do.

[Buggie]

I got in as spectator on different map. After you and barbie left, so yup the map was crashing the game on me.

Look like Harley has same issue.
I check on my PC with D3D render. If UsePrecache = true I get crash UT. If UsePrecache = False i enter to map started locally. Beta7.

So try set UsePrecache to False.

In console type
preferences
hit Enter

In new window navigate to Rendering. Press plus. Open Direct3D support.
Set UsePrecache to false.

---

Good news. After set UsePrecache to false Harley able to enter on map.

Discovered some issues. But I know how find it and test it: v436 + D3D + Galaxy.
So currently map mostly playable (checked first 4 parts, later I check last part 5).
All glitches must be resolved soon in future betas.

---

But I strongly suggest use D3D9 instead. It is modern render. D3D render is really glitchy and outdated. If this possible - install and use D3D9 renderer.
Link here: http://www.cwdohnal.com/utglr/utd3d9r13.zip

Harley if you read this - please try too. I hope it work on your old hardware. At least try.

Just unpack zip into system folder. Run UT - options. change video driver - show not certified renders and select it.
Via command "preferences" you can tune some options if you need.
---

Does it worth floating around limits and a hard working time ?

Of course it was worth it. At least during the development of this conversion, a lot of bug reports were filed, some of which were fixed in the new patch.

[Eternity]

Of course it was worth it. At least during the development of this conversion, a lot of bug reports were filed, some of which were fixed in the new patch.

This map also has uncovered another difficult bug in v469a-Linux build, it seems investigation will take a long time until it can be reported... This problem looks very similar as another one - existed in v469-Linux build from 4 Feb. 2020 and produced very high amount of i/o wait time... It was fixed then. Now, with this new problem there is no high i/o wait time, server latency gets increased (and tick rate reduced) by some another, undefined reason... I still can not find out any reason that might produce this effect after reaching MyZoneInfo5-MyZoneInfo23.

[Buggie]

Beta10: https://www.sendspace.com/file/6dwj46
mirror: http://medor.no-ip.org/index.php?dir=Ma ... Beta10.zip

- Fix Textures on MyLevel which cause crash on D3D renderer. Better always use P8 format of textures and nothing else.
- Fix predator attacking players before game start. Already fixed in v469a, but most servers not v469.
- Fix path issue for skaarj.

Now even not need usePrecache = False.

[Red_Fist]

My MH rejects the old weapons, new install.

I have oldskool installed, it says "can't find file for rajorjack" or OMRajorjack something like that.

take those old weapons and other pickups out,,, for MH.

[Buggie]

I already answered on topic for what need old weapons - so no, its not removed.
With Razorjack something wrong with common MH version. but it is not a map problem.
For example, on Barbie server all work properly, because here fixed this stuff.
If you use proper MH version - all must work.

Map tested for play in local environment, without server. In this condition old weapons is helpful.