A THREAD THAT CHANGES UNREAL...FOREVER!!!!! AHAHAHAHAHAHAHAHA

AND MAKES **** ****** and Warren Spector SUCK IT DOWN!!
The HUB system worked in Unreal all ALONG! I noticed this while browsing log/comments that around march 1998 this was implemented. The mysterious ?peer at the end of a level teleporter forces the linear transition.
But there were two other... ?push and ?pop
?pop on itself can restart the hub, but when used together in a hub it works miracles. As I couldn't test this myself UB did all the practic research trying this out in a game.
He used the zora's beta conversion maps since they are largely unaltered and dont use custom scripts for hubs. fhub4 has been used as showcase. I'll summon UB shortly..
EDIT: we did some testing with zeurkous on his machine ourselves because his curiosity won over him and he ran unreal after a long time. If all three ?push ?peer and ?pop are used it works well. There can be multiple pushes but not multiple pops. the saves game#.usa are kept until loadgame occurs or ?load= simply.

The server testing we got to work halfway so far, from outright crashing at first to other issues. But multiple pushes do save it to multiple Game# instances. This was tested on the 226 versions on this side.

It's keeping the save of the map/events in i after you revisit the level, IE the carcasses are there and whatever else you've left there. In the state it's left in the current game it obviously needs some tweaks to work fine. There are especially nasty implications for online play and so far it needs a custom gametype to work correctly more or less. But the funcionality is there, despite being largely unknown before. Many mods have taken overcomplicated steps or other games to make hub systems work.

Critical: appError called:

Critical: Assertion failed: ActorClass [File:M:\Unreal224\Engine\Src\UnChan.cpp] [Line: 691]

Critical: Windows GetLastError: The operation completed successfully. (0)

-
<zeurkous> okay...
<zeurkous> when metried the ?{push,pop,peer} stuff out on a dedicated swerver w/ a single client
<zeurkous> -- but w/ seperate Save/ dirs for the experiment --
<zeurkous> mefirst found out that while the swerver is smart enough not to send the ?{push,pop,peer} on to new clients
<zeurkous> GameInfo.ProcessServerTravel() actually does
<zeurkous> in practice that causes the client to save Entry instead of the acutal level
<zeurkous> so mecrufted together a subclass of GameInfo, the ProcessServerTravel() routine of which strips any off said options
<zeurkous> so the client is never informed of the hub system being in operation
<zeurkous> btw, for both the swerver and the client, mehas the respective save dir in the Paths array
<zeurkous> in case that makes a diff
<zeurkous> me's not sure anymore whether that's standard or not, feh
<zeurkous> the swerver tells the client the real level name
<zeurkous> so instead of trying NyLeve, it fetched the Game* file from the swerver
<zeurkous> which resulted in a surprising situation -- since the client takes over all the swerver state
<zeurkous> which turned out to include the stuff in the LevelInfo
<zeurkous> mehad a client acting as a dedicated swerver for a tick, while being linked to the intended swerver
<zeurkous> sole intended swerver*
<zeurkous> then the client suddenly transferred to the level mehad popped from
<zeurkous> mehad issued the pop from*
<zeurkous> after quite a couple of experiments
<zeurkous> mefound out that since the intended client now acted as if it were the swerver, based on the state in the Game file
<zeurkous> it decided at the end of the first tick to enact the orig push
<zeurkous> crashing itself in the process, too, by overwriting Game0 with Game0
<zeurkous> or trying to :x
<zeurkous> again, the actual, intended swerver wasn't so stupid and ran on happily
<zeurkous> methen tried to find a way to get the swerver tell the client that it's really not Game0, but NyLeve -- the level orig pushed and then popped --
<zeurkous> that should be opened
<zeurkous> after all, the swerver was aware of that
<zeurkous> mecouldn't figure out how to do that
<zeurkous> sometried `ucc conform'
<zeurkous> however, in either case, that yielded a file of ~40K
<zeurkous> w/ unclear contents
<zeurkous> finally, memanually `conformed' the swerver's Game0 and the client's copy of NyLeve, also named Game0 for the purpose of the test
<zeurkous> by extended the shorter of the two w/ zeroes until the sizes matched
<zeurkous> and by overwriting the GUID of the client version w/ the one of the swerver
<zeurkous> the client ate that
<zeurkous> long enough through the first tick to run the console
<zeurkous> meconsole reports that, so meknows
<zeurkous> however, appearantly immediately after that
<zeurkous> the above error occours
<zeurkous> on the client
<zeurkous> again, the swerver goes on happily
<zeurkous> oh, and as for the fetch-from-swerver route
<zeurkous> the client xferred in a tick 'cause that's what the native code appears to do if (Level.NextURL != "") && (Level.NextSwitchCountdown == 0)
<zeurkous> even ServerTravel does it that way
<zeurkous> the one thing mehasn't tried yet is to pass the client the ?pop argument, but not the corresponding ?push argument
<zeurkous> memight do that tomorrow
<zeurkous> memeans, w/ the client fetching the Game file from the swerver*
<zeurkous> that might work, but it still prolly won't
<zeurkous> besides, there are security issues to consider, like the sharing of the AdminPassword
<zeurkous> hence mepreference for the second route
<zeurkous> blaat
<zeurkous> second route is to keep the Game file for the swerver only*
<zeurkous> and making the client use the original level, in our case, NyLeve

------------------------------------
Just rambings/findings.

Yes here were multiple mods, some of them were released but got lost or their lates versions. I remember one of the los mods was capture he cow, the oher was unreal 2d_the original) and latest versions of conquer the base got lost as well.