SVN Revision 1926

[DOLBot]

Commit from dunnerholl

Log Messages
Added : Constant to be used for Autoaggrovalues for mobs, default -1 in aggrorange

Files Changed:
MODIFY - DOLSharp/trunk/GameServer/GlobalConstants.cs
MODIFY - DOLSharp/trunk/GameServer/gameobjects/GameNPC.cs

View Changes:
http://dolserver.svn.sourceforge.net/do ... v&rev=1926

[Dunnerholl]

wanted to say constant to be used for autovalues as its name indicates (and cause we planned to use it for multiple things)

[Tolakram]

Can you make the check insist on both aggrorange AND aggroamount be == -1?

[Dunnerholl]

Can you make the check insist on both aggrorange AND aggroamount be == -1?

i was thinking about this, but its kinda same stupid as checking for just one.

because what indicates an aggrolevel of 100 and aggrorange of -1 ?

and what would be if aggrorange is 10000 and aggrolevel -1 ?

we would have to split that logic up to set range dynamically on -1 and level dynamically on -1. should i?

[Tolakram]

Well.

Shouldn't it be level instead of range then? Seems to me the amount of aggression is more suggestive than the range of agression.

/shrug; 6 of one, half dozen of the other.

Storm DB updated.

Code: Select all

update mob set aggrorange = -1 where aggrorange = 0;

[Dunnerholl]

most interesting for me during the last update :

Code: Select all

/// <summary>
/// Aggressive Level in % 0..100, 0 means not Aggressive
/// </summary>
int AggroLevel { get; set; }

hahaha

[Kakuri]

Is adding a new class named Constants really a good approach for this?

And should it be a constant in the code, or does it make any sense to make it (shudder) another server property?

[Graveen]

i vote SP, yup

[Dunnerholl]

in my opinion server properties are overused. its a total chaos to manage. and this constant is totally code related, you would not want to change it on the fly or during server uptime.

[Kakuri]

If it ought to be user-configurable at all, I think a server property is the way to go (even if it shouldn't be changed while the server's running).

If it need not be user-configurable, then why not just define it as a constant in GlobalConstants.cs? What's the need for the new class Constants?

[Graveen]

ServerProperties are similar to an xml or an ini file. The DoL choice is to gather configurables items in SP, and typically, the default aggro range worths to be in

[Tolakram]

If it ought to be user-configurable at all, I think a server property is the way to go (even if it shouldn't be changed while the server's running).

If it need not be user-configurable, then why not just define it as a constant in GlobalConstants.cs? What's the need for the new class Constants?

This is doable, just make the server property readonly (I think) ... the way almost all of them used to be before I changed them so I could update settings on the fly.

[Dunnerholl]

ServerProperties are similar to an xml or an ini file. The DoL choice is to gather configurables items in SP, and typically, the default aggro range worths to be in

this is NOT the default aggrorange it is the value used to trigger autoconfigure. nothing that needs to be customized

[Dunnerholl]

If it ought to be user-configurable at all, I think a server property is the way to go (even if it shouldn't be changed while the server's running).

If it need not be user-configurable, then why not just define it as a constant in GlobalConstants.cs? What's the need for the new class Constants?

show me how

[Graveen]

ServerProperties are similar to an xml or an ini file. The DoL choice is to gather configurables items in SP, and typically, the default aggro range worths to be in

this is NOT the default aggrorange it is the value used to trigger autoconfigure. nothing that needs to be customized

effectively.