[Logo]
 
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
PreventDeath/ModifyPawn order: solution suggestions?  XML
Forum Index -> Druids RPG Development Go to Page: 1, 2 Next 
Author Message
BotFodder

Wicked Sick!
[Avatar]

Joined: 01/13/2006 15:23:41
Messages: 1239
Location: Florida
Offline

See for references:

http://disastrousconsequences.com/dcforum/posts/list/2324.page#20025

http://disastrousconsequences.com/dcforum/posts/list/2338.page

for other threads referencing this issue.

This deals with Abilities that have either ModifyPawn (MP) or PreventDeath (PD) in them.

I can be 100% sure about ModifyPawn (as I haven't reviewed how exactly it's called), but I *am* 100% sure about PreventDeath. There can be several gotchas depending on what order the skills in question were purchased, and in what order they're called. What order the functions within Abilities are called can have certain unforeseen impacts if the coder is not aware of the potential for "conflict". It's most problematic (and easiest to explain) with PD: If some Ability looks at bAlreadyPrevented and, if it is False, assumes that the player *will* die, but then Ghost (or some other Ability that might actually prevent death) is triggered afterwards in the sequence, this can have unfortunate (and undesired) consequences.

The question I'm placing to you is: How would you fix it? Here's the "obvious" solutions:

1. Manually redo the order of all players' skills in the UT2004RPG.ini - tedious, and for large playerbases, unfeasable.

2. Code all skills that need things to run in particular order to check, and if needed, make calls to the Ability's PD or MP. Problematic because if a new Ability is developed, all objects that need to ensure proper running will have to be retouched. Also ignores what folks who might extend Dru's code could be doing further down the line ...

I have another idea but I'm holding off making a public suggestion of it because it too has it's issues (and makes my head hurt thinking about how to go about implementing it), and I'd like to hear if there are other suggestions out there.

I use the Futurama Prof. Farnsworth Skin: http://www.disastrousconsequences.com/dcforum/posts/list/1595.page
WM: (DC)BotFodder 170
MM: (DC)BotDoctor 141
AM: (DC)BotBooster 147
http://ericdives.com/ - My DC Newbie FAQ: http://tinyurl.com/lz229
Twitter: http://twitter.com/ericdives
[WWW] aim icon [MSN]
Szlat

Wicked Sick!

Joined: 05/18/2005 18:32:41
Messages: 2124
Location: UK
Offline

A tricky one.

I am not convinced about explicitly testing for the presence of other abilities within the PreventDeath code. It limits how other people can add other mods, and how people can extend the functionality without re-coding.

Forcing the order could work - you would need to ensure that they exist in the StatsInv in the same order that they occur in the RPG.ini. This could perhaps be done when the player abilities get read in and added, which would avoid changing the file with all the player's skills in. So it will require changes to RPGStatsInv and probably the Mutator, so a bit heavy-handed. It would then allow server admins to get all the abilities in the correct order. However, they would probably have to look at the code for each ability to see what the correct order is - assuming there is one.

Taking a step backwards to look at the problem, here's my thoughts:

PreventDeath is a function that is called to see if any of the Player's abilities will stop him Dying. Ghost is a primary example of this.

The problem is people put all sorts of other features into PreventDeath, because it is a convenient place to handle dying code. In reality, only abilities that can return true to PreventDeath ought to use it.

So, Ghost will still be ok - that does stop people dying. But how should we kick off the other abilites?

What we could do with is the single PreventDeath call being replaced by three calls, in order:
  • PlayerCouldDie - Players health gone below zero
  • PreventDeath - as now
  • PlayerHasDied - PreventDeath failed
    This would give us a lot more flexibility.
    Ultima could use PlayerCouldDie or PlayerHasDied, depending on what you wanted.
    Ghost would use PreventDeath.
    NoWeaponDrop, and perhaps the pinata fix, would use the PlayerHasDied.

    The calling sequence seems to be:
    Pawn.Died calls GameInfo.PreventDeath, which calls PreventDeath for the first of the GameRules currently running.
    RPGRules.PreventDeath first calls super.PreventDeath (which iterates through the rest of the gamerules.PreventDeaths) to see if any of those can prevent the death. Then it checks the abilities in StatsInv to see if those can prevent death. If not, it starts tidying up.

    Now ideally we would add the two extra functions into RPGAbility, and call them from within RPGRules.PreventDeath - but that involves changing Mysterial code so we can't do it.

    Instead, what may be feasible is to create a new class called RPGDeathAbility extending RPGAbility, and add the two new functions in that class. Then all of our abilities we want these checks on can be extensions of RPGDeathAbility, rather than RPGAbility.
    The difficult bit is getting those functions called. What we would have to do is create 2 special abilities to sit as first and last in everyones list of abilities.
    The First ability would have a PreventDeath function that iterated through all the abilities that were of type RPGDeathAbility and call the PlayerCouldDie function.
    The Last ability would have a PreventDeath function that if bAlreadyPrevented was not true, would iterate through all the abilities that were of type RPGDeathAbility and call the PlayerHasDied function.

    A bit complex, but might work if we can fix the first and last abilties.

    As an aside, we could also add code in there to call a PreventDeath on the current weapon, so you could have weapons of type Resurrection.
  • BotFodder

    Wicked Sick!
    [Avatar]

    Joined: 01/13/2006 15:23:41
    Messages: 1239
    Location: Florida
    Offline

    Okay - so you've touched upon my other solution - automating the ordering of the Abilities array. The thing I suggested to Dru (and he's still thinking about it, apparently) is to set the order when skills are purchased (though setting the order when they're read in is also a good idea).

    If you look at the UT2004RPG.ini that Druid provides with his mod, you'll find the first stanza is the UT2004RPG.MutUT2004RPG stanza. In that stanza, there's an array of Abilities built. If we set up that array so that the abilities are in the preferred order, that would help the situation. IOW, since the "Class" classes don't have PD (and probably shouldn't), then you'd set the order (so that both PD and MP calls are done in the preferred order) as so (using the abilities that I know might have issues either now or in the future):

    Ultima (just thought of this one right now - this way you can just have a standard PD in Ultima and not need any extra code in Ghost, bAP stays false)
    Ghost (bAP becomes true)
    Loaded Weapons (for MP - set up a WM's weapons)

    ... and near the bottom:

    Loaded Artifacts (to stop art droppage in PD)
    Denial (both for PD and MP; keep weapons on death and then replace weapons on spawn - destroying any LW set weapons if necessary? hmmmm, need to play with this)

    So when an ability is purchased (or the player's stats are read in), the player's abilities array is reordered to match the MutUT2004RPG Abilities array order.

    But you've also hit on the other issues - the code to do this could get messy quickly, would probably be better if it were in the UT2004RPG core code, and I don't necessarily feel comfortable with messing with a key array (player.Abilities) like that.

    Other than that, there's a bit more for me to digest in Szlat's message, so let me get back to it ...

    I use the Futurama Prof. Farnsworth Skin: http://www.disastrousconsequences.com/dcforum/posts/list/1595.page
    WM: (DC)BotFodder 170
    MM: (DC)BotDoctor 141
    AM: (DC)BotBooster 147
    http://ericdives.com/ - My DC Newbie FAQ: http://tinyurl.com/lz229
    Twitter: http://twitter.com/ericdives
    [WWW] aim icon [MSN]
    Szlat

    Wicked Sick!

    Joined: 05/18/2005 18:32:41
    Messages: 2124
    Location: UK
    Offline

    Szlat wrote:
    .....The difficult bit is getting those functions called. What we would have to do is create 2 special abilities to sit as first and last in everyones list of abilities.
    The First ability would have a PreventDeath function that iterated through all the abilities that were of type RPGDeathAbility and call the PlayerCouldDie function.
    The Last ability would have a PreventDeath function that if bAlreadyPrevented was not true, would iterate through all the abilities that were of type RPGDeathAbility and call the PlayerHasDied function.

    A bit complex, but might work if we can fix the first and last abilties. 

    As an alternative, since the RPGRules.PreventDeath calls the PreventDeath of other GameRules before doing it's stuff, if we could add another GameRules with just a PreventDeath function, which could
  • Perform the calls to the PlayerCouldDie function for the abilities, so we wouldn't need a "First" ability
  • Add the "Last" ability to the end of the abilities list.
    The "Last" ability would then call the PlayerHasDied functions, then remove itself.

    Should be a bit simpler than ordering the abilities.
  • BotFodder

    Wicked Sick!
    [Avatar]

    Joined: 01/13/2006 15:23:41
    Messages: 1239
    Location: Florida
    Offline

    I think I'm starting to get a handle on how one might go about sorting the order of the Abilities, but before I start playing with this, a few thoughts ...

    I don't want to put time into this if (assuming success) it isn't going to be considered useful. I'd much rather start working on the other workaround methods if we're going to use them instead ... because once it is determined how the problem will be handled, then I can solve "real" problems like pinata.

    Mysterial poo pooed the idea, voicing the opinion that you'd eventually run into some kind of circular dependency between skills anyway. As I've said previously, I don't know if I buy into that. Even if I did, I'd say you can solve a lot of your issues up front. Any circular dependencies that come up you can now handle in a predicatable way.

    As for the ordering thing, it's really just a couple of classes that would have to "added" to from the core code (pretty much just one function rewritten in each). I could probably do it in its own mod easily - making calls to super.whatever when needed (pretty much right at the start, really). The kicker is that as far as I can tell, it's two separate arrays - one for the server, and one that is originally built off of that one but is occasionally manipulated separately and is replicated to the client.

    So I guess what I'm wondering about is where Dru's brain is at on this issue. "Still rhuminating" is a valid response of course.

    I use the Futurama Prof. Farnsworth Skin: http://www.disastrousconsequences.com/dcforum/posts/list/1595.page
    WM: (DC)BotFodder 170
    MM: (DC)BotDoctor 141
    AM: (DC)BotBooster 147
    http://ericdives.com/ - My DC Newbie FAQ: http://tinyurl.com/lz229
    Twitter: http://twitter.com/ericdives
    [WWW] aim icon [MSN]
    BotFodder

    Wicked Sick!
    [Avatar]

    Joined: 01/13/2006 15:23:41
    Messages: 1239
    Location: Florida
    Offline

    Szlat wrote:
    Should be a bit simpler than ordering the abilities. 

    I dunno ... adding two extra functions that could end up being used to do the same exact thing as "PreventDeath" seems a little like overkill to me.

    From what I've seen, it shouldn't be that hard to manipulate the arrays. Extend the classes in question, call super.(function that read in the player stats or responded to a player buying a stat), and then sort the arrays as desired.

    The list of available Abilities is going to be included in the ini no matter what, really, so there shouldn't be a big deal with defining it's order in there and then using that to sort a player's abilities.

    Just make sure you've backed up your INI before subjecting this to live use.

    I might actually just go ahead and code it up over the weekend and give it a whirl on my test box, as this being in any kind of limbo is really holding up some things I'd like to work on.

    I use the Futurama Prof. Farnsworth Skin: http://www.disastrousconsequences.com/dcforum/posts/list/1595.page
    WM: (DC)BotFodder 170
    MM: (DC)BotDoctor 141
    AM: (DC)BotBooster 147
    http://ericdives.com/ - My DC Newbie FAQ: http://tinyurl.com/lz229
    Twitter: http://twitter.com/ericdives
    [WWW] aim icon [MSN]
    Szlat

    Wicked Sick!

    Joined: 05/18/2005 18:32:41
    Messages: 2124
    Location: UK
    Offline

    BotFodder wrote:

    I dunno ... adding two extra functions that could end up being used to do the same exact thing as "PreventDeath" seems a little like overkill to me.
     
    But it wouldn't do the same thing as ordering the abilities.

    The reason you need to order the abilities is that PreventDeath is being used for more than preventing death. There is only Ghost that does that. It is because we are sticking things like Denial and pinata on there as well that we start to get a conflict.

    Still, ordering them should work.

    The time when ordering might give a problem is when on another server some admin adds extra abilities for a different mod, and puts them in the wrong order. Short of going into the code and working out exactly what each class is doing it might be difficult for him to know what order to put them in.

    Having said that, with the ordering at least he can sort it out. With my suggestion, he would have to recode them so the guts of the code was on a PlayerHasDied rather than the PreventDeath function.

    So, ordering may be a simpler approach for admins to understand.

    Another thought: the only one that is giving us problems is Ghost. Provided that goes first, everything else is ok (I think?) Why not automatically give everyone Ghost level zero, so everyone always has it before any purchased abilities? Level zero obviously will not do anything, but will just be a placeholder.
    BotFodder

    Wicked Sick!
    [Avatar]

    Joined: 01/13/2006 15:23:41
    Messages: 1239
    Location: Florida
    Offline

    Well there might develop some very minor issues with "ModifyPawn" too (mainly LW and Denial, but since we're talking only Denial 2, it's not a huge deal).

    But yeah, giving newbies the skill Ghost with level 0 right off the bat might work.

    I use the Futurama Prof. Farnsworth Skin: http://www.disastrousconsequences.com/dcforum/posts/list/1595.page
    WM: (DC)BotFodder 170
    MM: (DC)BotDoctor 141
    AM: (DC)BotBooster 147
    http://ericdives.com/ - My DC Newbie FAQ: http://tinyurl.com/lz229
    Twitter: http://twitter.com/ericdives
    [WWW] aim icon [MSN]
    Szlat

    Wicked Sick!

    Joined: 05/18/2005 18:32:41
    Messages: 2124
    Location: UK
    Offline

    BotFodder wrote:
    Well there might develop some very minor issues with "ModifyPawn" too (mainly LW and Denial, but since we're talking only Denial 2, it's not a huge deal). 
    I hadn't realised there was a problem with the ordering for ModifyPawn as well.
    Does this mean theoretically PreventDeath might want one order and ModifyPawn another?
    BotFodder

    Wicked Sick!
    [Avatar]

    Joined: 01/13/2006 15:23:41
    Messages: 1239
    Location: Florida
    Offline

    Theoretically yes, and that may be the circular dependency issue Mysterial was hinting at. However, I think the likelihood is rare, and that to a large extent you can avoid issues by using the same order. And if it *does* become an issue, then you just code that one exception instead of a bunch to deal with order issues off the bat.

    I use the Futurama Prof. Farnsworth Skin: http://www.disastrousconsequences.com/dcforum/posts/list/1595.page
    WM: (DC)BotFodder 170
    MM: (DC)BotDoctor 141
    AM: (DC)BotBooster 147
    http://ericdives.com/ - My DC Newbie FAQ: http://tinyurl.com/lz229
    Twitter: http://twitter.com/ericdives
    [WWW] aim icon [MSN]
    TheDruidXpawX

    Wicked Sick!
    [Avatar]

    Joined: 12/19/2004 18:32:13
    Messages: 1946
    Offline

    I've got a bit of an easier idea.

    If we added a GameRules that also handled death, but inserted itself in front of UT2004RPG on the first tick, we could process the prevent death method beefore UT2004RPG does.

    From there, we could add a set of new methods to the DruidGhost, DruidUltima, DruidNoWeaponDrop, etc... that are for PrePreventDeath() ActualPreventDeath() and PostPreventDeath() (Overriding the current PreventDeath() method to do nothing at all)

    Then we first make those calls. then we allow UT2004RPG to do it's thing next if PreventDeath is false.

    Thoughts?


    Skin download: http://www.disastrousconsequences.com/dcforum/posts/list/1189.page

    The fundamental problem is this: The first word we learn as children is NO. From that point forward society teaches women that saying no isn't polite, and society teaches men to respect those who wont take no for an answer.

    The world is what you make of it, my friend. If it doesn't fit, you make alterations. -- Stella, The Morning Star
    BotFodder

    Wicked Sick!
    [Avatar]

    Joined: 01/13/2006 15:23:41
    Messages: 1239
    Location: Florida
    Offline

    I think that's basically what Szlat suggested, but perhaps with a more easily handled alternative. I know when my ideas have been voted down (2-1 here no biggie).

    My thoughts (mainly guesses) are:

    PrePreventDeath I don't know where it would so much apply yet, but could be greatly useable in the future - someone died, it doesn't matter if they do or don't, we do something no matter what - perhaps trigger Ultima? ActualPreventDeath would be like "DruidPreventDeath" - basically PD, but named differently to differentiate it from any PD that UT2004RPG would call, and where Ghost would act. PostPreventDeath would only run if nothing in APD returned true, and would be the place for Denial and Pinata fix code. Then we'd allow any skills in the UT2004RPG core that we're using (that don't have Druid versions, basically) to run their PD - coding Druid alternatives if we discover/use something that conflicts with our setup.

    The only issue I might have with this is that it triggers three more loops when someone dies. I don't like having too many loops. Maybe I'm just old and remember when you'd actually notice large loops running in code. But if we set up APD's loop to stop running when any ability returns true, then that's cool, and we could avoid the third loop too. And since it's not like *every* ability would have it, it's not a "long" loop.

    Well, maybe this will grow on me ...

    My only other suggestion is to put a prerequisite on Denial that it require LW for WMs. Not that any WM would skip his main skill right off the bat for Denial, but ya know ...

    I use the Futurama Prof. Farnsworth Skin: http://www.disastrousconsequences.com/dcforum/posts/list/1595.page
    WM: (DC)BotFodder 170
    MM: (DC)BotDoctor 141
    AM: (DC)BotBooster 147
    http://ericdives.com/ - My DC Newbie FAQ: http://tinyurl.com/lz229
    Twitter: http://twitter.com/ericdives
    [WWW] aim icon [MSN]
    Szlat

    Wicked Sick!

    Joined: 05/18/2005 18:32:41
    Messages: 2124
    Location: UK
    Offline

    TheDruidXpawX wrote:
    From there, we could add a set of new methods to the DruidGhost, DruidUltima, DruidNoWeaponDrop, etc... that are for PrePreventDeath() ActualPreventDeath() and PostPreventDeath() (Overriding the current PreventDeath() method to do nothing at all)

    Then we first make those calls. then we allow UT2004RPG to do it's thing next if PreventDeath is false. 
    We would probably need a class called DruidsRPGArtifact, extending RPGArtifact, that had support for the 3 functions in it. DruidGhost etc would need to be based on that class.

    Then, the new GameRules loop could have 3 loops
  • call the PrePreventDeath function for all DruidsRPGArtifacts
  • call the ActualPreventDeath function for all DruidsRPGArtifacts, and the PreventDeath function for all non-DruidsRPGArtifacts
  • call the PostPreventDeath function for all DruidsRPGArtifacts

    But we would then need to disable the loop in the RPGRules PreventDeath function?
    Or are you suggesting copying the code into the new GameRules PreventDeath function and making sure the RPGRules PreventDeath never runs?
  • BotFodder

    Wicked Sick!
    [Avatar]

    Joined: 01/13/2006 15:23:41
    Messages: 1239
    Location: Florida
    Offline

    Szlat wrote:
    We would probably need a class called DruidsRPGArtifact, 

    This idea did briefly occur to me while I was working on the original Pinata fixes; if we had a "bTossOnDeath" boolean we could set, and rewrite the DruidsRPGArtifact to have the proper DropFrom to check it, we'd be good to go - but then we're back to rewriting certain artifacts we borrow unchanged from Mysterial's RPG core ...

    However, it's just occurred to me that you're confusing your artifacts and your abilities. PreventDeath is only in abilities, not artifacts.

    However, if we put it in artifacts, we could make a "Ghost" artifact ... hmmm ...

    Anyway, back to topic: we wouldn't need a new Artifact. But we might need a DruidRPGAbility master class ...

    The thing is, wouldn't we run into issues if we didn't rerwrite all the UT2004RPG abilities we borrow if we tried to call ActualPreventDeath in them? I haven't dug through the code to verify this, but I would say there'd need to be at least a dummy of the three PD functions in them, right?

    I use the Futurama Prof. Farnsworth Skin: http://www.disastrousconsequences.com/dcforum/posts/list/1595.page
    WM: (DC)BotFodder 170
    MM: (DC)BotDoctor 141
    AM: (DC)BotBooster 147
    http://ericdives.com/ - My DC Newbie FAQ: http://tinyurl.com/lz229
    Twitter: http://twitter.com/ericdives
    [WWW] aim icon [MSN]
    Szlat

    Wicked Sick!

    Joined: 05/18/2005 18:32:41
    Messages: 2124
    Location: UK
    Offline

    BotFodder wrote:

    Szlat wrote:
    We would probably need a class called DruidsRPGArtifact, 

    ... it's just occurred to me that you're confusing your artifacts and your abilities. PreventDeath is only in abilities, not artifacts.

    ...

    Anyway, back to topic: we wouldn't need a new Artifact. But we might need a DruidRPGAbility master class ...

    The thing is, wouldn't we run into issues if we didn't rerwrite all the UT2004RPG abilities we borrow if we tried to call ActualPreventDeath in them? I haven't dug through the code to verify this, but I would say there'd need to be at least a dummy of the three PD functions in them, right? 

    You are correct - I should have said DruidRPGAbility rather than DruidRPGArtifact. (see my earlier post - I called it a RPGDeathAbility then) ops:

    The DruidRPGAbility class would have 3 dummy functions, which we would override as necessary. We would only need to rewrite and subclass the abilities that we want to use the 3 functions on. Other abilities could stop as they are.
    And if the ability is not of type DruidRPGAbility, we could call PreventDeath in it, rather than ActualPreventDeath to maintain backwards compatibility.
     
    Forum Index -> Druids RPG Development Go to Page: 1, 2 Next 
    Go to: