Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Askot Bokbondeler]

ptw

[BradUffner]

Getting close to having a good definition editor in the application.  It should be ready sometime tonight unless I hit a major snag.  This should be a lot easier than editing the raw XML.

Spoiler (click to show/hide)

[BradUffner]

I took a little time and threw up some descriptions for 50ish tokens and a few descriptions/arguments for those with them.

Spoiler: Here's the list (click to show/hide)

ABUSE_BODIES
ADOPTS_OWNER
ACTIVE_SEASON
BENIGN
SPRING
SUMMER
AUTUMN
WINTER
UNDERSWIM
UTTERANCES
WET
DRY
AQUIFER
WAFERS
DEEP_SPECIAL
DEEP_SURFACE
EQUIPS
AMPHIBIOUS
AQUATIC
ARENA_RESTRICTED
AMBUSHPREDATOR
ALL_ACTIVE
DIURNAL
VESPERTINE
MAXAGE
MEANDERER
MISCHIEVOUS
NO_AUTUMN
NO_DRINK
NO_EAT
NO_DIZZINESS
NO_FEVERS
NO_SLEEP
NO_SPRING
NO_THOUGHT_CENTER_FOR_MOVEMENT
NO_WINTER
NOBONES
NOBREATHE
NOEMOTION
NOEXERT
NOFEAR
NOMEAT
NONAUSEA
NOPAIN
NOSKIN
NOSKULL
NOSMELLYROT
NOSTUCKINS
NOSTUN
NOT_BUTCHERABLE
NOT_LIVING
PARALYZEIMMUNE

Also I discovered 2 creature tokens that (probably because they don't occur in vanilla DF) didn't show up on your token list.
OPPOSED_TO_LIFE
MATUTINAL

Lastly I wanted to do the temperature tokens (FIXED_TEMP, HOMEOTHERM, etc.) but I couldn't quite figure out how to get it to accept the degreesUrist type and if it required a subtype or not.

I see you are adding more tokens!  I accepted the new items you added.  I'm going to give you moderator access so that you can approve your own items.  One thing I wanted to mention was that I saw for the ARMOR_LEVEL token you ended up having to repeat the arguments and description several times.  There is a shortcut to doing this.  Set the Usage to ALL:ALL and that same description will be used for every thing that the token is allowed on.  The "allowedOn" list still controls what things it is valid for, but this will save a lot of typing.  This way you only have to enter the arguments once.  If for some reason there is one usage where you want something different you can still do this.  enter the generic stuff under ALL:ALL, then enter your specific type.  It will always search from most specific to most general, using the ALL:ALL entry as a catch all.

[BradUffner]

I see you are adding more tokens!  I accepted the new items you added.  I'm going to give you moderator access so that you can approve your own items.  One thing I wanted to mention was that I saw for the ARMOR_LEVEL token you ended up having to repeat the arguments and description several times.  There is a shortcut to doing this.  Set the Usage to ALL:ALL and that same description will be used for every thing that the token is allowed on.  The "allowedOn" list still controls what things it is valid for, but this will save a lot of typing.  This way you only have to enter the arguments once.  If for some reason there is one usage where you want something different you can still do this.  enter the generic stuff under ALL:ALL, then enter your specific type.  It will always search from most specific to most general, using the ALL:ALL entry as a catch all.

As an example, here is the one of the tokens you just did, modified using the shortcut.

Code: [Select]

<token name="BARRED">
<allowedOn type="ITEM" subType="ITEM_ARMOR" />
<allowedOn type="ITEM" subType="ITEM_GLOVES" />
<allowedOn type="ITEM" subType="ITEM_HELM" />
<allowedOn type="ITEM" subType="ITEM_PANTS" />
<allowedOn type="ITEM" subType="ITEM_SHOES" />
<usage type="ALL" subType="ALL">
<description>Allows item to be crafted out of bone.</description>
</usage>
</token>

The token will still only be allowed to be placed on the subtypes listed, but now they all share a description.
You can enter "ALL" for either the type of subType to have it treated as a wildcard.

[i2amroy]

Yeah I'm working my way through them, though someone else will need to handle the ones in the GRAPHICS category since I've never messed about with graphics before. Also thanks for the example, I'm sure it will make things easier!

Just a few things here:
1)I see that in your Data file you have a list of biomes. Is there any way for me to reference that list without needing to make one that includes every biome for every time it comes up? If so is there a way similar lists with all of the skill tokens or profession tokens could be made/referenced?
2)Is there a way to make an argument that is optional for a given token? This occurred with the ARMOR token as the rarity value is technically optional, but I'm not sure how to have a blank option on a list.
3)The last problem showed up when I took a stab at the APPOINTED_BY token. The token uses the list of positions that is defined in the entity, so I would assume that a "lookup" type would probably function best in this case. The problem then comes that since the various positions are defined inside of a normal entry, I couldn't see a way to point the lookup to find the defined positions inside of the entity.

[BradUffner]

Yeah I'm working my way through them, though someone else will need to handle the ones in the GRAPHICS category since I've never messed about with graphics before. Also thanks for the example, I'm sure it will make things easier!

Just a few things here:
1)I see that in your Data file you have a list of biomes. Is there any way for me to reference that list without needing to make one that includes every biome for every time it comes up? If so is there a way similar lists with all of the skill tokens or profession tokens could be made/referenced?
2)Is there a way to make an argument that is optional for a given token? This occurred with the ARMOR token as the rarity value is technically optional, but I'm not sure how to have a blank option on a list.
3)The last problem showed up when I took a stab at the APPOINTED_BY token. The token uses the list of positions that is defined in the entity, so I would assume that a "lookup" type would probably function best in this case. The problem then comes that since the various positions are defined inside of a normal entry, I couldn't see a way to point the lookup to find the defined positions inside of the entity.

There are still a few details I have to work out with some of the more advanced tokens.  Especially those with variable numbers of arguments.  I would skip those for now.  I'll take a closer look at the APPOINTED_BY token after I get the in-app definition editing working and come up with some way the get the data in there.

[i2amroy]

I'm still getting some problems when I'm trying to use temperatures for arguments.

This is what I have for the argument:

Code: [Select]

<argument name="boiling point" type="degreesUrist" />and I keep getting the error "Index was outside of the bounds of the array".

[BradUffner]

I'm still getting some problems when I'm trying to use temperatures for arguments.

This is what I have for the argument:

Code: [Select]

<argument name="boiling point" type="degreesUrist" />and I keep getting the error "Index was outside of the bounds of the array".

I think I found the problem.  I'll have a fix for it soon.

[BradUffner]

Website has been updated. degreesUrist types seem to be working now.

[BradUffner]

Ouch, I just realized that this whole time the path to df.exe in the settings wasn't getting saved. Sorry about that guys 
It'll be fixed shortly.  I'm just polishing up the code to submit token definitions to the DF:Tokens site.

[BradUffner]

Alpha 11 is up!  This release includes in-app token definition editing!!! 

Do edit a token definition just right click it in the token grid.  In order to submit your definitions to the website for everyone to enjoy you will need to register at http://dftokens.gumpstudio.com.  Then open Raw Explorer and put your user name and password in to Tools > Options.  Once that's done there will be a checkbox on the token definition editor to upload your edits.  The submissions will need to be approved by i2amroy or myself before you can download them using Help > Update.

This probably still has a few bugs in it, so if you run in to any problems please let me know.  I'll probably have time for one quick round of bug fixing tomorrow before I head off for Easter Dinner; I won't be back until monday.

I wanted to publicly thank i2amroy for all the work he's been doing today entering tokens with the XML editor on the website.  He has entered dozens of definitions so far using a method that can't be easy.  Everyone give him a round of applause!

[BradUffner]

11.1 released, fixed a bug in definition submission.

[i2amroy]

Thank you! Thank you!

Anyways I've got another hundred or so in and though I've gotten fairly good at the XML editor, I'm very glad that there will be an easier way to input tokens. I'll be shutting down for the weekend in just a bit, though I might manage to get some more tokens entered in tomorrow in between church and dinner sometime. I'm just happy to help make this turn into a tool that all of us modders can use and can't wait until it reaches a widely usable point.

Also if anybody out there is good with graphics packs and their various tokens don't be afraid to step up and edit those tokens. I've never used a graphics pack myself, so I'll probably sticking to the other tokens until I've got those done so a bit of help there would be greatly appreciated.

[BradUffner]

A quick note about what "StickTo" is for in the definition editor.  This is used when you export your work back in to raws.  Whenever a token is written to the file it checks the previous token.  If the the previous one is in the current one's "stick to" list, it will output in the same line instead of going going down a line.

"ParentOf" will work similarly, but it's used for indenting (or will be when I get to that point).  Any token with items in that list will have those tokens indented under them when they are output.

[BradUffner]

3)The last problem showed up when I took a stab at the APPOINTED_BY token. The token uses the list of positions that is defined in the entity, so I would assume that a "lookup" type would probably function best in this case. The problem then comes that since the various positions are defined inside of a normal entry, I couldn't see a way to point the lookup to find the defined positions inside of the entity.

I'm reworking the typeData for lookup types to handle this (don't worry, existing data will be backwards compatible).
The new format will start with a "command", either "object" or "token" so far.

"object" works like the current format, where it returns a list of objects that match a type and subtype.  "object:ITEM:ITEM_SHOES" to return all "shoe" items in the raws.

"token" is a bit more complex, but it will support to the more advanced feature you will need for things like APPOINTED_BY.
The format is "<objectId>:<TokenName>:<argumentIndex>".  So "token:MOUNTAIN:POSITION:0" will return a list of all the POSITION tokens within the MOUNTAIN object (0 for the first argument of that token).  There is one more step needed to actually do the APPOINTED_BY token though, "replacements".  Anything between a set of "%" in the type data will be replaced with the value of a token in the current object being edited. Anything between "~self~" will represent that the source is from the same object.

Using all this the typeData for APPOINTED_BY would be "token:~self~:POSITION:0" (if I managed to follow my own logic).  This will start working in a future version, it's not finalized yet, so don't try to enter tokenData using this format yet.

UPDATE

IT WORKS!!!!  My crazy scheme actually works!  MWAhahahhahahahahhahahaha.

Spoiler (click to show/hide)

Now I'm off to go stuff myself full of ham.