Proposed DFN Changes

[giwo]

There are a few things that have been tossed about here on the forums and in the #uox3 chatroom for a while. I wanted to consolidate these ideas into a single cohesive plan and then eventually put it into motion.

First of all, A section delimiter. I am quite happy with our TAG=DATA format, however once we get to the DATA, the information can be split by spaces ( ) in some scenarios, and commas (,) in other scenarios. Notably neither of these delimiters would work in a line of text, as a comma and a space are both regularly used expressions. Thus we need to decide on a relatively rare section delimiter for the DATA value. My thought, is the semicolon (;) however that symbol can be infrequently used in a line of text, so perhaps it isn't the best choice.

Secondly, TAG=DATA pairs. While I would guess at 99% of the DFN's obeying the TAG=DATA rule, there are a specific few (I'm thinking books and itemlists) that are not. Having a standardized format for all scripts can reduce redundant code handling, moreover it allows developers to expect the script to be in a certain format, rather than needing to find out what format it uses before working with it. Most importantly, however, by using a standardized TAG=DATA format, we can uppercase the tag immediately upon reading it in (which you couldn't do if there is no TAG= as the DATA section gets read in as the TAG and thus the entire line uppercased). This would greatly reduce extra work we are forced to do uppercasing a tag every time we parse ScriptSections, instead doing it once and storing that.

Finally, harditems.dfn: thoughts, suggestions, etc. Should we simply leave it, or find a way to standardize it (thus making it easier for everyone to deal with).

[Grimson]

First of all, A section delimiter. I am quite happy with our TAG=DATA format, however once we get to the DATA, the information can be split by spaces ( ) in some scenarios, and commas (,) in other scenarios. Notably neither of these delimiters would work in a line of text, as a comma and a space are both regularly used expressions. Thus we need to decide on a relatively rare section delimiter for the DATA value. My thought, is the semicolon (;) however that symbol can be infrequently used in a line of text, so perhaps it isn't the best choice.

Maybe a "*", "@" or "|", they are barely used in normal text. The pipe would IMHO be the best choice out of those three.

Finally, harditems.dfn: thoughts, suggestions, etc. Should we simply leave it, or find a way to standardize it (thus making it easier for everyone to deal with).

The first entrys look quite ok. Only the type 12 entrys are hard to read due to the many IDs in one line, I would suggest to break those into seperate entrys or allow to specify additional IDs as part of one entry.

P.S. you have a PM .

[Xuri]

Having one entry for every single door sounds a bit like overkill to me.

[giwo]

*nod* Thus why I'm fielding ideas and thoughts on if it's worthwhile changing harditems.dfn at all...

[Maarc]

I think moving to a consistent TAG=DATA system is a good idea, but then, that's what you and I have talked about giwo

As for hard items ... some of it's immediacy, I guess, may become less important. I'm looking at it now, and apart from doors, there's very little of any substance there, and what *is* there, I wonder about these days

The rest seems primarily of the sort

Code: Select all

weight=#
pile=1
decay=1

Weight and Pile are covered in the DFN Override system now, so we can ensure that some of this is set right through there. I don't think Decay is covered through it. And weight might be an issue, as it's a UI08 in the DFN Override system, whereas it can be higher than that through harditems, I think (or at least, it does documentation wise).

But the rest is just doors. And basically, all we're doing there is assigning type 12 to a bunch of item IDs.

Honestly, I don't see a big issue with breaking out into individual sections. Let's face it, it's almost never going to be touched (it's rarely updated). If new doors are added, it's easier to maintain (lesser risk of buggering up what's already there). And if we write a tool (it's on my list of things to do) that is a context specific DFN editor, some of this goes away too. We turn 2 sections into 42 with the doors, but they'll all be fairly simple anyway.

Plus, from an optimisation perspective, doing so is faster (string based map lookup, rather than stepping through section by section to see if the section header is a substring match).

[jr]

Not that I'm much of an expert, but there seems to be an awful lot of code like

Code: Select all

if( weaponID == 0x13B1 || weaponID == 0x13B2 || weaponID == 0x26C2 || weaponID == 0x26CC ||
    weaponID == 0x2571 || weaponID == 0x0F4F || weaponID == 0x0F50 || weaponID == 0x13FC ||
    weaponID == 0x13FD || weaponID == 0x26C3 || weaponID == 0x26CD || weaponID == 0x27A5 ||
    weaponID == 0x27F0 )	// Is it a bow?

or

Code: Select all

if( targetID1 == 0x05 )
{
	if( ( targetID2 >= 0x3B && targetID2 <= 0x4F ) || ( targetID2 >= 0x51 && targetID2 <= 0x53 ) || ( targetID2 == 0x6A ) )
	return true;
}

in both C++ and JS code to compute membership of a given item/tile/whatever to a certain group. It would be nice to have a general mechanism to specify lists of ids so we could just write

Code: Select all

if (isA (ourObj.id, "bow"))

This should also be capable of handling the doors in harditems.

[giwo]

jr makes a good point. Something like that would be possible, as that's basically how we handle NPC id's, with the creatures.dfn. Perhaps we could do something similar for items and be free of the harditems.dfn entries alltogether.

[Grimson]

jr makes a good point. Something like that would be possible, as that's basically how we handle NPC id's, with the creatures.dfn. Perhaps we could do something similar for items and be free of the harditems.dfn entries alltogether.

We do already have a type setting for items, we could extend the list: http://sourceforge.net/docman/display_d ... _id=113893
and use this for those checks. We also already have a itemtypes.dfn .

[Xuri]

Maarc: You mentioned a "DFN Override" system - what is that? I don't really care how you guys change the system, as long as you don't take away the ability to add "blank" items into the world without having to modify the source to do so

[Grimson]

Maarc: You mentioned a "DFN Override" system - what is that? I don't really care how you guys change the system, as long as you don't take away the ability to add "blank" items into the world without having to modify the source to do so

I guess he means the tiles.dfn in the map folder.

Btw. does this work for all types of tiles or only for static tiles?

Edit:

And weight might be an issue, as it's a UI08 in the DFN Override system, whereas it can be higher than that through harditems, I think (or at least, it does documentation wise).

If I'm not wrong weight for a single item can be up to 255, where 255 means it's not movable. So higher values wouldn't make much sense, and a UI08 should be enough, unless we wan't negative weight values for some reason.

[giwo]

jr makes a good point. Something like that would be possible, as that's basically how we handle NPC id's, with the creatures.dfn. Perhaps we could do something similar for items and be free of the harditems.dfn entries alltogether.

We do already have a type setting for items, we could extend the list: http://sourceforge.net/docman/display_d ... _id=113893
and use this for those checks. We also already have a itemtypes.dfn .

itemtypes.dfn applies only to DoubleClick(), and is being phased out as we export DoubleClick() functionality to JS.

Item types are also iffy as for an item to have a type it must have been created by the DFN's (with the type set in said dfn) or have an entry at harditems.dfn at the time of its creation. Thus any item created prior to a new type being assigned in the dfn's would not have that type, and basically be bugged. Secondly, there are many items that fall into a certain group which already have types. Types were never meant to specify what ID an item had (and thus if it blocked, etc) types were meant more for triggered actions. So you could, theoretically, have a wall tile with a container type set on it.

As a side note, if we want to trust the muls, most of the ID checks we have could be done away with in favor of tile flags.

[Grimson]

itemtypes.dfn applies only to DoubleClick(), and is being phased out as we export DoubleClick() functionality to JS.

Ok.

As a side note, if we want to trust the muls, most of the ID checks we have could be done away with in favor of tile flags.

We can already overwrite those flags, so we could use them and fix the flags that are wrong in tiles.dfn. And for the flags not present in the muls we could add them by ourselfs. The only downside is that tiles.dfn could get very big.

[Grimson]

Ok, this is not a change in DFN handling but it seems to somewhat fit into this thread:

Currently there are some areas in the source where we create items by using IDs that are compiled into the sources. For example in newCarveTarget() when carving a human and newbieItems() for the basic clothing. At least in those two examples we also use entrys from already existing DFN files, so I think we could add special named entrys to those DFNs and get the IDs from them. Like "[CARVE HUMAN]" for carving and "[DEFAULT CLOTHING]" for the newbie items. This would make those functions more configurable and easier to fix in case the IDs change or are simply wrong.

What do you think?

[giwo]

That sounds fine, if there is any good way to incorporate that into the current system, it would be preferrable, as code re-use is always the best way. But we should avoid having forced ID's in the source whenever possible.

[Grimson]

That sounds fine, if there is any good way to incorporate that into the current system, it would be preferrable, as code re-use is always the best way. But we should avoid having forced ID's in the source whenever possible.

Alright, then I'll have a look at it tomorrow.

Btw. about trusting the muls. Take a look at static tile 0x1516, it's skirt but also flagged as a weapon.

[giwo]

Not suprised at all....

If you take a look at mul and movement handling we have several areas (not counting what we've already fixed with tiles.dfn) that I will eventually have to add tiles.dfn entries for.

[Maarc]

I think that trusting the MULs to some degree is a good starting point, but ultimately in some ways it doesn't have the level of details that we want. It's good for determining if things can stack or pile, but it's not good at separating out whether an item weapon is a one handed sword, a mace, or a crossbow, you know?

Essentially, yes, tiles.dfn is a sort of equivalence to creatures.dfn, really, just for items, instead of NPCs. There would be nothing wrong with minor (and they should only need to be minor) extensions to the tile class to include customisations as we might need them.

For instance, to shunt out most of the weapon data to a tiles.dfn sort of thing, you'd be looking at pushing out

* WeaponType - the type of weapon they are (including none!)
* CombatSkill - the skill associated with using this weapon
* HorseAnim - animation for a PC when this item is used in combat on horse
* FootAnim - animation for a PC when this item is used in combat on foot
* HitSound - sound to play when this thing hits (may need to be longer than 1, given wrestling is a random choice)

Thing is, though, CombatSkill, HorseAnim and FootAnim are more bound to the weapon type, than the weapon ID itself. However, people may want to alter that in future too, so it does give us a little flexibility without extending the WeaponType enum in future.

Note that there is potentially more than a single animation for foot combat, so that may need to be a list.


As a quick aside, I just saw PlaySwingAnimations(), and surely there must be a way to shunt out the special case eagle stuff into creatures.dfn somehow?

And while we're on the subject of dfn changes, how about hair/colour validation stuff? At the moment, the IDs for validating new PCs hair or skin colour is pretty much hard coded. Is there not a way we could shunt this out to the DFNs, and maintain the list there? eg something like

Code: Select all

[VALIDHAIRSTYLE 0x0190]
{
STYLE=0x2FBF
...
}

[VALIDHAIRCOLOUR 0x0190]
{
COLOUR=0x03EA, 0x0422
...
}

[VALIDFACIALHAIR 0x0190]
{
FACIAL=0x203E, 0x2041
...
}
etc

And include skin colour as well as facial style.

Other possible things to push out:

* DropSound - Sound when an item is dropped (at the moment, it's gold or gems, then a sound based on what it's container is)
* OnOpenSound - when a door is opened
* OnCloseSound - when a door is closed

What you then have left is a list of IDs for anvils, targeted IDs for mining, hard coded reagant IDs (could we not integrate this into the create menu / resource system somehow, for reag requirements?), PackTypes (is the item a pack? If so, what type?), PackModel (the model ID to send based on the pack type), CItem::IsMetalType(), CItem::IsLeatherType(), CItem::IsFieldSpell()

You also have a possible upgrade to creatures.dfn in CChar::IsValidMount() and MountCreature().

I would suggest that if you moved out the weapons, isMetal, isLeather and Pack stuff, that it would deal with the vast majority of the hard coded IDs (barring the others mentioned here). But there's a fair chunk there, and we don't necessarily want all of it out to dfns, and we don't want to bloat up Tile too much either.

[Grimson]

* WeaponType - the type of weapon they are (including none!)
* CombatSkill - the skill associated with using this weapon
* HorseAnim - animation for a PC when this item is used in combat on horse
* FootAnim - animation for a PC when this item is used in combat on foot
* HitSound - sound to play when this thing hits (may need to be longer than 1, given wrestling is a random choice)

It also would be nice if we could override some or all of those settings per item, this would allow to customize weapons a bit more. At least CombatSkill, HitSound and WeaponType should work, the animations I'm not shure how the client handles that.

Edit:

And while we're on the subject of dfn changes, how about hair/colour validation stuff? At the moment, the IDs for validating new PCs hair or skin colour is pretty much hard coded. Is there not a way we could shunt this out to the DFNs, and maintain the list there?

Why not add these to creatures.dfn or races.dfn (I think the race code already has ways to set valid hair and beard types).

What you then have left is a list of IDs for anvils, targeted IDs for mining, hard coded reagant IDs (could we not integrate this into the create menu / resource system somehow, for reag requirements?)

Isn't this about to be moved out to JS together with magic and skills?

[Maarc]

While I can appreciate the desire to want to do that, I think it's fraught with potential bloat. Let's face it, most items in the world aren't going to be weapons anyway, and these properties can't be reused for other purposes for other item types.

So at a minimum you're looking at

1 byte - weapon type
1 byte - combat skill
2 bytes - horse anim
2 bytes - foot anim
2 bytes per entry - hit sound

so you're looking at 8 bytes just for a minimum entry added to *every* single item in the world, for what would be arguably < 10% (and in reality, probably < 5%) of the world's item population. And that's another few attributes to parse/save, which impacts load times, and everything.

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.

[Maarc]

Well yeah, I'd sort of expect all that mining related stuff to get shunted out to JS anyway, so that's why I listed it (it's in there and currently used), but didn't consider it a priority

I personally would love to see PC created elves belong to an elf race, and humans belong to a human race, and do some of it through there. But I don't know if the hair/beard/skin validation on the races stuff is flexible enough to cope at the moment (though we could always just extend that). I'm happy enough to look into the changes for that, I just don't want to make potentially big changes like that without getting others thoughts

As for reagants ... currently, we've got a bunch of tags and store it in the spell structure. I'm just suggesting that instead of that, we store a pointer to a CREATE entry, which contains the requirements there instead. Sort of about leveraging existing code and keeping it up to date that way (and simplifying the engine somewhat).