Print

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

[Intrinsic]

Visual building editor? holy cow batman! Fantastic work on this dude.

[BradUffner]

Beta 7.1 is now available.  This bug fix release fixes 2 potential crashes related to spheres.  It also causes the building editor to correctly draw tiles set to "Use Mat Color" (Black and white with Red -> blue gradient overlay).

[Jeoshua]

Oh man, I'm starting to use Notepad++ less and less now for changing settings.  Fantastic work thus far.

And the community has really stepped forward with the token definitions.  This pleases me to no end

Right now I'm most concerned with the idea of this utility spitting out a 100% workable raw folder with it's default settings.  I'm testing this by importing and then exporting a mostly vanilla 34.10 raw folder (it has phoebus color and tile changes, but is otherwise normal).

I've noticed that the png graphics files are being correctly exported over, but end up about half the size.  Looking at the difference in-game shows no real changes, and examining the files in photoshop reveals that very little has actually changed, mainly being confined to the backgrounds of the files.  I assume this is all due to recompression.

Possible additions or changes:

• Comments - Various mods and even the vanilla game files use invalid tokens in order to make comments in the raws.  It might be possible to parse unknowns as a "comment" line.
• Basic Tokens - Almost every token which takes no arguments gets output in the files as [TOKEN_NAME:] instead of [TOKEN_NAME].  Note the extra ":".  It parses correctly in DF, but leads to confusion when using external tools to check out the changes.
  In language_words.txt alone, there are 2,869 changes of this type, and all tokens seem to be correctly defined as taking no arguments.  Over the entire vanilla fileset, after exportation, there are 23,935 occurances of ":]"
  It could "easilly" be fixed by adding a new "Args Type" of "None" to the Token definitions, instead of just "Basic" or "List"
• More on Language - language_words.txt is being exported over, but the words files (language_DWARF.txt, language_ELF.txt, etc) and the symbol file (language_SYM.txt) are not being evaluated or exported.  Two object types are basically being overlooked in the [OBJECT:LANGUAGE] files:
  
  • [SYMBOL:x] - subsymbol [S_WORD:x]
  • [TRANSLATION:x] - subsymbol [T_WORD:x]
  They're very simple file types actually.  Far simpler than language_WORDS.txt.  It might be possible to show the translations side-by-side in a grid so that all the translations could be viewed and edited at once (in a perfect world where everything is possible of course).
  
• Formatting - There are several conventions of raw syntax that have evolved over time.  Technically they are not required for any specific tokens to work correctly, but they do help in readability.  Compare: body_default.txt before and after exportation.  At best, this is a minor consideration, but it would be nice to be able to specify that, for example, Caste level tokens be indented farther than Creature level tokens, or that [CON:x] should appear on the same line as a [BP:x] token
• Save-Editing Mode - Some features may break a game if performed on a save\regionX\raw folder, such as adding or deleting any objects or object files.  It would be fairly simple to "lock" this ability with a menu option.
• Adding Graphics Files - Under Manage Source, adding a GRAPHICS source will lead to a file named "object\filename.txt" instead of putting the file into the Graphics folder.

[BradUffner]

Thanks for the notes!  I'm just blown away by how quickly everyone got together and defined the tokens!  I really wasn't expecting this kind of response.  Like I've said before.  Raw Explorer would be useless without the correct argument definitions. All of it's fancy editors and syntax checking come directly from know what type each argument is.  Without that data you would just be editing a string.  Fantastic work guys!!!

The comments are going to be very tricky. Raw Explorer currently actually reads them and stores them in memory, but doesn't output them.  So far I haven't come up with a decent way to know which token to attach them too.  They are currently attached to the token that proceeds them in the raw file, but this isn't always correct, especially where comments are multiple lines.  Take this snippet for example:

Code: [Select]

[BODY_DETAIL_PLAN:HUMANOID_RELSIZES]
[RELSIZE:BY_CATEGORY:LIVER:300] Of course!  Standard relative size for humanoids is 200.

Tendons and ligaments are currently very abstract, but adding these flags will let wounds occur that damage them.  The number afterward is the healing rate.  Lower is faster.

[USE_MATERIAL_TEMPLATE:SINEW:SINEW_TEMPLATE]There are logically actually 2 separate comments here, but physically it is one continuous block of text.  Raw explorer doesn't really have a way to correctly split this out. If you were to move the RELSZIE token up and down the token list, it would take the larger comment below it and move it too. I have a few ideas, but I don't know if it will work in all cases.  It IS something I want to get working eventually though.

I hadn't noticed the superfluous ":" in the stand alone tokens on export.  It should be an easy fix.  Thanks for bringing it to my attention.

The language tokens are actually going to be very tricky.  I'm going to have to store them separately because they "conflict" with several of the other object IDs.  For example the DWARF creature has the same objectId as the word DWARF.  This causes raw explorer to think there is a conflict.  I may have to do something like the BODYGLOSS Editor, where it is done in a separate interface.  I love the idea of displaying all the translations side by side though!


Formatting is going to be another tricky one.  Some of it can already be done using the "Sticks To" list in the definition editor.  That will only handle situations where tokens should display on the same line as previous tokens.  I have 2 things planned that should take care of most of the formatting.  The first is similar to "Sticks To", which is "Contains", where you will be able to specifiy that tokens in the contained list will be indented under the token that contains them.  The 2nd one will deal specifically with the caste issue.  I'm adding a "scope" property to token definitions where you will be able to specifiy if the token is scoped at the Object level or the Caste level.  Once that's done any caste level tokens will be able to automatically be indented under their caste.

I have some ideas about fixing the graphic set resizing bug too.  I may push out another bug fix release tonight or tomorrow to fix some of these problems.

[Dunamisdeos]

Hey there, I got a bug when I tried to add more than one resposibility tag to a noble. Crashed out of the program. Also, does the same thing if I try to add a NAME_MALE or female token.

[BradUffner]

Hey there, I got a bug when I tried to add more than one resposibility tag to a noble. Crashed out of the program. Also, does the same thing if I try to add a NAME_MALE or female token.

I've have release Beta 7.2 that fixes this bug.  It also fixed the export formatting of tokens with no arguments.

[Jeoshua]

The formatting and commenting suggestions are of minor consequence, truly.  The primary concern is that they work correctly, and they do.

I wasn't aware of how the language definitions would overlap, but now that you mention it I suppose it could be an issue.  There should probably be an [OBJECT:LANGUAGE] subsystem of some kind that handles them in a separate environment, since they are very peculiar files in general, many different actual object types being covered under one overarching type.  Technically you can place all of the language files into one file and it works correctly so long as they're ordered correctly

I've tested this, and Masterwork also contains a language_all.txt file with all the translations in one file.  The Words and Sym files were separate, but I tested out placing them into the language_all.txt file and it worked without any noticeable problems... tho it did change what things were named in a totally seeded worldgen like any file changes seem to do.

[Putnam]

Why doesn't there seem to be a BUILDING_FURNACE type?

[BradUffner]

Why doesn't there seem to be a BUILDING_FURNACE type?

Is that a valid subtype of building?  I don't recall seeing it anywhere.  The majority of features were taken from the default raws.  If it wasn't in the default raws then it probably didn't make it in to raw explorer unless someone specifically mentioned it to me...  I don't see it being hard to add if it's actually valid.

[Putnam]

Yeah, it's valid. I use it. It's a subtype of BUILDING.

[BradUffner]

Yeah, it's valid. I use it. It's a subtype of BUILDING.

Consider it added for the next version then!  Does it use the same format for tile, color, and blocking tiles as workshops?

[Putnam]

It's all the same--the only distinction is that BUILDING_FURNACE shows up in the furnac(e) folder under (b)uildings.

[Bohandas]

looks cool

[Bohandas]

How do I access the workshop editor shown in the topic post?

[the_game_hunt]

Raw Explorer 7.2  , Let's try this.

Oh, btw now I can download from the main link,I dont know why I couldnt