Print

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

[Arni]

Built together with that one: dfraweditor
Sourcecode & download: http://code.google.com/p/dfraweditor/


DwarfStruct will be a XML based Modding tool for Dwarf Fortress.
It's written in Java and will be open source as soon as I got that far, that there is a stable version.
The Userinterface as well as the raw code will be steered by XML-Configurations.
Currently it is in the planning phase. This means you can help to improve the end quality of the software. Feel free to contribute! Urists wants you!

We've developed so far a XML base but it still needs a lot of improvement (for XML will be the base of all and should be fitting perfectly to all possible raws!)

Current XML examples

Code: [Select]

<raws>
   <attribute name="OBJECT:ITEM">
   <!-- adding no argument does make it just selectable. No entering values -->
      <description>Object:item does contain all items that are currently modable like weapons, armor and food</description>
      <!-- description is optional. It will be then displayed as help to mod -->
      <attribute>
         <attribute name="ITEM_ARMOR">
            <argument type="textField"/>
            <description>give a logic name to your item</description>
            <attribute required="true">
               <attribute name="NAME">
               <argument lable="Singular" type="textField"></argument>
               <argument lable="Plural" type="textField"></argument>
               <description>Yes, that's how your item should be called ingame!</description>
               </attribute>
            </attribute>
            <attribute name="ARMORLEVEL" required="true">
               <argument type="slider" min="1" max="3"/>
            </attribute>
            <attribute name="LAYER" equired="true">
               <argument type="combobox">
                     <option>armor</option>
                     <option>over</option>
                     <option>under</option>
               </argument>
            </attribute>
            <attribute name="SHAPED"/> <!-- you can add it or not. Your decision. It will be just shown in a selection list... That will maybe on the right. -->
         </attribute>
      </attribute>
      <attribute name="ITEM_WEAPON">
      <argument type="textField"/>
      <attribute>
      <!-- etc. for all OBJECT:ITEMs -->
      </attribute>
      </attribute>
   </attribute>
   <!-- The other objects are just appended -->
   <attribute name="OBJECT:REACTION">
      <!--That's the biggest problem i currently see. Anyone got any smart ideas here? Skipping a few to get to the jucy ones-->
      <!-- multiple is a boolean that allows you to have multiple entries of that type. Is REAGENT the only one that allows multiple entries?  Because it seems to requires a special case due to numeratoin. We can leave that to the user though...
      [REAGENT:B:1:METAL_ORE:COPPER]  It should be possible to search for the metal_ores. But the question here is: how to map that in the xmls?
      Even more fun the [PRODUCT:100:2:BAR:NO_SUBTYPE:METAL:BRONZE] . I'm not advanced enougth in the art of dfmodding of realy to know that. Help?   -->
      <attribute name="REAGENT" multiple="true">
     
   </attribute>
</raws>Thanks to Artanis00 for bating me in the right way with the XMLs.

Explenaitions
Abstract seen every dwarffortress raw tag is an attribute. And every attribute can have an infinit amount of children and siblings.
Every attribute can also have an infinite amount of arguments. Using the user imput in the arguments and the attribute the basic rawtag can be constructed that way.

The current problems im running against are

• How to map smart a reference to an other object. Like in entity_default [CREATURE:DWARF] the creature type that must be read out of the object:creature files.
• How to map the tree of possibilities in the reactions. I dont realy have an overview over [PRODUCT:PERCENTAGE:AMOUNT:TYPE:SUB_TYPE:TYPE:ITEM]

Help is most welcome.


Original thread:
http://www.bay12forums.com/smf/index.php?topic=19206.0

[MiamiBryce]

While the raws aren't in XML, they are a form not unlike XML.  I think we could do well to use actual XSD to define the raws.  Here's a rough, off-the-cuff,  interpretation of descriptor_color_standard.txt...

Spoiler (click to show/hide)

<xs:schema>

  <xs:simpleType name="UnsignedByte">
      <xs:restriction base="xs:integer">
        <xs:minInclusive value="0"/>
        <xs:maxInclusive value="255"/>
      </xs:restriction>
  </xs:simpleType>

  <xs:element name="NAME">
    <xs:attribute name="name" type="xs:string" use="required"/>
  </xs:element>

  <xs:element name="RGB">
    <xs:attribute name="red" type="UnsignedByte" use="required"/>
    <xs:attribute name="green" type="UnsignedByte" use="required"/>
    <xs:attribute name="blue" type="UnsignedByte" use="required"/>
  </xs:element>

  <xs:element name="COLOR">
    <xs:attribute name="id" type="xs:string" use="required"/>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="NAME"/>
        <xs:element ref="RGB"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>

Another thing I noticed is that information on what control type to use is also embedded in the definition XML.  I think that would be separate of the definition of the structure of the data.  Since this community standard would be used for multiple modding tools (hopefully we get to that point!!) different tools might use different controls for different object attributes.

I think what control one would use would end up being programatically determined by the front end being used by the modding tool.  I'll speak for myself when I say that I would look at the red, green, and blue attributes above and see they are defined as integer and have a restriction of lower bound of 0 and upper bound of 255.  A slider of 255 long would take up too much real estate, so I'd probably just whip up a text box with an integer-zero-to-255 validator on it.

Anyway, that's my two cents.