Arenas and/or Replacements - Stories and Facts
Posted: Sat Jun 13, 2020 7:15 am
More methods have been developed these years when was coming to replacing a stock weapon with another one child of stock weapon, there are methods for preventing a recursive crash replacement. Me one I don't have these even if my mods were using replacements EUT_Eightball, Eminigun2, EPulseGun.
You can enforce a double check at weapon, or you can use a sort of "first-check" method - perhaps is faster than a double check.
Let's see "mad" weapon definition:
Crusher code is the simple code which is NOT RECOMMENDED:
This will cause a recursive replacement because AdvancedRocketlauncher is accomplishing test IF condition "(It is an Expanded (ut_Eighball))" and running code in infinity. UE1 will stop infinity at a number of such calls crashing game.
Some double check code would prevent a recursive replacement by testing weapon twice
Using "class" type replacement is not always healthy because the same ammo type used by a child class not mentioned can be removed/replaced causing weapon which was not replaced to do a recursive give-ammo problem or other when it wants to initialize operation - doubleenforcer empty crap uses the same ammo as enforcer which is replaced making a full mess if it's not replaced at once with parent class.
"First-check" method make code to finish replacement if weapon found is OUR weapon preventing future checks:This initial check will throw out replacement function with a positive response without any future check. No pain, no headaches.
And then ?
And then pro coders don't need more such information as long as they know better what to do even having pro-replacements written, this information is basic for people writing some codes from time to time.
The rest of options for some weapon mod would need to take in account a "default weapon" as long as they might let pawns unarmed and complaining later for other reasons than their own reasons - XC_MonsterHunt was claimed as leaving pawn unarmed when was used with some CS mod. Oh well, XC_MonsterHunt in pure format is not letting pawn unarmed, here the problem has come with CS not XC_MonsterHunt because it was turning off any unknown weapon instead of replacing it/them properly. To not forget that XC_MonsterHunt has configurable replacements which can use all sort of weapons and ammo types, it's a matter of admin-knowledge. Button-Admin (no offenses) types capable to only start/stop server and editing some 3 lines in whatever INI file won't get what a configurable replacement is capable to do and how mobile and helpful is such a configuration. Here the stage need some attention, when pawn already has a replacement weapon, other weapon replaced with the same thing owned by perhaps should not have a duplicate copy - weapon without MyMarker.
Next type of modifiers might do delayed replacements allowing all weaponry to be initialized and figuring after a few milliseconds what weapon is where and what does it do in order to not break pawn's inventory chain.
You can enforce a double check at weapon, or you can use a sort of "first-check" method - perhaps is faster than a double check.
Let's see "mad" weapon definition:
Code: Select all
class AdvacedRocketLauncher expands UT_Eightball;
..
..
Code: Select all
if (Other.IsA('UT_Eightball'))
{
ReplaceWith(Other,"MyPackage.AdvancedRocketlauncher");
return False;
}
Some double check code would prevent a recursive replacement by testing weapon twice
Code: Select all
if ( AdvancedRocketLauncher(Other) == None && UT_EightBall(Other) != None ) //When replacement is a child, Not our weapon right now, but it's a parent which has to be replaced
{
ReplaceWith(Other,"MyPackage.AdvancedRocketLauncher");
return False;
}
"First-check" method make code to finish replacement if weapon found is OUR weapon preventing future checks:
Code: Select all
//Position 1)
if (Other.IsA('AdvancedRocketLauncher'))
return True;
...
//Next replacements
And then ?
And then pro coders don't need more such information as long as they know better what to do even having pro-replacements written, this information is basic for people writing some codes from time to time.
The rest of options for some weapon mod would need to take in account a "default weapon" as long as they might let pawns unarmed and complaining later for other reasons than their own reasons - XC_MonsterHunt was claimed as leaving pawn unarmed when was used with some CS mod. Oh well, XC_MonsterHunt in pure format is not letting pawn unarmed, here the problem has come with CS not XC_MonsterHunt because it was turning off any unknown weapon instead of replacing it/them properly. To not forget that XC_MonsterHunt has configurable replacements which can use all sort of weapons and ammo types, it's a matter of admin-knowledge. Button-Admin (no offenses) types capable to only start/stop server and editing some 3 lines in whatever INI file won't get what a configurable replacement is capable to do and how mobile and helpful is such a configuration. Here the stage need some attention, when pawn already has a replacement weapon, other weapon replaced with the same thing owned by perhaps should not have a duplicate copy - weapon without MyMarker.
Next type of modifiers might do delayed replacements allowing all weaponry to be initialized and figuring after a few milliseconds what weapon is where and what does it do in order to not break pawn's inventory chain.