Print

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

[Eagleon]

Alright, I realize I might be trolled for this, but I thought it'd be good to get the idea out there anyway so that people start thinking about it. Right now, all editing is done in flat files. That's great. I like that. I can work with that, and it's fun. However, the tokens are becoming more and more diverse and arcane. Some of them crash the game if used improperly, some of them have parameters that are obscure and buried within the bowels of the Wiki, and many are obsolete or redundant.

What I propose is something a bit more flexible and extendable. Something easy enough for a beginner to pick up, but which can be rapidly updated and improved without relying on coders. A community effort, however the coding work required past completion is minimal or nonexistent if it's made properly, so anyone could help improve it in the coming years.

Enter <project>. Most modders might realize that the raws are (at least currently) quite standardized in format. There's no reason there can't be a GUI-based editor made right now. It'd be relatively easy to slap one together, but it wouldn't stay current. Where the difficulties come in is that DF is being constantly updated and improved. New tokens added, removed, new parameters, new possibilities, etc. So why not allow people to add and change those within the editor itself?

I'm not saying it'd be easy at all to make. It'd require a lot of planning and foresight. Lots of coding grunt-work in MSVC or similar. But with DF's community, I believe it can be done.

What's required isn't a list of things that can be done, but a list of possible rules that tags could have. Off the top of my head, there are tags required within a raw without exception ([OBJECT:<whatever>] for instance), tags that have a list of acceptable parameters and no others ([OBJECT:<whatever>] being CREATURE, BODY, DESCRIPTOR, ENTITY, ITEM, etc.), tags that may only be placed after another tag if it has a specific parameter (so [CREATURE:<whatever>] would not be placed after [OBJECT:ITEM]), tags that have to be placed after a specific other tag for them to affect that definition (a category which most tags fall under), tags which are basically required to be present beneath another tag ([NAME:<singular>:<plural>] maybe), tags that have one or more parameter, tags that don't, tags that require one or more parameter or don't require some or all of them, tags whose parameter(s) are arbitrary strings and not hard-coded ([NAME:<feh>], [CREATURE:<feh>], [ENTITY:<feh>], [REAGENT:#:REACTION_CLASS:<whatever>]), tags that accept only numbers for their parameter(s), tags that only accept a certain range of numbers (none that I can think of off the top of my head, but it's possible), tags that have to fall under a certain order with other tags to remain effective (ditto), tags that can be added multiple times ([SPHERE:<beh>], [ATTACK]s, etc), and so on. I'm sure there are others.

All of these could be checkboxes, fields, or lists in the tag editor. For instance, to define PREFSTRING as a tag I would make it have one parameter, and for that parameter I would mark it as being an arbitrary string. I would also check that it must fall under another tag, in this case [CREATURE]. Since [CREATURE:<feh>] is checked as always falling under [OBJECT:<feh>] when [OBJECT:<feh> is CREATURE], PREFSTRING would not be seen when editing items, languages, and so on.

I realize this all might be confusing, but it's central to my idea. Once all tags are defined this way, the main program could be used like any other mainstream game's mod suite, such as the TES Construction Set for Morrowind, Oblivion, etc. Imagine just checking off and filling in the things you need for any one creature you're creating. Having all the tokens in front of you, with community-created help text available as you hover over their checkboxes and fields. Don't have the sphere list handy for defining what your new critter can be worshipped for? Just click the list box next to it and select what you need. New update made [SPHERE] accept an arbitrary definition, and there's now a scary new raw file for defining their associations (woot!/augh!)? DESPAIR NOT! Your friendly DF community has already updated the tag definitions, or will soon, and now you have a whole new editor, no coding required.

I'd hope it would also encompass raw-file merging and reversion. That might be for later versions. The tag definition file might not have to be downloaded with this if the user just wanted a mod management tool. I don't know.

It's a dream at least. I can't make it on my own, not quite yet at least, but maybe someone will be inspired to create it. For now ideas and suggestions are welcome.

[nicholasneko]

i think i suggested this very thing, though not as well writen, at least twice now and nothing came of it.

[Nesoo]

quote:Originally posted by nicholasneko:
<STRONG>i think i suggested this very thing, though not as well writen, at least twice now and nothing came of it.</STRONG>

I wasn't planning on announcing it until I got further along (my C++ is still pretty rusty right now), but I was working on an init file editor as per your request. The first few versions would probably be hard coded and have little if any error checking, but I do have an xml file set up to define what the tags are and what values they can have that will eventually be read in. The xml file would be pretty easy to edit as needed for new versions. A goal is to have a preview of the selected tileset in colors as you edit them (as per Trukkle's suggestion).

If I get something like that working, going on to a mod editor would be the next goal.

Of course, the key word here is "if", which is why I hadn't announced it yet... announce too early and then lose interest... not cool. So, don't get your hopes up and pretend that you didn't read any of this  

[Arni]

A GUI based RAW Modtool is a nice idea. I had that very idea as well and begun with it. The troublesome part is the including of the raw Attributes in the tool.
My idea is creating a Java software that will read XMLs with the definitions in them. So in the Java there is just logic how to process the XMLs & RAWs. Most of the modeling of the GUI is done by the XMLs. (There will be still some basic gui components contained in the java though)
The XMLs might look something like that.

Code: [Select]

<rawFile header="[OBJECT:ITEM]">
<rawElement header="[ITEM_ARMOR:?]" input="textField" mandatory="true">
<rawAttribute attribute="[NAME:?:?]" input="textField" input="textField" mandatory="true"></rawAttribute>
<rawAttribute attribute="[ARMORLEVEL:?]" input="slider(1:3)" mandatory="true"></rawAttribute>
<rawAttribute attribute="[LAYER:?]" input="dropdown(ARMOR, OVER, UNDER)" mandatory="true"></rawAttribute>
<rawAttribute attribute="[SHAPED]" mandatory="false"></rawAttribute>
</rawElement>
</rawfile>

That way the software does not to be adapted when the raws are extended. It's just the XML that must be changed and that can be done by most people.

What do you think about it? Do I have your support on this?

[Tormy]

A GUI based RAW Modtool is a nice idea.

Having a mod tool like that would be awesome. I was always wondering, that why don't we have one yet. [...considering that we have tons of very different mods/hacks/utilities/etc. already.]

[MaximumZero]

I approve. That would make things a whole lot easier and faster.

[Arni]

Work in progress 

Still Todo:
    * Fill XML content in raw structure master
    * Create GUI (<-- That might take friggin long)
    * Create new Files (<-- easy)
    * Read existent files (Comments will make it fun)
    * Update old files
    * Get the bay12forum users to create XMLs for me, so i dont have to do the annoying work

[Artanis00]

A GUI based RAW Modtool is a nice idea. I had that very idea as well and begun with it. The troublesome part is the including of the raw Attributes in the tool.
My idea is creating a Java software that will read XMLs with the definitions in them. So in the Java there is just logic how to process the XMLs & RAWs. Most of the modeling of the GUI is done by the XMLs. (There will be still some basic gui components contained in the java though)
The XMLs might look something like that.

Code: [Select]

<rawFile header="[OBJECT:ITEM]">
<rawElement header="[ITEM_ARMOR:?]" input="textField" mandatory="true">
<rawAttribute attribute="[NAME:?:?]" input="textField" input="textField" mandatory="true"></rawAttribute>
<rawAttribute attribute="[ARMORLEVEL:?]" input="slider(1:3)" mandatory="true"></rawAttribute>
<rawAttribute attribute="[LAYER:?]" input="dropdown(ARMOR, OVER, UNDER)" mandatory="true"></rawAttribute>
<rawAttribute attribute="[SHAPED]" mandatory="false"></rawAttribute>
</rawElement>
</rawfile>

That way the software does not to be adapted when the raws are extended. It's just the XML that must be changed and that can be done by most people.

What do you think about it? Do I have your support on this?

If I may suggest a few things about the XML, I think it may be easier to do something like this (rationale and explanations in the xml comments):

Code: [Select]

<raws>
    <!-- all raw files start with `[object:type]`; the object part can
         be implied. Also, keeping to one bit of data per field means
         that further parsing can be limited.
         
         To put that a little more forcefully, designing an XML format
         such that you need to use regular expressions on the data is
         rather stupid.
         
         Similarly, the brackets around a tag are implied and can be
         skipped here. Also, all tag arguments are separated by colons,
         so each additional argument implies the colon that preceeds
         it, resulting in just needing the tag name itself. This will
         also make it easier to handle tags with an arbitrary number
         of arguments, such as eye colors, building tiles, template
         arguments, etc.
    -->
    <raw object-type="item">
        <!-- the item's programmatic name is implied as a required
             text field. If that changes you'll need to alter the
             software to handle it anyway.
        -->
        <entry type="item_armor">
            <!-- renamed mandatory to required. Seems to flow better,
                 and is used in other xml formats, IIRC.
                 
                 A cosmetic change.
            -->
            <attribute name="name" required="true">
                <!-- By splitting arguments out of the attribute
                     element, each one can be specified as required or
                     not on it's own. I know some tags have optional
                     arguments.
                     
                     Also, they can be named or hinted individually,
                     and you can have optional tags with required
                     arguments.
                     
                     And, I'm pretty sure having multiple identically
                     named attributes in a single element doesn't work.
                -->
                <argument name="singular" type="text" required="true" />
                <argument name="plural" type="text" required="true" />
            </attribute>
            <attribute name="armorlevel" required="true">
                <!-- by splitting slider apart, you again avoid
                     further parsing.
                -->
                <argument type="slider" min="1" max="3" required="true" />
            </attribute>
            <attribute name="layer" required="true">
                <!-- essentially the same as slider above, but with
                    text, and inspired by HTML's select element.
                -->
                <argument type="combobox" required="true">
                    <option>armor</option>
                    <option>over</option>
                    <option>under</option>
                </argument>
            </attribute>
            <!-- required/mandatory defaults to false.-->
            <attribute name="shaped" />
        </entry>
    </raw>
</raws>

As a suggestion--however you define the XML format--do creatures first. Creatures are the most complex right now, so that way if you have to make changes to encompass them you won't have to go back and change everything else to match.

I look forward to seeing how you handle the caste/tissue/etc. selection commands.

[jetex1911]

hmm. a raw editing program. . . now i can make races easier!

[MaximumZero]

Work in progress 

Still Todo:
    * Fill XML content in raw structure master
    * Create GUI (<-- That might take friggin long)
    * Create new Files (<-- easy)
    * Read existent files (Comments will make it fun)
    * Update old files
    * Get the bay12forum users to create XMLs for me, so i dont have to do the annoying work

Is it just Memory.xml that you need? You can usually find that updated in the Stonesense/dfHack threads within a few hours of a new release.

[WormSlayer]

Bumping this thread to bookmark it - Awesome idea!

[MiamiBryce]

been playing DF all day, my brain is melting from need to sleep at this point.  I looked cross-eyed at what I saw here and I think I like what I saw.  If you're going to do the End-All, Be-All tool, please check out my ideas for change tracking, versioning, and publishing if you've not seen them yet:

http://www.bay12forums.com/smf/index.php?topic=63316.0

I swear I spend more time tracking mod changes I make than making the changes.

[Arni]

If I may suggest a few things about the XML, I think it may be easier to do something like this (rationale and explanations in the xml comments):

Code: [Select]

<raws>
    <!-- all raw files start with `[object:type]`; the object part can
         be implied. Also, keeping to one bit of data per field means
         that further parsing can be limited.
         
         To put that a little more forcefully, designing an XML format
         such that you need to use regular expressions on the data is
         rather stupid.
         
         Similarly, the brackets around a tag are implied and can be
         skipped here. Also, all tag arguments are separated by colons,
         so each additional argument implies the colon that preceeds
         it, resulting in just needing the tag name itself. This will
         also make it easier to handle tags with an arbitrary number
         of arguments, such as eye colors, building tiles, template
         arguments, etc.
    -->
    <raw object-type="item">
        <!-- the item's programmatic name is implied as a required
             text field. If that changes you'll need to alter the
             software to handle it anyway.
        -->
        <entry type="item_armor">
            <!-- renamed mandatory to required. Seems to flow better,
                 and is used in other xml formats, IIRC.
                 
                 A cosmetic change.
            -->
            <attribute name="name" required="true">
                <!-- By splitting arguments out of the attribute
                     element, each one can be specified as required or
                     not on it's own. I know some tags have optional
                     arguments.
                     
                     Also, they can be named or hinted individually,
                     and you can have optional tags with required
                     arguments.
                     
                     And, I'm pretty sure having multiple identically
                     named attributes in a single element doesn't work.
                -->
                <argument name="singular" type="text" required="true" />
                <argument name="plural" type="text" required="true" />
            </attribute>
            <attribute name="armorlevel" required="true">
                <!-- by splitting slider apart, you again avoid
                     further parsing.
                -->
                <argument type="slider" min="1" max="3" required="true" />
            </attribute>
            <attribute name="layer" required="true">
                <!-- essentially the same as slider above, but with
                    text, and inspired by HTML's select element.
                -->
                <argument type="combobox" required="true">
                    <option>armor</option>
                    <option>over</option>
                    <option>under</option>
                </argument>
            </attribute>
            <!-- required/mandatory defaults to false.-->
            <attribute name="shaped" />
        </entry>
    </raw>
</raws>

As a suggestion--however you define the XML format--do creatures first. Creatures are the most complex right now, so that way if you have to make changes to encompass them you won't have to go back and change everything else to match.

I look forward to seeing how you handle the caste/tissue/etc. selection commands.

Thanks for the improved XML. After some thinking i came to the conclusion that this seems to be the best solution, eventhough it will be more of a pain in the ass to process the nodes.

Bout the caste/tissue/etc. What's wrong with an attribute having attributes? It's not really a big difference between [OBJECT:TYPE] and [CASTE:castename].

(Thanks for asking that question. It helped me to come up with a better System for my internal structure in the java. Why not building a nice little tree? )

[Artanis00]

Thanks for the improved XML. After some thinking i came to the conclusion that this seems to be the best solution, eventhough it will be more of a pain in the ass to process the nodes.

XML is (a) pain... even when you use it for something it was designed for, like what you are doing.

Bout the caste/tissue/etc. What's wrong with an attribute having attributes? It's not really a big difference between [OBJECT:TYPE] and [CASTE:castename].

That might work.

[Lord Urist]

There's something similar already created (not anywhere near as comprehensive, though):
http://www.bay12forums.com/smf/index.php?PHPSESSID=c92f6c1c7aade3d58e3416f80f943e66&topic=59730.msg1341973
it's not mine, but it looks pretty good - it seems to have flopped and died though. Just thought to point you guys towards it - if you can get this dream a reality then... well, I don't know, but it sounds like a great idea!