Proposed DFN Changes

[Grimson]

I realise it's all a trade off. And honestly, I do have to wonder anyway if some of this can't be done via JS anyway, given how infrequent would be. I think we need to (and we would be you and giwo, given primary coders, plus at least some users/shard ops) sit down and really evaluate where the combat system is at, what we need to get out of it, how feasible some of it is, and how much of the loop we want to shunt out to the JS engine. Rather than quick (but effective) fixes, sort of take a more holistic approach. And I do realise not everyone has a huge amount of time either.

We could slim down combat.cpp. Leaving only the functions that do more intense calculations inside, like damage, armor and resistance, expose them to JS. Then do the rest in JS using events in a global script. But I'm not shure how big the speed impact would be.

[Maarc]

That's the kicker, isn't it? The speed could be a problem. I think we need to invest a little time in testing, and see if we can't come up with some mini-driver test benches, or a test benchmark (so a false client that sends pre-scripted commands), so we can try and evaluate performance bottlenecks. I think the development of a combat simulator, using our code, would be a handy thing.

But even there, with what you suggested ... some people might want to use different damage and armour calculations. Say someone wants to make a D&D style shard, they might want to use dice rolls and everything, and they'll want to be able to edit that sort of stuff.

It's not an easy thing, and it is difficult to come to some sort of compromise, on flexibility, speed, and burden on the shard ops.

[Grimson]

But even there, with what you suggested ... some people might want to use different damage and armour calculations. Say someone wants to make a D&D style shard, they might want to use dice rolls and everything, and they'll want to be able to edit that sort of stuff.

Please read my post here: viewtopic.php?p=5655#5655 with this changes you could customize most of the calculations while still doing everything else in code. We just need to split up the calculations and expose them individually to JS. So a user can choose which parts of combat/magic he wants to do in JS and which should be handled by UOX3.

Edit:
To say it simple, I want to split up combat and damage handling into smaller specialized functions that can be called via JS. Then do combat by default in the source code, like we do now, with the change that we call those functions instead of doing most of it in one big function. But allow the user to override that using a JS event like onSwing(). In this JS event he can call all the source functions he is happy with and only change the part he wants to be different.

[Grimson]

Btw. while we are at changing the handling of configuartion files, could we also use the DFN logic to read in the ini file?

[Maarc]

That'd definitely be a good idea. The ToolAPI can already parse an INI file, and in my testing so far, it's just another Script/ScriptSection combo, as it uses the same tag/data pairing and section setup.

[punt]

Perhaps the DFN could be extended to be self defining.

right now , one must understand the context of the directory structure to understand "what" the dfn is defining. It is not stand alone out of that context. Manipulation of the data, outside the final directory structure, requires additional hints in some fashion. This can be problematice for tools, or shards that want to organize their "work" (not final deployment) in different structures.

[Maarc]

There wouldn't need to be many elements changed to make it self-defining, of sorts. Just sifting through the schemas so far, more types than not tend to be self-describing. The ones that are, at the moment, are:

* Carve
* Colors
* Command (barring a subset)
* Creatures
* House
* HTML
* Location
* Maps
* Misc
* Messageboard
* Newbie
* Race
* REgions
* Skills (barring a subset)
* Spawn
* Spells
* Titles
* Weather

The ones that are missing schemas:

* Items
* Harditems
* Advance
* Create
* Menus

The ones that are partially complete:

* Commands - need to provide a basic descriptor for individual command level descriptions
* Skills - ore schemas need to be better self-defined
* NPCs - all barring actual NPC entries are self-defining
* Items - can't tell, but I'm guessing most are self-defining bar the items themselves

So as it stands, the bulk of the different section types are already self-defining, in that you can find the category it belongs to purely from the header. It's only those few instances (which is bulk of the data, but still, few instances of different types) where you can't figure it out.

[punt]

Correct. And I was hoping the DFN could be extended to self define for ALL of them, and more importnatly, in a consistent manner (does no good to have know what dfn one is in, to be able to determine how to determine the type!). So one doesn't have to have a loction to determine what type of data is being described.