XC_Engine [20] - XC_Core [7b] - XC_IpDrv
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
Yes, now this will gonna be cute and interesting... I'm loving those "aClass" deals.
Edit: Yep, I went to some of my presumptions getting over some of those replacements or adding lines.
One thing known by me which I was fixing at MBot was to not follow any sort of order if game has been ended and this is what I've added. At rocket tick... well... Not all A.I. are oriented to a "MoveTarget" monsters as I could figure are oriented in moving to a Location (focus) etc - see jumper class they seems to not use often such goal, also not always have target and... if rocket fell out of world tick should not be active in bDeleteMe situation. Here I'm agree for letting people to write these as they consider.
Aside I'm thinking at some applicability of iterators added, also I'm rethinking at Dynamic Mesh for some default matches as an option... hmm.
Edit2: On-Line testing a bit
Server v440 some classic game-types - client 436 works, client 440 works, client 440 mixed with an old IpDrv.dll might be badly crashing, so now looks like it is advisable to use 436 as it is and 440 as it is without mixing any files. Clients loaded with XC_Stuff looks like works normally with no major issues so far. Keep going...
Edit: Yep, I went to some of my presumptions getting over some of those replacements or adding lines.
One thing known by me which I was fixing at MBot was to not follow any sort of order if game has been ended and this is what I've added. At rocket tick... well... Not all A.I. are oriented to a "MoveTarget" monsters as I could figure are oriented in moving to a Location (focus) etc - see jumper class they seems to not use often such goal, also not always have target and... if rocket fell out of world tick should not be active in bDeleteMe situation. Here I'm agree for letting people to write these as they consider.
Aside I'm thinking at some applicability of iterators added, also I'm rethinking at Dynamic Mesh for some default matches as an option... hmm.
Edit2: On-Line testing a bit
Server v440 some classic game-types - client 436 works, client 440 works, client 440 mixed with an old IpDrv.dll might be badly crashing, so now looks like it is advisable to use 436 as it is and 440 as it is without mixing any files. Clients loaded with XC_Stuff looks like works normally with no major issues so far. Keep going...
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
A few things randomly happening at "server-travel" in local games between Levels (usually the same Level). What's wrong here ?
Edit: Figured Speech problem...
Edit2: I have replaced some ChallengeVoicePack things with others => Crashes gone. Now it's Stable as rock and my CTFGame has returned to "TakeTheirFlag". I added "SearchAndDestroy" for any MonsterHunt game and I got it functional.
And I believe that function "GetOrderString" might be wrong but I'm not sure if is called because TournamentGameReplicationInfo has another the same one...
Code: Select all
XC_Engine: NotifyLevelChange() begin...
ScriptLog: XC: Helper Win Created
ScriptLog: XC: LevelChange
XC_Engine: NotifyLevelChange() end
XC_Engine: Restoring Function UnrealI.WarLord.PlayMovingAttack
XC_Engine: Restoring Function UnrealI.WarLord.PlayRangedAttack
XC_Engine: Restoring Function UnrealI.Titan.SlapDamageTarget
XC_Engine: Restoring Function UnrealI.Titan.PunchDamageTarget
XC_Engine: Restoring Function UnrealI.Titan.SpawnRock
XC_Engine: Restoring Function UnrealShare.Tentacle.PlayRangedAttack
XC_Engine: Restoring Function UnrealI.SkaarjTrooper.PlayFiring
XC_Engine: Restoring Function UnrealI.SkaarjTrooper.PlayMovingAttack
XC_Engine: Restoring Function UnrealI.SkaarjTrooper.startup.SetHome
XC_Engine: Restoring Function UnrealI.SkaarjTrooper.startup.BeginState
XC_Engine: Restoring Function UnrealI.SkaarjBerserker.WhatToDoNext
XC_Engine: Restoring Function UnrealShare.SkaarjWarrior.SpawnTwoShots
XC_Engine: Restoring Function UnrealShare.Skaarj.SpinDamageTarget
XC_Engine: Restoring Function UnrealShare.Skaarj.ClawDamageTarget
XC_Engine: Restoring Function UnrealShare.Slith.ClawDamageTarget
XC_Engine: Restoring Function UnrealI.Queen.SpawnShot
XC_Engine: Restoring Function UnrealI.Pupae.PlayMeleeAttack
XC_Engine: Restoring Function UnrealShare.Nali.AdjustHitLocation
XC_Engine: Restoring Function UnrealShare.Nali.Killed
XC_Engine: Restoring Function UnrealI.Mercenary.SprayTarget
XC_Engine: Restoring Function UnrealI.GiantGasbag.SpawnBelch
XC_Engine: Restoring Function UnrealI.Gasbag.SpawnBelch
XC_Engine: Restoring Function UnrealI.Gasbag.PlayRangedAttack
XC_Engine: Restoring Function UnrealShare.Cow.Grazing.EndState
XC_Engine: Restoring Function UnrealShare.Brute.PlayRangedAttack
XC_Engine: Restoring Function UnrealShare.BabyCow.Grazing.PickDestination
XC_Engine: Restoring Function UnrealShare.BabyCow.Grazing.TakeDamage
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.StakeOut.BeginState
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.TacticalMove.BeginState
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.TacticalMove.PickDestination
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.PlayCombatMove
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.TacticalMove.Timer
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.Charging.Timer
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.Threatening.TakeDamage
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.Guarding.TakeDamage
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.Patroling.TakeDamage
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.StartRoaming
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.RelativeStrength
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.MeleeDamageTarget
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.startup.SetHome
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.Killed
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.StakeOut.AdjustAim
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.ChooseTeamAttackFor
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.FireProjectile
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.SeePlayer
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.AttitudeTo
XC_Engine: Restoring Function UnrealShare.NaliRabbit.Evade.PickDestination
XC_Engine: Restoring Function Engine.Pawn.AdjustHitLocation
XC_Engine: Restoring Function UnrealShare.BruteProjectile.Flying.BlowUp
XC_Engine: Restoring Function UnrealI.RazorBladeAlt.Flying.Tick
XC_Engine: Restoring Function Botpack.ShockProj.SuperExplosion
XC_Engine: Restoring Function Botpack.UT_Eightball.FireRockets.BeginState
XC_Engine: Restoring Function UnrealShare.Eightball.FireRockets.BeginState
XC_Engine: Restoring Function UnrealShare.Eightball.NormalFire.Tick
XC_Engine: Restoring Function UnrealShare.Eightball.AltFiring.Tick
XC_Engine: Restoring Function UnrealShare.Flashlight.Activated.Tick
XC_Engine: Restoring Function Engine.Pickup.UsedUp
XC_Engine: Restoring Function Botpack.JumpSpot.SpecialHandling
XC_Engine: Restoring Function Botpack.JumpSpot.SpecialCost
XC_Engine: Restoring Function Botpack.TranslocStart.SpecialHandling
XC_Engine: Restoring Function Engine.Weapon.CheckVisibility
XC_Engine: Restoring Function UnrealShare.Boulder.PostBeginPlay
XC_Engine: Restoring Function Engine.Decoration.Frag
XC_Engine: Restoring Function Engine.Decoration.skinnedFrag
XC_Engine: Restoring Function Engine.Decoration.Destroyed
XC_Engine: Restoring Function Engine.Decoration.ZoneChange
XC_Engine: Restoring Function Botpack.DeathMatchPlus.ChangeName
XC_Engine: Restoring Function Engine.WayBeacon.Touch
XC_Engine: Restoring Function Engine.PlayerPawn.ShowPath
XC_Engine: Restoring Function Engine.PlayerPawn.ShowInventory
XC_Engine: Restoring Function Engine.GameInfo.Killed
XC_Engine: Restoring Function Engine.GameInfo.ScoreKill
XC_Engine: Restoring Function UnrealI.Queen.Teleporting.Tick
XC_Engine: Restoring Function UnrealI.Queen.Teleporting.ChooseDestination
XC_Engine: Restoring Function UnrealShare.ScriptedPawn.SetEnemy
XC_Engine: Restoring Function Botpack.AssaultRandomizer.CostEnabled.SpecialCost
XC_Engine: Restoring Function UnrealShare.Transporter.Trigger
XC_Engine: Restoring Function Botpack.DistanceViewTrigger.Trigger
XC_Engine: Restoring Function Botpack.UT_invisibility.Activated.EndState
XC_Engine: Restoring Function Botpack.Bot.SetOrders
XC_Engine: Restoring Function Engine.Weapon.SpawnCopy
XC_Engine: Restoring Function Engine.Mutator.AddMutator
XC_Engine: Reverting RELIABLE_BUFFER assertion hack
XC_Engine: Reverting GetWeapon hook
XC_Engine: Reverting PlayerPawn.AdminLogin hook
Init: Shut down moving brush tracker for Level CTF-Donut_R16.MyLevel
Log: Collecting garbage
Log: Purging garbage
Log: 0.0ms Unloading: Package SkeletalChars
Log: 0.0ms Unloading: Package MultiMesh
Log: 0.0ms Unloading: Package EpicCustomModels
Log: 0.0ms Unloading: Package NsCTF3
Log: 0.0ms Unloading: Package CommandoSkins
Critical: appError called:
Critical: Assertion failed: _Linker->ExportMap(_LinkerIndex)._Object==this
[File:R:\Projects\nacput\Ut436\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: UD3D9RenderDevice::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: (50581: 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.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 09/04/16 13:47:52
Edit2: I have replaced some ChallengeVoicePack things with others => Crashes gone. Now it's Stable as rock and my CTFGame has returned to "TakeTheirFlag". I added "SearchAndDestroy" for any MonsterHunt game and I got it functional.
And I believe that function "GetOrderString" might be wrong but I'm not sure if is called because TournamentGameReplicationInfo has another the same one...
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
I think I accidentally disabled the Sort, PlayerSpeech hooks in that last test build.
In the meantime, I'm going to move my test launcher's FPS limiter to XCGE.
This should allow quick FPS limit changes by using the 'fps' command.
No more messing around with video renderer settings.
EDIT:
This successfuly lets you grab ServerPackages and ServerActors using GET commands quite safely, regardless of array size and chars needed.
I'm pretty much trying to implement remaining SCF's fixes into XCGE
In the meantime, I'm going to move my test launcher's FPS limiter to XCGE.
This should allow quick FPS limit changes by using the 'fps' command.
No more messing around with video renderer settings.
EDIT:
This successfuly lets you grab ServerPackages and ServerActors using GET commands quite safely, regardless of array size and chars needed.
Code: Select all
void UXC_GameEngine::PerformGetCommand(const TCHAR* Str, FOutputDevice& Ar)
{
// Get a class default variable.
TCHAR ClassName[256], PropertyName[128], ArrayIdx[16];
UClass* Class = NULL;
UProperty* Property = NULL;
INT Idx = 0;
//Get objects and optionally index
if (ParseToken(Str, ClassName, ARRAY_COUNT(ClassName), 1) && (Class = FindObject<UClass>(ANY_PACKAGE, ClassName)) != NULL)
{
if (ParseToken(Str, PropertyName, ARRAY_COUNT(PropertyName), 1) && (Property = FindField<UProperty>(Class, PropertyName)) != NULL)
{
if (ParseToken(Str, ArrayIdx, ARRAY_COUNT(ArrayIdx), 1))
Idx = Clamp(appAtoi(ArrayIdx), 0, Property->ArrayDim - 1);
}
else Ar.Logf(NAME_ExecWarning, TEXT("Unrecognized property %s"), PropertyName);
}
else Ar.Logf(NAME_ExecWarning, TEXT("Unrecognized class %s"), ClassName);
if ( !Class || !Class->GetPropertiesSize() || !Property )
return;
BYTE* DataOffset = ((BYTE*)Class->GetDefaultObject()) + Property->Offset + Property->ElementSize * Idx;
//Determine best allocation method
if ( Property->IsA(UStrProperty::StaticClass() ) ) //Print directly without copying
Ar.Log( *(TCHAR**)DataOffset );
else if ( Property->IsA(UNameProperty::StaticClass() ) ) //Print directly without copying
Ar.Log( *(*(FName*)DataOffset) );
else if ( Property->IsA(UArrayProperty::StaticClass() ) ) //Dynamic array, evaluate buffer size...
{
UProperty* Inner = ((UArrayProperty*)Property)->Inner;
FArray* Arr = (FArray*)DataOffset;
TCHAR* Buffer;
if ( Inner->IsA( UStrProperty::StaticClass() ) )
{
//Calculate buffer size
FString* StrList = (FString*) Arr->GetData();
INT BufferSize = 3; // '(' ')' 'NULL' chars
for ( INT i=0 ; i<Arr->Num() ; i++ )
BufferSize += StrList[i].Len() + 3; // "", chars
Buffer = (TCHAR*)appMalloc( BufferSize * sizeof(TCHAR), TEXT("SAFE_GET"));
}
else
{ //1024 chars per INI line (up to 64 lines)
Buffer = (TCHAR*)appMalloc( ::Clamp(Arr->Num(), 1, 64) * 1024 * sizeof(TCHAR), TEXT("SAFE_GET"));
}
Property->ExportText(Idx, Buffer, (BYTE*)(Class->GetDefaultObject()), (BYTE*)(Class->GetDefaultObject()), PPF_Localized);
Ar.Log(Buffer);
appFree( Buffer );
}
else //Simple property, INI/T3D formats should restrict this to 1024 chars
{
TCHAR Temp[1024];
Property->ExportText(Idx, Temp, (BYTE*)(Class->GetDefaultObject()), (BYTE*)(Class->GetDefaultObject()), PPF_Localized);
Ar.Log(Temp);
}
}
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
ReplaceFunction has a few extra limitations for replicated functions.
If the parameters, locals are changed the net packets will be borked (if the func has parameters) so as workaround I simply made it so that both original and replacement must have the exact same parameter/locals setup.
So if there's a need to use extra variables, delegate that task to a 'final' function.
Also, XC_Core will have a XC_ServerCommandlet class that'll run the server using QueryPerformanceCounter based timers in windows and gettimeofday ones in Linux, with more precise sleeps.
This pretty much solved the 63.9 fps issue on my test dedicated server (65TR), changing it to an average of 65.0
Kind of sucks if you have a server with a fixed command line launcher (Fragnet, NFO) but if you can get them to modify it you're set...
With this change the Clock/Unclock natives in linux should actually return something other than a negative number.
Then a massive server log spam exploit getting patched... that's pretty much all I'll say.
If the parameters, locals are changed the net packets will be borked (if the func has parameters) so as workaround I simply made it so that both original and replacement must have the exact same parameter/locals setup.
So if there's a need to use extra variables, delegate that task to a 'final' function.
Also, XC_Core will have a XC_ServerCommandlet class that'll run the server using QueryPerformanceCounter based timers in windows and gettimeofday ones in Linux, with more precise sleeps.
This pretty much solved the 63.9 fps issue on my test dedicated server (65TR), changing it to an average of 65.0
Kind of sucks if you have a server with a fixed command line launcher (Fragnet, NFO) but if you can get them to modify it you're set...
With this change the Clock/Unclock natives in linux should actually return something other than a negative number.
Then a massive server log spam exploit getting patched... that's pretty much all I'll say.
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
Using ReplaceFunction at Carcasses I was trying to tweak a bit that stupid Krallcarcass height Bug using DynamicMesh. I used to tag Carcass and XC actor for getting them together. Logs confirm presence but I'm not sure if this is not a wrong idea because it doesn't looks like it helps like for creatures where somehow it worked in a way. I detached Actor in carcass's destruction. At a moment some funky logs were showing (Carcass near Door ? ). I'm trying to recreate those logs
However it's memory expensive and I don't know if I do something wrong because it's like doesn't even exist.
Else I see KrallCarcass0 twice. It's about that "recycle actors" system ?
Edit:
AT a moment before to add features might be recommended a revision for something older:
Occurrence bUseLevelHook = True >> Server 440 UT.exe >> Client the same 440 - Impossible to run in this contextIt's nothing unusual, I did many times such tests but right now bUseLevelHook is no longer an option. Both client and server have the same files.
Code: Select all
ScriptLog: I have Tag >> KrallCarcass0
Log: Allocated 21972 bytes for XC_PrimitiveMesh0
ScriptLog: I have Tag >> KrallCarcass1
Log: Allocated 21972 bytes for XC_PrimitiveMesh1
Log: Attempting to deallocate collision cache for XC_PrimitiveMesh1
ScriptLog: Removing MH-Akemi_vs_Tomoko_Rv.XC_PrimitiveMesh1 and self...
Log: Attempting to deallocate collision cache for XC_PrimitiveMesh0
ScriptLog: Removing MH-Akemi_vs_Tomoko_Rv.XC_PrimitiveMesh0 and self...
ScriptLog: I have Tag >> KrallCarcass0
Log: Allocated 21972 bytes for XC_PrimitiveMesh0
Log: Attempting to deallocate collision cache for XC_PrimitiveMesh0
ScriptLog: Removing MH-Akemi_vs_Tomoko_Rv.XC_PrimitiveMesh0 and self...
Else I see KrallCarcass0 twice. It's about that "recycle actors" system ?
Edit:
AT a moment before to add features might be recommended a revision for something older:
Occurrence bUseLevelHook = True >> Server 440 UT.exe >> Client the same 440 - Impossible to run in this context
Code: Select all
XC_Engine: Checking for Moving Brush Tracker insertion...
Init: Initialized moving brush tracker for Level MH-Akemi_vs_Tomoko_Rv.MyLevel
XC_Engine: Browse() End
Init: Game engine initialized
Init: XC_Engine Travel Manager initialized
Init: XC_Engine Time Manager initialized
Log: Startup time: -17809.900527 seconds
ScriptLog: MH-Akemi_vs_Tomoko_Rv.Lightbadie0 > has started Level tweaking...
ScriptLog: Lightbadie0 operated...
ScriptLog: Ignited TickSpy... Attempt to get Configured TickRate...
ScriptLog: MH-Akemi_vs_Tomoko_Rv.Ticker0 > Detected TickRate set at 30
ScriptLog: MH-Akemi_vs_Tomoko_Rv.Ticker0 > Ideal Tick Interval has been computed at 36
ScriptLog: TickRate went 19
ScriptLog: TickRate went 19
Critical: UpdatePreNet
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 09/10/16 13:02:37
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
This build uses non-RTDSC timers for the AppSeconds, Clock, UnClock natives and in UserFlags stats (Net).
New commandlet XC_Core.XC_ServerCommandlet that uses these timers as well.
FindObject native bugfixed when passed without a third parameter.
Mid level garbage Collection no longer causes level switch crash (small problem with replaced functions)
Players cannot join the server before sending their URL parameters, neither bypass the server passwod query.
Control channel cannot be used to spam a server's log.
Function replacer:
- PlayerPawn.ViewPlayer, PlayerPawn.ViewPlayerNum ported to new function replacement system.
- DynamicLoadObject native replaced with a crash free version.
- Disables ServerCrashFix's DLO and EXEC hooks to prevent crashes.
// Windows timers use QueryPerformanceCounter
// Linux timers use gettimeofday
New commandlet XC_Core.XC_ServerCommandlet that uses these timers as well.
FindObject native bugfixed when passed without a third parameter.
Mid level garbage Collection no longer causes level switch crash (small problem with replaced functions)
Players cannot join the server before sending their URL parameters, neither bypass the server passwod query.
Control channel cannot be used to spam a server's log.
Function replacer:
- PlayerPawn.ViewPlayer, PlayerPawn.ViewPlayerNum ported to new function replacement system.
- DynamicLoadObject native replaced with a crash free version.
- Disables ServerCrashFix's DLO and EXEC hooks to prevent crashes.
// Windows timers use QueryPerformanceCounter
// Linux timers use gettimeofday
You do not have the required permissions to view the files attached to this post.
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
A short test was working now, I see logs, I think Carcass was on stair (maybe I don't need to mess with that PrimitiveMesh)
If I'm not mistaking looks like is not the best reaction of PrimitiveMesh...
Edit: My ShowPath went borked even with FINAL declared... I'll see how do I need to write it .The CheckPath() code is older (Posted a few posts ago) + variables included in abstract class. Perhaps this stuff has limitation as my happiness related to super tweaks so we are limited somehow:
Code: Select all
Log: Allocated 21972 bytes for XC_PrimitiveMesh0
Log: Allocated 21972 bytes for XC_PrimitiveMesh1
Log: Allocated 21972 bytes for XC_PrimitiveMesh2
Log: Plane 35: Overlapping
Log: Plane 48: Overlapping
Log: Plane 49: Overlapping
Log: Plane 101: Overlapping
Log: Plane 148: Overlapping
Log: Plane 208: Overlapping
Log: Plane 232: Overlapping
Log: Plane 234: Overlapping
Log: Plane 283: Overlapping
Log: Plane 359: Overlapping
Log: Plane 364: Overlapping
Log: Plane 407: Overlapping
Log: Allocated 21972 bytes for XC_PrimitiveMesh3
Log: Allocated 21972 bytes for XC_PrimitiveMesh4
ScriptLog: TickRate went 24
Log: Allocated 21972 bytes for XC_PrimitiveMesh5
Log: Allocated 21972 bytes for XC_PrimitiveMesh6
ScriptLog: TickRate went 23
Log: _43_Point 2 vs LocalStart: (-801.020020,1592.621216) [23,-33,25]
Log: Diff signs!
Log: _43_ Point to player (26.399996,40.040001)
Log: WTF 0,1: plane 21.207283 to 4.946692 XY:(0.550459,0.834862,0.000000,W:-2.588624)
Log: _53_Point 2 vs LocalStart: (-29.378801,56.964363) [1,-18,-51]
Log: Diff signs!
Log: _53_ Point to player (4.400001,-3.960000)
Log: WTF 0,1: plane -2.376982 to -8.873497 XY:(0.743294,-0.668965,0.000000,W:24.975685)
Log: Point 0,1: plane reachable -2.376982 to -8.873497 XY:(0.743294,-0.668965,W:24.975685)
Log: _53_Point 0 vs LocalStart: (-267.579407,205.300781) [5,-14,-52]
Log: Diff signs!
Log: _53_ Point to player (9.459999,15.620001)
Log: WTF 1,2: plane -0.757620 to -1.444097 XY:(0.518035,0.855360,0.000000,W:3.162208)
Log: Point 1,2: plane reachable -0.757620 to -1.444097 XY:(0.518035,0.855360,W:3.162208)
Log: _57_Point 2 vs LocalStart: (-1010.592041,-2565.618164) [2,17,-51]
Log: _67_Point 2 vs LocalStart: (-115.821198,190.719513) [1,-21,18]
Log: Diff signs!
Log: _67_ Point to player (14.630000,-3.519999)
Log: WTF 0,1: plane 0.674496 to -1.130672 XY:(0.972254,-0.233926,0.000000,W:18.172426)
Log: Point 0,1: plane reachable 0.674496 to -1.130672 XY:(0.972254,-0.233926,W:18.172426)
Log: _67_Point 0 vs LocalStart: (-293.255615,-6.828453) [5,-6,-51]
Log: _68_Point 2 vs LocalStart: (143.239792,-15.523430) [4,-3,46]
Log: Diff signs!
Log: _68_ Point to player (-5.389998,-18.920000)
Log: WTF 0,1: plane -11.210918 to -11.057821 XY:(-0.273982,-0.961735,0.000000,W:13.786142)
Log: _69_Point 2 vs LocalStart: (43.559998,376.111908) [14,-17,40]
Log: _73_Point 2 vs LocalStart: (16.552856,565.491455) [29,-32,48]
Log: _76_Point 2 vs LocalStart: (466.817932,5201.562012) [20,-30,26]
Log: _77_Point 2 vs LocalStart: (-2.613617,-570.471863) [1,-8,42]
Log: _77_Point 0 vs LocalStart: (-203.570404,1047.742065) [21,-27,37]
Log: Diff signs!
Log: _77_ Point to player (38.279999,33.000004)
Log: WTF 1,2: plane 8.730676 to -1.249667 XY:(0.757410,0.652940,0.000000,W:10.543424)
Log: Point 1,2: plane reachable 8.730676 to -1.249667 XY:(0.757410,0.652940,W:10.543424)
Log: _80_Point 2 vs LocalStart: (212.379196,198.237610) [14,-25,20]
Log: _80_Point 0 vs LocalStart: (474.344177,914.039795) [2,-26,16]
NetComeGo: Close XC_TcpipConnection2 09/12/16 08:22:43
Log: Closing by request
Edit: My ShowPath went borked even with FINAL declared... I'll see how do I need to write it .
Edit2:Nvm, I figured how to deal with it - calling another function to not have different properties size. For such case exiting local game seems to deliver some Malloc Crash 0x2 etc... And this crash happens after using changed formula...Log wrote: ScriptWarning: ReplaceFunction: [NET] ShowPath and Tw_ShowPath have different properties size
Code: Select all
exec function Tw_ShowPath()
{
local Actor Node;
CheckPath();
}
hm...Crash_Log wrote: XC_Engine: NotifyLevelChange() begin...
ScriptLog: XC: Helper Win Created
ScriptLog: XC: LevelChange
XC_Engine: NotifyLevelChange() end
Critical: FMallocWindows::Free
Critical: FMallocWindows::Realloc
Critical: 42F91D80 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_Rv.TFemale1)
Critical: AActor::Destroy
Critical: UObject::ConditionalDestroy
Critical: (TFemale1 MH-Akemi_vs_Tomoko_Rv.TFemale1)
Critical: ShutupSound
Critical: ULevel::DestroyActor
Critical: (TFemale1 MH-Akemi_vs_Tomoko_Rv.TFemale1)
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: UD3D9RenderDevice::ShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 09/12/16 19:30:11
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
Stop mixing game binaries.
Keep v440 with v440, v436 with v436, v451 with v451 stuff.
===
Example of on-demand map hotfix (DripGenerator).
Detects if class is loaded, attempts to load fix if so, applies the fix IF the map requires it while allowing clients to run it.
This is an example of user controlled resource loading as there's no dependancy/linking to the class, pretty useful to avoid loading unused resources (in this case, DripGenerator class, sound and model)
Keep v440 with v440, v436 with v436, v451 with v451 stuff.
===
Example of on-demand map hotfix (DripGenerator).
Detects if class is loaded, attempts to load fix if so, applies the fix IF the map requires it while allowing clients to run it.
This is an example of user controlled resource loading as there's no dependancy/linking to the class, pretty useful to avoid loading unused resources (in this case, DripGenerator class, sound and model)
You do not have the required permissions to view the files attached to this post.
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
This is what I did - only 440 binaries for testing purpose.Higor wrote:Stop mixing game binaries.
Keep v440 with v440, v436 with v436, v451 with v451 stuff.
If I'm not calling function screwed with "replacefunction" game do travel normally, else see result up there. I set rememberspot and I try to find it - it works but... crap happens at map switching...
Because Function was different in size I did not used Different in size things I CALLED other one there ONLY in authority not simulated. I don't see other warnings...
[attachment=0]NsUTw.7z[/attachment]
I have simply called other Custom function from REPLACED ONE... Go figure what happens then...
Just do a check at ReplaceFunction or whatever OpCode or heck knows what is there.
You do not have the required permissions to view the files attached to this post.
-
- Inhuman
- Posts: 958
- Joined: Wed Mar 31, 2010 9:02 pm
- Personal rank: I am quite rank.
- Location: MrLoathsome fell out of the world!
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
Really? The 440 crap has physics stuff all broken online. Who knows what the hell else in it isnt right.sektor2111 wrote:This is what I did - only 440 binaries for testing purpose.
I scrapped all that junk.
436 is now it on my servers, and if the clients have trouble, then can just ditch whatever crappy server version
they are trying to use as client, *and should't be anyway.
blarg
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
440 if is screwed or not I was testing That pathing stuff which I was tweaking.
Results are as follows:
- if I don't call that function everything is fine;
- if I call it everything works in game properly but not at purging Garbage operation between Levels (so called Server-Travel process) because it was an OFF-Line game test.
After last update I have noticed Warning ShowPath and Tw_ShowPath differs in size (I used new variables), so I went to move stuff in other function CheckPath called from Tw_ShowPath. Functional but not in trash collecting section between Levels. I'll bet on 100$ that happens in 436 as well, something is still borked with that ReplaceFunction Vs Purging Garbage.
Edit: Okay, Interesting deal at Drip, but Timer code used will be Another one (not state or state) but more Sanitized because it does the same errors like precipitation craps. Happily Recommending:I don't make any energy saving procedure at sanitizers.
Last time I got tired of fixing game-types spawning sh!te without checking if they were ever spawned.
I'm gonna add this fix in NsUTw too...
Results are as follows:
- if I don't call that function everything is fine;
- if I call it everything works in game properly but not at purging Garbage operation between Levels (so called Server-Travel process) because it was an OFF-Line game test.
After last update I have noticed Warning ShowPath and Tw_ShowPath differs in size (I used new variables), so I went to move stuff in other function CheckPath called from Tw_ShowPath. Functional but not in trash collecting section between Levels. I'll bet on 100$ that happens in 436 as well, something is still borked with that ReplaceFunction Vs Purging Garbage.
Edit: Okay, Interesting deal at Drip, but Timer code used will be Another one (not state or state) but more Sanitized because it does the same errors like precipitation craps. Happily Recommending:
Code: Select all
function Timer()
{
local XC_DripFixParticle d;
if ( Level.Game != None && Level.Game.bGameEnded ) //Stop bullshitting in useless game state
goto StopStupidSpam;
d = Spawn(class'XC_DripFixParticle'); //We *TRY* this - a BSP problem might do sucks here
if ( d != None && !d.bDeleteMe )
{
d.DrawScale = 0.5+FRand()*DripVariance;
if ( DripTexture != None )
d.Skin = DripTexture;
}
if ( bTimerLoop )
SetTimer(DripPause+FRand()*DripPause,True);
StopStupidSpam: //Null bellow
}
Last time I got tired of fixing game-types spawning sh!te without checking if they were ever spawned.
I'm gonna add this fix in NsUTw too...
-
- Godlike
- Posts: 1866
- Joined: Sun Mar 04, 2012 6:47 pm
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
Not needed, mutators can't kill the particle and the drip has bCollideWhenPlacing set to false. Only a spawn notify can deny this and has to specifically target the particle.
The particles will self-destruct after their first physics tick if they spawn outside of the world, and since they're not subclassed from Decoration the log won't be spammed.
I don't understand the deal with those gotos, just return.
The particles will self-destruct after their first physics tick if they spawn outside of the world, and since they're not subclassed from Decoration the log won't be spammed.
Code: Select all
if ( d != None && !d.bDeleteMe )
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
Actually the most of my stuff is not using return any more. Else I did not see anything rammed at this point. MBot uses goto a lot and I have Bots in any game... I might be wrong here but... I know well some rare indeed and random effects of "return;" so I'm not gonna use it. You know what "Ret" instruction does...
-
- Godlike
- Posts: 2928
- Joined: Fri Sep 25, 2015 9:01 pm
- Location: moved without proper hashing
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
Isn't it just a GOTO to the end of function block?sektor2111 wrote:You know what "Ret" instruction does...
"If Origin not in center it be not in center." --Buggie
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: XC_Engine [18] - XC_Core [6] - XC_IpDrv
In assembly RET = return address is popped from stack = end of program - written in a machine code tutorial for Z80 processors.
A RECALL for 1000 times MONSTERSPAWN types does return, result, YOU DON'T SEE their death in CTF-FACE (my controller shows all deaths of monsters) - except those super-duper "error free" types, at a moment server simply exit because or return dumbness from that TAKEDAMAGE sh!t. I KNOW WHAT I'm saying, and I don't need to mention a mutator soup + some old MHBotyman what it does because I abused return in mutate command - IT has STOPPED working. Then I decided to send code at end of function if conditions are not accomplished - in case that you have fail to notice this is what I was doing for almost 5 months.
The meaning of return must be wise used else I cannot be sure if you don't screw things - rare but it looks like might happen.
My sanitizer was:
If (Enemy != None)
GoToState('Attacking');
Those codes were something like
If ( Enemy == None )
return;
GoToState('Attacking');
To be honest My Way never disturbed me, but never. If I'm wrong here that's it, I'm not the single one - I saw smarty ones messing up like in preschool...
Aside, it looks like with a new replication defined for players and Bots game runs good, I see that some timers removed make things to feel a bit different.
A RECALL for 1000 times MONSTERSPAWN types does return, result, YOU DON'T SEE their death in CTF-FACE (my controller shows all deaths of monsters) - except those super-duper "error free" types, at a moment server simply exit because or return dumbness from that TAKEDAMAGE sh!t. I KNOW WHAT I'm saying, and I don't need to mention a mutator soup + some old MHBotyman what it does because I abused return in mutate command - IT has STOPPED working. Then I decided to send code at end of function if conditions are not accomplished - in case that you have fail to notice this is what I was doing for almost 5 months.
The meaning of return must be wise used else I cannot be sure if you don't screw things - rare but it looks like might happen.
My sanitizer was:
If (Enemy != None)
GoToState('Attacking');
Those codes were something like
If ( Enemy == None )
return;
GoToState('Attacking');
To be honest My Way never disturbed me, but never. If I'm wrong here that's it, I'm not the single one - I saw smarty ones messing up like in preschool...
Aside, it looks like with a new replication defined for players and Bots game runs good, I see that some timers removed make things to feel a bit different.