Hi everyone.

I'm trying to check in CombatTimer in Mobile.cs if a mobile is .Controlled or .Summoned and I'm wondering what's the "best" way to do it.

From what I found I can create abstract "Controlled" and "Summoned" properties and override them in BaseCreature (and anywhere else...) or make the whole CombatTimer virtual and override it only in BaseCreature. I'd really appreciate any coments from someone more experienced on a better approach, programming-wise, because I'm stuck.

Also, I'm probably being really daft here, but why can't I use any of the classes declared in /Scripts (e.g. BaseCreature) in Core files like I can use in all of the other scirpts?
 
Well, a PlayerMobile, a Wanderer, a TownCrier, etc. can't be controlled nor summoned.
If you need to make checks in the superclass, you have to review your approach indeed, as what you suggest would impact on all the subclasses.
Also, keep in mind that the core is built separatly from the scripts, the ScriptCompiler.cs manages the script compiling from what i remember, so it,s better ot putting everything in the same basket :p

Also, what are you trying to change in the combat timer exactly?
 
Hi everyone.

I'm trying to check in CombatTimer in Mobile.cs if a mobile is .Controlled or .Summoned and I'm wondering what's the "best" way to do it.

From what I found I can create abstract "Controlled" and "Summoned" properties and override them in BaseCreature (and anywhere else...) or make the whole CombatTimer virtual and override it only in BaseCreature. I'd really appreciate any coments from someone more experienced on a better approach, programming-wise, because I'm stuck.

Also, I'm probably being really daft here, but why can't I use any of the classes declared in /Scripts (e.g. BaseCreature) in Core files like I can use in all of the other scirpts?

Can you share what you've done to make the CombatTimer virtual? It's impossible to know where you are going wrong without knowing what you've done. Making Controlled/Summoned abstract doesn't make sense though, as abstract means that the properties need to be implemented in all subclasses, but as Pooka said, there's no reason to implement them in PlayerMobile. Making them virtual would make more sense, but if you are overriding the combat timer then you shouldn't need to access them from the core anyway, since the combat timer will be handled in Scripts.
 
Last edited:
Thanks for responses!

I was trying to avoid Abstract for that reason, it's a lot of changes to original scripts. If I do it Virtual, then only BaseCreature.cs would use it's own CombatTimer, rest could use the base from Mobile.cs? Still, that's a change in the core + a change in BaseCreature, and I'm trying to keep all the changes to minimum so I can update ServUO with as little hassle as possible.

I haven't done anything yet, I just wonder if someone with more C# experience could give a tip on the approach. I want to add a random chance to change target in combat, but only for mobiles that are not players, not summoned and not controlled.

I'll have to check, maybe I can add a custom utility function like, e.g. "CanChangeCombatTarget(Mobile who)" in which I cast "who" to BaseCreature, null-check, then check Summoned and Controlled and use that function in CombatTimer in Mobile.cs
 
I haven't done anything yet, I just wonder if someone with more C# experience could give a tip on the approach. I want to add a random chance to change target in combat, but only for mobiles that are not players, not summoned and not controlled.

You could do this in OnActionCombat() in BaseCreature, you wouldn't need to use the combat timer. The combat timer is specifically for checking whether or not someone should take a swing. This sounds more like an overall AI change though, so might be better suited putting it in monster AI.
 
Yep, i even think some AI purposely change their targets once in a while, i'm not sure if it was champions or Predator AI but i recall seeing that behavior before.
 
I was experimenting with AI and test messages earlier, but couldn't find anything that did a check before each swing - that's where I wanted a target change, so the mob would be ready to hit another target straight away.

Thanks for the OnActionCombat(), Jack! I'll have a look at that.
Thanks, po0ka. True! I think I recall champions changing targets, too.
 
Personally, I'd just create a new virtual method on Mobile.cs:
Code:
protected virtual void OnCombatTimerTick( )
{

}

Then take the CombatTimer.OnTick() method body and move it to the new OnCombatTimerTick()
You'll need to refactor 'm_Mobile' to 'this' to make it compile.
When you've done that, simply replace the CombatTimer.OnTick() method body with this:

Code:
protected override void OnTick()
{
   m_Mobile.OnCombatTimerTick( );
}

Then you're free to override OnCombatTimerTick( ) in BaseCreature, to implement any logic you want.
You can omit the override's base.OnCombatTimerTick( ) call to negate the default logic.


The reason you cannot access Scripts classes from the Core is because of dependencies.
The Core and Scripts are two separate libraries (they both compile to separate DLL files)
One can depend on the other, but it's never a two-way relationship as this causes circular dependency issues.
The reason RunUO was designed this way was to protect the (then) closed-source EXE from being modified, while still allowing shard owners to expand their code-base with customisation by editing Scripts.
If RunUO were written today, it's likely it would all be one self-contained, compiled EXE without the need to compile Scripts at run-time.
 
Huge thanks, Voxpire! That's exactly what I had in mind, just wasn't sure how to get about it :)

Huge thanks, guys, I was testing it on a GM char before I posted and was wondering why I couldn't see any debug messages or anything... ;) Just tested on a player char and OnActionCombat() works like a charm - seems like the least intrusive and most precise way to go
 
You could do this in OnActionCombat() in BaseCreature
Just a quick follow-up - works like a charm, thanks :) It does change the behaviour od all mobiles, but it's easier to add a check for weaker ones (birds, dogs, cats, etc.) than editing every hostile, stronger mobile
 
Back