Moving IsAllowedToAttack from ServerRules to GameLiving?

[geshi]

Hey all

I was thinking about removing the IsAllowedToAttack method from ServerRules and adding it to GameLiving to allow for much more customisation.

Has anyone got any thoughts on this? it may cause a few headaches for some server owners in the short term but in the long term it will be a very nice thing to have..

[Graveen]

This is done through ClassType.

When you define a GameNPC, the brain is a characteristic of this GameNPC, similar to the model used. If you need more NPCs with different brains, you can create as classtype as necessary (and if you look as specific non-smb users, they are always in different classes).

[geshi]

Yep sure that can be used for mobs (even though it is quite hackish).. but for players it's not possible :/

[Graveen]

Players ? You are the brain of the player !

[IStandAloneToo]

I was thinking about removing the IsAllowedToAttack method from ServerRules and adding it to GameLiving to allow for much more customisation.

The problem is that this would go backwards in the customization as servers would need to edit the DoL core to modify the rule. Obviously, creating custom server rules is a great advantage for customization. Why would you need this method on a GameLiving? I don't see what can't be accomplished.

[geshi]

Things like Mentalist RR5 and Phaseshift can be moved to the GamePlayer IsAllowedToAttack method and return false if the target has either of those effects up... instead of them being in their own respective scripts like they are at the moment.

And say I wanted a monster which can only attack players when it's below 50% hp for example, if IsAllowedToAttack was in GameLiving I could just override it in the custom monster script and add that really easily instead of modifying the large method in IsAllowedToAttack in the serverrules. Sure it's possible by creating my own custom server rules but if the method was in GameLiving instead it would be quite a bit easier.

Plus if I wanted to say release that boss script to a friend for example, I'd be able to do it really easily, just send him the file. If the current system is kept then I'd have to modify the server rules and send him those, and his might be different from mine so he won't be able to have my boss mob.

[IStandAloneToo]

I see your point and it is valid. Unfortunately, we're trading conveniences here. Generally it is easy to edit ServerRules::IsAllowedToAttack rather than edit a custom GameLiving. I don't think the optimizing for a few corner cases would be wise.

Also, I prefer to have the checks in their respective scripts. Cluttering something like IsAllowedToAttack with checks for a bunch of different spells and cases would be exceptionally messy. Take the global SpellHandler::FinishSpellCast for instance. It is riddled with Warlock and Animist special cases. That's not the only place in that file where there are custom checks in global spell handling. This should really be avoided. Making this change would cause a similar effect. In general, segregating checks to specific handling code is best practice.

Subsequently, we always need to provide backwards compatibility to our public API:

Has anyone got any thoughts on this? it may cause a few headaches for some server owners in the short term but in the long term it will be a very nice thing to have..

The headache here would be large. A server shouldn't get compiler errors from a change made to the server rules. This is why Win32 calls keep getting postfixes: CreateWindow -> CreateWindowEx because they need to keep CreateWindow the same call as before.

[Tolakram]

Perhaps what geshi means is that GameLiving contains IsAllowedToAttack and the default implementation is to call ServerRules IATA? This might be workable, Geshi would still need to provide custom handling in his own classes.

I've done some of these kinds of mods ... making GamePlayer responsible for answering questions about players, then having the default implementation provide the old answer. My D2 gameplayer class then has the means to customize this.

In this case, for this to work, gamleliving... or maybe gameobject... would need isallowedtoattack with the default implementation being a call to server rules.

This would require a crap ton of code changes though. An easier way for geshi, would be for serverrules to continue to handle the question, check to see if the player or living is a custom class, then call back to that class to handle it. Easy implementation, no core changes.

[geshi]

Well IsAllowedToAttack in AbstractServerRules would be changed to simply

Code: Select all

return attacker.IsAllowedToAttack(defender, quiet);

It really wouldn't be difficult to copy and paste the current code in IsAllowedToAttack from the current Server Rules to the respective classes that it should be in.. so it wouldn't cause a headache for anyone who uses the default rules..

For people who use custom rules, sure it would take some time to move the respective code to the classes it would be in but it would be more than worth it in the end.

And yeah at the moment I just ignore everything in IsAllowedToAttack for my special monster and handle it in the special monster class.. but it would just be nice if this was done for everything by default..

Edit: I forgot to mention, if it was done the way I just mentioned then server owners with custom rules won't have to worry about changing anything if they don't want to win win situation I think anyway... doesn't harm anyone..

[Graveen]

ServerRules is good for all generic behaviours.

Class rules are interesting for class handling (thank you, Captain obvious !)... But... this is something in the brain area.

I'd more see IsAllowedToAttack in the brain scope:
- calling the specific ServerRules (player, mob, realm interactions)
- calling its own IsAllowedToAttack (or vice-versa, you define it in fact. For SMB, nothing, for PetBrain, a bit more checks, for necropetbrain, a tons /wave Tola )

There are some confusions in general related to the scope of the brain vs the scope of a gameliving inherited class. This is perhaps something we would want to left as is, or eventually discuss.

And we also miss a "team logic" handling: i don't remember how Ryan handled BoneDancer's pet formations (Ryan, if you hear us..), and this is potentially an area where improvement are needed. Darwin mocked up this successfully (for formations) but the "team logic" i think about is wider.