XC_Engine [20] - XC_Core [7b] - XC_IpDrv
-
- Godlike
- Posts: 6443
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
Woow, Higor ! You are the Man Of The Year !
Finally idiots are getting Redeemer because you have created a path between Teleporter and nearest InventorySpot, else I have to look carefully at Bots (or MBots ), it do seems like they cannot jump with JumpBoots around miniammo, I'm gonna look where issue is coming from... Last time I saw that it was functional.
Edit: Default Bot seems to jump forever in Deck16][ like it has unlimited jumps... even failed shield a few times jumping over it (single Bot spectated) - probably random timing bug.
Edit2: Yep... tiny correction at MBot, it uses properly 3 jumps to get in upper area, it do looks good now.
Edit3:
Now I'm interested in doing some pathing mutator but probably files (attached modules) are going to be U packages, probably a harder job... eh, something with dynamic load "outer.lulupather" etc. then pathnode child, hmm, I gotta learn pathing details but such tutorials probably don't exist... Anyway so far I see new things doable which is a nice step forward. I would like to see more people interested at these debates but maybe they are busy with other things.
Finally idiots are getting Redeemer because you have created a path between Teleporter and nearest InventorySpot, else I have to look carefully at Bots (or MBots ), it do seems like they cannot jump with JumpBoots around miniammo, I'm gonna look where issue is coming from... Last time I saw that it was functional.
Edit: Default Bot seems to jump forever in Deck16][ like it has unlimited jumps... even failed shield a few times jumping over it (single Bot spectated) - probably random timing bug.
Edit2: Yep... tiny correction at MBot, it uses properly 3 jumps to get in upper area, it do looks good now.
Edit3:
Now I'm interested in doing some pathing mutator but probably files (attached modules) are going to be U packages, probably a harder job... eh, something with dynamic load "outer.lulupather" etc. then pathnode child, hmm, I gotta learn pathing details but such tutorials probably don't exist... Anyway so far I see new things doable which is a nice step forward. I would like to see more people interested at these debates but maybe they are busy with other things.
-
- Godlike
- Posts: 6443
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
I do ask some explanations toward my old problem >>
I Removed code from XC stuff and I'm using only this one.
It is very operational, then I hit menu to start a tournament or restart map. It drives to End of game >>>
Code: Select all
class XC_PlayerPawn expands PlayerPawn abstract;
var private float LastPathTime;
var private bool bSaidPath;
...
exec function ShowPath()
{
local Actor Node;
CheckPath();
}
....
final function CheckPath()
{
local Actor Node;
local WayBeacon W, W1;
local bool bHasBeacon;
/*
if ( !bAdmin && (Level.NetMode != NM_Standalone) )
return;
*/
foreach ChildActors(class'WayBeacon',W)
{
W1 = W;
bHasBeacon = True;
break;
}
if ( LastPathTime + 7 > Level.TimeSeconds )
{
if ( !bSaidPath )
{
bSaidPath = True;
if ( bHasBeacon )
W1.Disable('Touch');
ClientMessage("Spaming is not allowed... Retry after"@(LastPathTime+7)-Level.TimeSeconds@seconds...);
}
GoTo DoNothing;
}
else
{
if ( bHasBeacon )
W1.Enable('Touch');
bSaidPath = False;
LastPathTime = Level.TimeSeconds;
}
KeepGoing:
if ( PointReachable ( Destination ))
{
ClientMessage("Destination is Reachable, look around for Lamp-Beacon...");
if ( bHasBeacon )
{
if ( W1.Location != Destination )
W1.SetLocation(Destination);
}
else
W1 = Spawn(class 'WayBeacon', self, '',Destination);
}
else
{
Node = FindPathTo(Destination);
if ( Node != None )
{
log(GetHumanName()@found path: $Node.Name);
if ( bHasBeacon )
{
if ( W1.Location != Node.Location )
W1.SetLocation( Node.Location );
}
else
W1 = Spawn(class 'WayBeacon',self,'',Node.location);
if (W1 != None)
{
if ( Node.Base != None )
W1.SetBase(Node.Base);
ClientMessage("Path Found - Look For Lamp-Beacon");
}
}
else
{
ClientMessage("Could not find a Path to Destination Spot.");
log(GetHumanName()@didn't find path.);
}
}
DoNothing:
}
It is very operational, then I hit menu to start a tournament or restart map. It drives to End of game >>>
What do I do wrong here ?LogFile wrote:Code: Select all
DevAudio: Galaxy SetViewport: WindowsViewport0 XC_Engine: NotifyLevelChange() begin... ScriptLog: XC: Helper Win Created ScriptLog: XC: LevelChange XC_Engine: NotifyLevelChange() end Critical: FMallocWindows::Free Critical: FMallocWindows::Realloc Critical: 42E7F346 0 FArray Critical: FArray::Realloc Critical: 0*2 Critical: FMallocWindows::Free Critical: UObject::ExitProperties Critical: (StrProperty Botpack.TournamentPlayer.spreenote) Critical: UObject::Destroy Critical: (TFemale1 MH-Akemi_vs_Tomoko_R16.TFemale2) Critical: AActor::Destroy Critical: UObject::ConditionalDestroy Critical: (TFemale1 MH-Akemi_vs_Tomoko_R16.TFemale2) Critical: ShutupSound Critical: ULevel::DestroyActor Critical: (TFemale1 MH-Akemi_vs_Tomoko_R16.TFemale2) Critical: DissociateViewports Critical: UXC_GameEngine::LoadMap Critical: LocalMapURL Critical: UGameEngine::Browse Critical: ClientTravel Critical: UGameEngine::Tick Critical: UXC_GameEngine::Tick Critical: UpdateWorld Critical: MainLoop Exit: Executing UObject::StaticShutdownAfterError Exit: Executing UWindowsClient::ShutdownAfterError Exit: UGalaxyAudioSubsystem::ShutdownAfterError Log: DirectDraw End Mode Exit: UOpenGLRenderDevice::ShutdownAfterError Exit: Exiting. Uninitialized: Name subsystem shut down Uninitialized: Log file closed, 10/25/16 22:31:30
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
The class is using global variables that are not present in the target playerpawn calling the function.
The variable LastPathTime has a certain offset, in this case, sizeof(APlayerpawn) + 0.
In the (for example) TMale2 class that's calling the function, that offset corresponds to a different variable.
One way to solve this, is to globalize all checks by instead accessing a memory region that's not mis-identified.
Basically, you share all the time checks (this affects all players instead) but you operate on an actual separate memory region that doesn't overlap with the player's own variables.
The variable LastPathTime has a certain offset, in this case, sizeof(APlayerpawn) + 0.
In the (for example) TMale2 class that's calling the function, that offset corresponds to a different variable.
One way to solve this, is to globalize all checks by instead accessing a memory region that's not mis-identified.
Basically, you share all the time checks (this affects all players instead) but you operate on an actual separate memory region that doesn't overlap with the player's own variables.
Code: Select all
Replace:
LastPathTime;
with
class'XC_PlayerPawn'.default.LastPathTime;
-
- Godlike
- Posts: 6443
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
-
- Godlike
- Posts: 6443
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
I see something wrong at chapter path tweaking, bringing into stage TranslocStart. It's probably more wrong than expected.
If by chance (and I could see this) Bot carrier is passing through such point will lose flag translocating discarding CTF directives by ignoring stupid bCanTranslocate boolean - that query would be more sane than bullshiting with Flag.
What we have in original:and amazing default properties
Excuse me, but I don't see any SpecialCost here defined even is supposed to have one ?
Else probably we need this but I don't know if we will cause a strange effect:Or another friendly version:
Pass through this LiftExit for another point in Path-Net than TranslocDest ? November and such...
These I don't think are the best without SpecialCost but for sure what we have is not the right thing, Bot losing Flag...
Edit:
Now it looks better (first method). By spectating a heavy match and being "overtime" at end of Level it seems to happen this - not sure how often but I saw it twice:Resource which I study has a different structure nothing with "_Linker" in line 260, but it is above that... not sure if doesn't occur a call to Level which is removed (or... reloaded) it was a simple restart post game ended using the same map.
If by chance (and I could see this) Bot carrier is passing through such point will lose flag translocating discarding CTF directives by ignoring stupid bCanTranslocate boolean - that query would be more sane than bullshiting with Flag.
What we have in original:
Code: Select all
if ( (B.MyTranslocator == None) || (B.MyTranslocator.TTarget != None) )
return None;
B.TranslocateToTarget(self);
return self;
Code: Select all
defaultproperties
{
bSpecialCost=True
bStatic=False
bNoDelete=True
}
Else probably we need this but I don't know if we will cause a strange effect:
Code: Select all
if ( /*(B.MyTranslocator == None) || (B.MyTranslocator.TTarget != None) ||*/ !B.bCanTranslocate)
return None;
B.TranslocateToTarget(self);
return self;
Code: Select all
if ( (B.MyTranslocator == None) || (B.MyTranslocator.TTarget != None) )
return None;
if (B.bCanTranslocate)
B.TranslocateToTarget(self);
return self;
These I don't think are the best without SpecialCost but for sure what we have is not the right thing, Bot losing Flag...
Edit:
Now it looks better (first method). By spectating a heavy match and being "overtime" at end of Level it seems to happen this - not sure how often but I saw it twice:
Code: Select all
Log: Collecting garbage
Log: Purging garbage
Critical: appError called:
Critical: Assertion failed: _Linker->ExportMap(_LinkerIndex)._Object==this [File:C:\UTDev\Core\Src\UnObj.cpp] [Line: 260]
Critical: Windows GetLastError: The operation completed successfully. (0)
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UOpenGLRenderDevice::ShutdownAfterError
Critical: UObject::SetLinker
Critical: (Palette SGirlSkins.Palette68)
Critical: UObject::Destroy
Critical: (Palette SGirlSkins.Palette68)
Critical: UObject::ConditionalDestroy
Critical: (Palette SGirlSkins.Palette68)
Critical: DispatchDestroy
Critical: (47900: Palette SGirlSkins.Palette68)
Critical: DispatchDestroys
Critical: UObject::PurgeGarbage
Critical: UObject::CollectGarbage
Critical: XCGE_Garbage
Critical: ExitLevel
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ServerTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Exiting.
-
- Godlike
- Posts: 6443
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
A random crash occurred today related to state change UObject::blablaState made me to put back TickFix because it looks like it does a good job as usual, now I have on screen tickrate in MH2 and I can see what's the deal with and without TickFix. Looks like has not very nice tick fluctuations and tickrate goes down at empty server (interesting) but switching from state to the same state I don't know if it needs to deliver a crash. Often Bot in "FallingState" calls again "FallingState" with no issues, but for preventing future "fast state cascading" I added a sleep at beginning of Master State "Attacking" for letting tick to breath a bit - this seems to not affect Bot reflexes noticeable. So I saw another occurrence when tick affected turns code execution in trash.
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
You don't need TickFix or any timer fixes if you launch the server using XC_Server commandlet, as a matter of fact, tickrate is far better than anything other tools offer.
Some extra stuff to be seen in the release v19 build:
- Actor name resetter on clients. It's a workaround for non-servers to prevent ever-increasing memory usage and name hash complexity.
- Native functions that have an opcode number can now be replaced by (only) other native functions.
- Considering removing the 'same-variables' limitation on replacing replicated functions if they have no parameters, there shouldn't be any problems there.
** Example: CallForHelp()
- Expose to unrealscript the GetMapName and PlayerCanSeeMe fixes.
- Add a 'AllConnections' iterator
Some extra stuff to be seen in the release v19 build:
- Actor name resetter on clients. It's a workaround for non-servers to prevent ever-increasing memory usage and name hash complexity.
- Native functions that have an opcode number can now be replaced by (only) other native functions.
- Considering removing the 'same-variables' limitation on replacing replicated functions if they have no parameters, there shouldn't be any problems there.
** Example: CallForHelp()
- Expose to unrealscript the GetMapName and PlayerCanSeeMe fixes.
- Add a 'AllConnections' iterator
-
- Godlike
- Posts: 6443
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
I'm using CallForHelp as it is - looks helpful, MBot is a Bot, but extended a bit.
So, PlayerCanSeeMe might have an Uscript alias working properly ? Wow, it sounds interesting.
I would like to see an alias for "CanMoveTo" if possible or an UScript translation in DOT or such - eh, my dreams... This one is used by "ActorReachable". Understanding it might help me in properly tweaking some stuff...
Iterator AllConnections - Can we attack Empty connections ? Not bad at all.
I'm still trying to figure a way in tracing nearby terrain like with human eye.
So, PlayerCanSeeMe might have an Uscript alias working properly ? Wow, it sounds interesting.
I would like to see an alias for "CanMoveTo" if possible or an UScript translation in DOT or such - eh, my dreams... This one is used by "ActorReachable". Understanding it might help me in properly tweaking some stuff...
Iterator AllConnections - Can we attack Empty connections ? Not bad at all.
I'm still trying to figure a way in tracing nearby terrain like with human eye.
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
PlayerCanSeeMe cannot be replaced with a non-native func, it has a numbered opcode.
I'd need a dummy wrapper in order to achieve that.
Expect another test build inbetween this and release.
I'd need a dummy wrapper in order to achieve that.
Expect another test build inbetween this and release.
-
- Godlike
- Posts: 6443
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
Why this back-to at PlayerCanSeeMe ? It still did cause problems ? I did not see any crash since last fix.
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
I intend to expose all of the function related behaviour to the function replacement system, excepting dynamic arrays due to being fully hardcoded in the compiler.
-
- Adept
- Posts: 324
- Joined: Tue Mar 11, 2008 4:49 am
- Location: Midwest
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
I was told it's possible to use this to force mutators into the singleplayer ladder, but I'm confused as to how to actually do it. Can somebody please help me out with this? I'm really trying to get Nali Weapons 3 Gore Standalone to work in singleplayer.
-
- Godlike
- Posts: 1963
- Joined: Sat Sep 17, 2011 4:32 pm
- Personal rank: Dame. Vandora
- Location: TN, USA
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
We already are working on 1 thread about this, don't need to spread it out making a mess.Lee_Stricklin wrote:I was told it's possible to use this to force mutators into the singleplayer ladder, but I'm confused as to how to actually do it. Can somebody please help me out with this? I'm really trying to get Nali Weapons 3 Gore Standalone to work in singleplayer.
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
Beta changes:
* Partially moved AdminLogin hook to function replacement system.
* Moved GetWeapon hook to function replacement system.
* Replicated functions that take no parameters can be replaced.
* Native functions with an opcode number can be replaced (only with other native functions)
* Halfassed clientside name recycler (win32 only)
Function replacer actors can now be loaded on user demand.
Run the game at least once after installing this build and you'll see this new entry in XC_Engine.ini
* Partially moved AdminLogin hook to function replacement system.
* Moved GetWeapon hook to function replacement system.
* Replicated functions that take no parameters can be replaced.
* Native functions with an opcode number can be replaced (only with other native functions)
* Halfassed clientside name recycler (win32 only)
Function replacer actors can now be loaded on user demand.
Run the game at least once after installing this build and you'll see this new entry in XC_Engine.ini
Code: Select all
[XC_Engine.XC_Engine_Actor_CFG]
Description[0]=This list contains subclasses of XC_Engine.XC_Engine_Actor to be spawned
Description[1]=The main XC_Engine_Actor will call XC_Init() on these actors before InitGame()
Description[2]=The : symbol indicates that a certain package has to be loaded as condition
XCGE_Actors=Unreali:XC_Engine_UT99.XC_Engine_UT99_Actor
XCGE_Actors=s_SWAT:XC_Engine_TOs.XC_Engine_TOs_Actor
You do not have the required permissions to view the files attached to this post.
-
- Godlike
- Posts: 6443
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv
So XCGE_Actors defined in INI are spawned properly by XC_Engine very early, which means that several tweaks are doable without mutators by only defining what we need and XCGE will spawn that for us.
Else, some tweaks might be "waiting" - I was writing some lousy fix for that TriggerControl problem but... I'm waiting 4 seconds for other possible fixes first (by example, morphed to TriggerOpenTimed by a master game-type, etc.). Else the rest of fixes which needs speed might be helpful a lot using this way.
Good work, Higor!
Edit:
But something got a different turn right now, similar to an old problemSetEnemy is still attached in natives and UScript too ? (duplicate multiple executions ?). Now what it's wrong ?
All right I'll change WhatToDoNext using VisibleCollidingActors or... removing stupid code which already exist in function Killed... Epic .
Else, some tweaks might be "waiting" - I was writing some lousy fix for that TriggerControl problem but... I'm waiting 4 seconds for other possible fixes first (by example, morphed to TriggerOpenTimed by a master game-type, etc.). Else the rest of fixes which needs speed might be helpful a lot using this way.
Good work, Higor!
Edit:
But something got a different turn right now, similar to an old problem
Code: Select all
Critical: appError called:
Critical: SkaarjBerserker MH-The-Ancients.SkaarjBerserker3 (Function UnrealShare.ScriptedPawn.SetEnemy:0031) Runaway loop detected (over 10000000 iterations)
Exit: Executing UObject::StaticShutdownAfterError
Critical: FFrame::Serialize
Critical: ScriptDebugV
Critical: SkaarjBerserker3.SetEnemy
Critical: ScriptDebugV
Critical: SkaarjBerserker3.WhatToDoNext
Critical: ScriptDebugV
Critical: SkaarjBerserker3.ChooseAttackMode
Critical: AActor::ProcessState
Critical: Object SkaarjBerserker MH-The-Ancients.SkaarjBerserker3, Old State State UnrealShare.ScriptedPawn.Attacking, New State State UnrealShare.ScriptedPawn.Attacking
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UXC_ServerCommandlet::Main
Exit: Exiting.
All right I'll change WhatToDoNext using VisibleCollidingActors or... removing stupid code which already exist in function Killed... Epic .