UT99.org | Unreal Tournament Community

Seems like everything just works as a player, frame rates better, never had to check when I seen an area that should have slowed down as-in UT oldSkool, frame-rate. But it's not the graphics that makes UnrealGold good.

Unreal IS more or less MH by default, as if you wanted it to play the exact same way. (by making the map within Unreal defaults and not a MH prefix, just plane Jane stock stuff.)

But Unreal is designed to do just that, so making maps might be better to concentrate on UnrealGold.

Other than Bots playing, but Unreal has MH as well, if it needs to be used.

Red_Fist wrote: ↑Wed Jun 14, 2023 4:21 am But Unreal is designed to do just that, so making maps might be better to concentrate on UnrealGold.

Textures and vars added in Gold are just damaging UT and that's why all 277 related assets are OFF-Topic here for some time. Maybe 469 can deal with these, I'm not curious, some of maps done in 227 with those Textures were knocking down plain UT render, players getting completely stuck. I wrote something for 227 due to new capabilities but later funky reactions were showing up after saving a Deck16 from there back to UT. You should do some tests by yourself. For me it's clear, maps aiming UT (all versions) should be executed and saved from UT and nothing else without internal linkers pointing at variables which UT doesn't know.

I never really examined unreal gold editor very well. I wonder if there is any new actors for bot paths or better movers or new riggers. Or if I see what the MH is like, or how it works and plays.

But what I am saying is Unreal don't need oldskool and other contortions of code, as compared to Unreal that needs none of that.

Cleaner mapping ?
Or wouldn't it really make a difference with less code, or for the CPU. Or would Unreal Gold be more code ?

Topic'sTitle wrote: Technically speaking...

there are internal differences in codes and their executions. If you don't get that UT won't access unknown variables then I'm talking at walls. We can end discussions before even to start them.
Linkers are created in map itself pointing at assets that UT won't manage. There are new vars in navigation, "player" variable was moved, screenshots are carefully ruined from having "mips" crashing D3D render from UT (I don't see what's the benefit here except a few bytes saved). UGold which I was probing last time, StaticMesh doesn't exist in UT and I did not investigate if A.I. understands it, "bTwoWay" is also placed elsewhere. Textures have properties unknown by UT render and so on. More to come, portals are useless if map doesn't have ZoneInfo actors, and all actors placed around are in account as placed in void not in map.

New Pathing stuff specific to 227? Custom pathing task in UT is already available since 2-3 years, initial stage delivered by XC_Engine and some mystical data can be fixed/erased with XC_PathsWorker. More to say, we can clean ReachSpecs without any corruption.

Whatever is needed for solving Textures looks available in 469b (469c it's no way), rebuilding geometry in exchange is good (when mapping is executed correctly). There is no logic point to mess with Gold in maps aiming UT. MyLevel codes will generate dependencies that UT won't run.

"there are internal differences in codes and their executions."

That is what I am trying to say-ask, is since Unreal is only default singlePlayer that it runs better than UT without having to force UT or add things, like oldskool, etc etc.

If you had two identical MH or SP maps, should Unreal use less CPU load ?

I did not do this test... because I didn't need it.

Red_Fist wrote: ↑Fri Jun 23, 2023 6:55 pm If you had two identical MH or SP maps, should Unreal use less CPU load ?

On a pedantic note, Unreal doesn't have MH - there is SP_MonsterHunt but maps made with that do not run in UT (not that that matters really as most/all of the [SP] MH maps for Unreal are conversions of MH maps made for UT so there is no reason to try to run the [SP] MH maps). Maps made with UT's MH won't run in Unreal.