Page 9 of 11

Re: XC_Engine megathread

Posted: Wed Jul 10, 2019 11:09 pm
by Higor
CollisionGrid status during the crash?

PD: Found another set of problems in CollisionGrid and already fixing some.
Found a bug in extent traces that was making players not properly stand in elevators and that the GCC compiler wasn't properly vectorizing (have to update to GCC 7)

Done, this should fix all (if not most) of CollisionGrid problems.
Small reminder that this requires SSE2 instruction set.

Re: XC_Engine megathread

Posted: Thu Jul 11, 2019 4:08 am
by sektor2111
This map... with brushes stripped

does the same "invisible-for-user" error if "bEventChainAddon=True", other maps are working.
Note: This map loads patch files for remapping navigation and it was... a heavy deal. Strategy in moving movers away from Scout did not worked in that time for this map while in others was the default strategy. I had to open them, mapping paths, and closing them back. Else... here I have some actors triggered at once with doors which are dropping in the right moment InventorySpots because originals from behind doors were removed and other paths were mapped for making Bots to get items only after opening those doors.
After disabling EventChain map was operational at once with all patching:

Testing in progress...

Re: XC_Engine megathread

Posted: Sat Jul 20, 2019 11:37 pm
by sektor2111
Next one:

Code: Select all

ScriptLog: UdpServerQuery(crt): Port 7778 successfully bound.
ScriptLog: Game Core found CaptureActor.
Critical: UXC_Level::SpawnActor
Critical: (Scout)
Critical: FPathBuilder::getScout
Critical: ScriptDebugV
Critical: EL_Trigger0.CreateAIMarker
Critical: ScriptDebugV
Critical: EL_Trigger0.Update
Critical: UObject::execClassContext
Critical: (XC_Engine_Actor DM-Velocity_R15.XC_Engine_Actor6 @ Function XC_Engine.XC_Engine_Actor.SetInitialState : 0051)
Critical: UObject::ProcessEvent
Critical: (XC_Engine_Actor DM-Velocity_R15.XC_Engine_Actor6, Function XC_Engine.XC_Engine_Actor.SetInitialState)
Critical: BeginPlay
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ServerTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UXC_ServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 07/21/19 01:12:19
Is this about "original" Scout ? Let's say that Scout goes to destruction right in PreBeginPlay(), in next tick is under destruction or almost removed, but Engine wants a deal here. Perhaps a Pawn pending deletion won't be able to reach at a goal... just saying...
I think here getScout call is doing critical damage because we don't need that Editor Scout, we need a "run-time" type Scout...

Re: XC_Engine megathread

Posted: Sun Jul 21, 2019 8:52 am
by Higor
Updated beta (includes CollisionGrid fixes)

Changelog here: ... 3132319b1b
Notable: "Improved actor attachment movement, actors are much less likely to overlap/encroach/telefrag each other when standing on a base that moves horizontally."

Re: XC_Engine megathread

Posted: Sun Jul 21, 2019 5:48 pm
by sektor2111
Yep... there are changes from beta2 to beta3...

Config done... everything is looking stable (I'll see other testing next hours) but I removed once again that XC_UPakPredator because I'm not sure if I do need it. Editor is crashing if I'm opening that thing. I don't get why I should use it.
Note: I've disabled RocketTick if game is being ended - auto-aiming in that stage it's useless...

Edit: The Good and The bad
Probing NfoServer with XC_MonsterHunt map called MH-CrystalMine3 (original by Teraniux not some stupid mismatch copy) using patch plugins for completing paths up to the MonsterEnd.
Evil things - Bots were trying a shortcut to WayPoint3 and I could not see more interest for WayPoint4 but let's say that I could manage these while they attacked forward...
Good news - Bots were going closer to end - opening gates (did not happen so far in prior versions) and even they could finish map - previous DevPath has stopped at first grate and... done with bot's race. In this update I see a real improvement to DevPath but I would like to find what was wrong at Position3 and 4 because they have been operational before.
Now I think I will want to retry my best pathing task for MH-LostInTimeV3... as long as I can do some reachSpecs nullified for making things easier for Engine.

Re: XC_Engine megathread

Posted: Mon Jul 22, 2019 11:19 pm
by sektor2111
Bump: Testing results
Using XC_MonsterHunt and MBots map MH-LostInTimeV3 a version with all paths redone. Pretty closer to applause newer DevPath... but:
- WayPoint4 moved more reachable returned a route in Editor (which is more nasty with Scout not like in run-time) using a closer node on that ledge nearby stone - Bots were roaming properly because of... new technology from XC_MonsterHunt. Me, player I could not see any route here.
- Waypoint5 The same results.
- Waypoint6 entirely reachable by ALL pawns - human as well - using a similar placement.
- Waypoint7 failure - Only bots roamed properly.
- Waypoint8 good response.
Personal conclusions - suspects - I see network working perfectly, the problem can be that last Node supposed reachable around target which won't return anything if it's colliding with mover and here comes once again collision issues vs Movers or map has problems causing error in computing BSP traces - in hoping to wrong.
EventChain had a sudden funky reaction ? I touched all Waypoints and MHBotyman4 was showing MonsterEnd reachable (I was closer) but turning me into another direction - a trigger - where I could see a green apple around last WayPoint instead of MonsterEnd and... DevPath discarded first search even if I was in the castle in the same area. Something is not working properly with that Green thing it has turned me almost 180 degrees to a trigger which was already touched opening the way to ending portal. It was like being a step behind me. During this time Bots were looping in another area of map without to leave that spot...

Edit: I think job it's done in LostintimeV3. If some waypoints are unseen by player is probably a BSP problem because Bots are hunting well in XC_MonsterHunt (there strategy is changed). I gotta do some checks in last room, but... mission it's almost done so this is not a problem in end.
All I might need are small actors for default Bot, removal of some directions, maybe some ammo and healing spots and... it's good to go for a XC Server... Impressive DevPath - applause.

Edit2: Confirmation
By disabling all that EventChain stuff and playing MH-Crystalmine3 with patch plugins (run-time depleted paths) I could see Bots heading the game up to the end. Definitely some events from XC_Engine added there combined with new paths aren't doing to many good things. All WayPoints injected in run-time have been completed properly without any other add-on.
As a self reminder, another long map with problems at DevPath was MH-PurpleChristmas or such. It worked in the past when I had a half of map with paths and stopped working when was full filled. I dropped it away... but now I'm curious how will react with new dev... :)

Re: XC_Engine megathread

Posted: Sat Jul 27, 2019 4:23 am
by Higor
Finally after some crazy brain exercise got bots to open doors smartly.
This can be really useful for movers blocking paths that don't have a BlockedPath marker or any other way of signaling the path isn't available.
This MAY help bots enable long distance elevators/bridges where the trigger isn't visible or reachable.

In the following example you'll see the bot not touching the secret door before going towards the light.

Re: XC_Engine megathread

Posted: Sat Jul 27, 2019 9:11 pm
by sektor2111
I understand what you mean but routing Bot should be Smart enough because mapper can be more creative - by using some dispatchers might result more complex chained events to trigger.

Back to pathing tests:
MH-PurpleChristmas has middle area responsive at DevPath and Bots are heading for a few items there, as for the rest of areas... not many chances...
As conclusion we have a powerful DevPath but in bad oversized maps it's not very active. Good work so far.

Re: XC_Engine megathread

Posted: Tue Jul 30, 2019 11:23 am
by Higor
Just found a very obscure bug in UT/UE.

Take a look at Bot and Pawn classes.
Bot has a definition of BaseChange, then calls Super.BaseChange within it...
The problem is that both functions have been tagged as singular functions.

So this means that Super.BaseChange will ALWAYS fail to run.
What's the effect of that?
Well, bots don't deal damage to players and decorations when they land on them.


Meanwhile, major milestone on the Event Chain System and Bot AI, does this clear any doubts about dispatchers and other complex mechanisms not being properly handled?

Re: XC_Engine megathread

Posted: Tue Jul 30, 2019 9:58 pm
by sektor2111
Which means that my MBot will need an update... or Hi, Epic -> I'm gonna update UScript part of main Engine file... it will be probably NOT a "singular" declaration.

Re: XC_Engine megathread

Posted: Sat Aug 03, 2019 9:43 am
by Higor
Getting close to finishing the update, already dealt with some annoying telefrags and did some more improvements on bot elevator handling.
(The Singular function bug was been sort of worked around, it's possible to call Global/Super versions of a singular function now)

Re: XC_Engine megathread

Posted: Tue Aug 06, 2019 11:16 pm
by Higor

Re: XC_Engine megathread

Posted: Fri Aug 30, 2019 4:26 am
by Higor
Found a few *not easy to trigger* bugs in the native code, if I have enough time in my hands I'll release a hotfix later.

Re: XC_Engine megathread

Posted: Sun Nov 17, 2019 6:14 am
by Higor
Some info over this project:

XC_Engine 25 and onwards will only run on UT v469, this means I'm deprecating UT v451 and under for next release.
Most of the changes in XC_Engine 25 will actually consist on removing stuff that won't be needed due to them having been implemented in the new UT patch.

Aside from a few bugfixes, a few new features might make it in.
A major one I'm thinking about is adding the possibility of making specific actors travel from one level to the other in Coop games, without requiring any relation to a player or it's inventory.
This would make the task of having hub levels, recurrent levels, and other general stat holders a lot simpler.

Re: XC_Engine megathread

Posted: Mon Nov 18, 2019 7:25 am
by sektor2111
Wasn't it more convenient for users to have configuration variables and specifications in a user manual so they could use this version in previous versions of UT and disabling what is not needed for 469 ? This 469 needs to be well tested until we can fully trust it. Moreover, version 24 seems to need minor repairs.