Print

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

[Fuco]

[UNDER DEVELOPEMENT: Looking for co-devs]
[UPDATE1:NEW_DOWNLOAD:DOWNLOAD_NOW!]

Hello fellow players and modders.

Recently I was doing some minor RAW edits and I was getting annoyed of notepad (gedit). I had some spare time so I've started this RAW editor project. I'm using Java and so far there are no problems running on all major platforms. Most of the content is configurable via XML/properties config files.

Current version is proof-of-concept syntax HL/autocomplete/doc loader application. The GUI is just so we can test the features. A friend of mine is working on a proper GUI (save/load/project browser/tabs...), so we might have something decent in a short time.

The keyword definition and styles for HL/AC are located in XML files. Currently, it only contains a few tokens. If you want to help out, I can send you instructions on what to do. You don't have to be a programmer, all you need to know is to use text editor. You can also participate on the programming, if you have some knowledge of java/swing.

I hope this will grow to be a viable option for all modders to use (even toady ), similar to IDEs like netbeans/msvs, but for DF RAWs instead

Screenshots:

Old pictures:

Spoiler (click to show/hide)

This image shows some syntax highlighting and autocomplete dialog. It behaves pretty much like netbeans/msvs autocomplete, so programmers get used to this in no time. The colors and text modifiers can be user-modified in the xml config. AC is currently invoked using ctrl+space

Latest version:
(treeview currently serve mostly for testing purposes)



Download:
First demo: http://dfraweditor.googlecode.com/files/editor.zip
Second demo: http://code.google.com/p/dfraweditor/downloads/detail?name=gui_20100905.zip&can=2&q= (AC/HL/id-ref working/Tree model - JTree component temporarily disabled)

SVN:
http://code.google.com/p/dfraweditor/source/checkout

Project googlecode page: http://code.google.com/p/dfraweditor/
Project power goals: http://code.google.com/p/dfraweditor/wiki/Goalsofthisproject

Suggestions welcomed

Changelog:
demo1->demo2:
Pretty much just fixing stuff and figuring out how to do it best
What should work:

• Highlight: Every 0.5s, the model is recalculated and the highlight is updated on the parts of the document that has changed.
• Document model (DOM): When loading the RAW file, a tree structure representing the RAW file is created. It contains all the relations between child and parent elements and arguments. Serves for autocomplete/highlighting and pretty much every action you take in editor
• Autocomplete: Can suggest valid containers/tokens/arguments (enums). Now also with "simple-ref" working (simple-ref means no need for <id> tags). This means you can define a material and later, when you [USE_MATERIAL_TEMPLATE] you will get a valid list of what can be there, based on the [MATERIAL_TEMPLATE]s you've defined. Invoke with CTRL+SPACE
• Descriptions: When you invoke autocomplete dialog, an interactive description is shown in a popup window (defined via <d> tag in raws.xml)
• Visible JTree representing model: currently for debuging purposes

[Shukaro]

This looks like it has the potential to be extremely useful to just about anyone who does work in the raws. Watching this thread closely.
Some suggestions:

A token definition library. Where the program could give you the function of a specific token (perhaps moused-over or highlighted) and tell you default values, warnings, and other information like that.

A template library. A collection of creature, item, and such entries that have all the important tokens in them, so that if you wanted to make a new creature or something you could just load up the template for it.

Looking at the goals page, the file-tree one is good, and I suggest being able to load up the raws from an installation, and have it sort all the creatures, reactions, items, and other things that have entries automatically into the proper category. Going with that, the ability to easily add/remove entries in both the vanilla files, and to have it automatically create files for custom entries would be amazing.

I don't have much experience with java, but I'll be happy to lend a hand with things that need doing. 

[Foamy]

I've been waiting for something like this. this has massive potential.

[MiamiBryce]

Zwei started an eclipse plugin for DF, you may want to look into what he did.

Might I suggest there may be some overlapping between your project and Arni's DwarfStruct project.  You may want to confer with Arni to see if there is any labor sharing that can be done, particularly in the area of defining what all of the objects that can appear in the raws are and what attributes those objects have.

I, personally, suggest we develop a community standard of xml document(s) that define the raws and what can appear in them so that those of use who want to make modding tools can without reinventing the wheel of how "OBJECT:LANGUAGE" -> "WORD:Id" -> " "NOUN|VERB|VERB:Singular:Plural" appear in the raws.  I mean if we had a firm XML schema and a set of (java looks to be pretty popular on these boards lately) libraries to load/save raws then any number of modding tools can be created using that back-end.

[Dbuhos]

I've been waiting for something like this. this has massive potential.

Same, I'm scared of modding because everything is SO complicated...

[Ironhand]

Excellent!

Does it limit the number of autocomplete tags based on the item type you're in?
Like, would you only be able to add [CHILD] tags when you're inside a [CREATURE]?

[Fuco]

Zwei started an eclipse plugin for DF, you may want to look into what he did.

I was looking at his soundsense and found the eclipse stuff via his signature . Formal RAW specs is an excelent idea, altho I fear eclipse is a bit too much for folks to install just to get RAW support. With this being said, coding LL parser isn't exactly that hard, and I hope (from the markup he made) RAW format is LL(1) language (someone want to prove this? ).

I, personally, suggest we develop a community standard of xml document(s) that define the raws and what can appear in them so that those of use who want to make modding tools can without reinventing the wheel

Again, good point. This is pretty much what he started with the xtext (is that how it's called?). I'd prefer XML over this because you can use XML with any language/tool, not just java or eclipse.

Does it limit the number of autocomplete tags based on the item type you're in?
Like, would you only be able to add [CHILD] tags when you're inside a [CREATURE]?

Right now, the only limit is the prefix of the token. It has no context-sensitive choices (like reducing choices to item tokens when you're in item container). This was planned, and my plan was to use rather ad-hoc definitions. Again, the formal spec seems much better.
Added to goal page.

A token definition library. Where the program could give you the function of a specific token (perhaps moused-over or highlighted) and tell you default values, warnings, and other information like that.

I had this in mind. It can appear as a box/mouse over when you invoke code complete (netbeans do this for example with javadoc), or maybe as a separate window/panel somewhere. This will be possible, however someone will have to write the documentation itself

A template library. A collection of creature, item, and such entries that have all the important tokens in them, so that if you wanted to make a new creature or something you could just load up the template for it.

Shouldn't be extremely difficult.

Both added to goal page.

I'll contact both Arni and Zwei to see if we can cook anything together.

[forsaken1111]

Marking this to watch it. Looks very promising.

[Rose]

looks good.

[zwei]

Zwei started an eclipse plugin for DF, you may want to look into what he did.

That project is asleep and possibly dead untill few bugs in xtext are fixed, but it is inspiration i guess.

[Fuco]

I've started work on first draft for DOM representation of RAWs. Right now I feel it'll make things easier, but maybe it wont... we'll see. It might be an interesting feature tho. It would be possible to work with it in similar way as with XML or HTML. But so far, HL and AC works fine without it.

Also, undo manager added. It was a bit tricky, I had to hack the event dispatcher and manually drop some events (for example style changes, as those are done by program not user).

We have discussed some things with Arni, and some cooperation is definitely possible. It will possibly lead to some standard RAW description format.

V 0.1 of my XML-based RAW description language: http://xml.pastebin.com/MneyWsRy

EDIT: I've simplified the format a bit, removing "f" (flag) entity, which was unified with tokens. All tokens/attributes are now required by default. New spec (68 lines) http://xml.pastebin.com/NiR7R7Ra
Experimental parser done in 200 lines.

The ITEM_ARMOR and related raws defined (111 lines w/ doc): http://xml.pastebin.com/F24rtQWZ

Ideas welcomed.

[Fuco]

Tree dom-like structure finished:



It will probably change a bit and the code still needs some cleanup, but the basics are done.

Features that will come with this: verification, argument autocomplete, simpler highlightning model. It should be possible to create javascript-like dom manipulation tools to further abstract the document. That, however, will come later.

Now, time to play some DF

[jaked122]

I must say that this is really cool... I'm gonna have to start using this.

[MiamiBryce]

Though I haven't examined what you've done in detail I'm unusually pleased by what I saw in my brief skimming of it.

I don't think I saw this in your examples - How are you planning on handling places where for example, you're editing an entity's armors and the list of armors would come from a look-up of all of the item_armors defined in the mod?

[Fuco]

Update, code is on the SVN

--------------------------------------------

I don't think I saw this in your examples - How are you planning on handling places where for example, you're editing an entity's armors and the list of armors would come from a look-up of all of the item_armors defined in the mod?

EDIT: I've written an article about id/ref and the format
http://code.google.com/p/dfraweditor/wiki/XMLFormat - about the format in general - very messy, it will need revisions to make it more understandable
http://code.google.com/p/dfraweditor/wiki/IdRefDraft - about the id/ref and some problems caused by RAW inconsistencies

(vv original part of the post follows vv)

In the XML spec, you define the ITEM_ARMOR entity to have an argument of type "string/id". Say the ID is ITEM_SUB_ID.

Code: [Select]

[ITEM_ARMOR:ITEM_ARMOR_BREASTPLATE]

and the definition
<c name="ITEM_ARMOR">
  <a type="string" id="ITEM_SUB_ID"/>
  rest omitted
</c>
ITEM_ARMOR_BREASTPLATE is now ITEM_SUB_ID. This tells the parser to append whaveter string found on that argument to the list of ARMOR IDs (it knows it's armor because we're in armor container tag)

This line from entity definition

Code: [Select]

[ARMOR:ITEM_ARMOR_BREASTPLATE:COMMON]

will look like this in the xml definition

Code: [Select]

<t name="ARMOR">
  <a type="string" ref="ITEM_SUB_ID"/>
  <a type="string"/>
</t>
Now, when editing, it will look at the 'ref' attribute and load up the list of ITEM_SUB_ID associated with "ARMOR" ITEM_ID (ITEM_ID is kind of supercategory of "ARMOR", "WEAPON", "TOY"..., while ITEM_SUB_ID is placeholder for item's logic names).

There is a slight inconsistency in naming. When defining item, it's called ITEM_XYZ, while the references are simply XYZ. So far this will be handled in the program code. It will probably be moved to the xml somehow. Probably in the form of lists of containers and their sub IDs and sub REFs. (ie ITEM_ARMOR ID map to ARMOR ref)

However, this feature is not yet implemented. But I'm confident it won't be hard (stuff might get complicated when handling creatures, but from the brief look it should be the same... I haven't found any nested references. Anyway, more research needed).

-------------------------------

Now, I have to figure out how to map elements in the Document (or TextPane) defined by their offset and length to the abstract document tree (heck, I'll just keep calling it DOM). I've finished some bruteforce lookup but I feel it's not the right approach. And I'm to scared of hacking javax.swing.text.Document model