Print

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

Dwarven Selection

113 (6.3%)

Wildlife

58 (3.2%)

Ambushes

154 (8.6%)

Sieges

207 (11.5%)

Undeads

118 (6.6%)

Forgotten Beasts

110 (6.1%)

Megabeasts

42 (2.3%)

The Circus

84 (4.7%)

FUN Spiral

286 (15.9%)

Dwarven Engineering

131 (7.3%)

FPS Death

396 (22%)

Other? (please specify)

97 (5.4%)

Total Members Voted: 879

[Jeoshua]

But isn't adding a tileset or a mod already adding files to "smudge" your "clean install"?  Phoebus_16x16.png is not a default file that comes with the game, so you're already breaking that rule.  And the current method employed, of putting the files in a subdirectory, is the cleanest way to add the files I can think of.

Adding files to multiple, spread out parts of the hard drive seems extremely disorganized and wasteful.  Sure, that's how a lot of modern programs do things, but the rules are different on every architecture you want to run the file on.  On XP it's different than Vista.  Vista is different than 7.  Linux puts it all in the /usr folder but in various places inside there depending on various things.  It's all quite a clusterfuck, and the program has to be aware of where things will be put for whichever version of whatever OS the user is running.

OR...

You could just put it in the same directory as the program, and go for the "portable" route.

[Shandra]

Adding files to multiple, spread out parts of the hard drive seems extremely disorganized and wasteful.
OR...
You could just put it in the same directory as the program, and go for the "portable" route.

Depends on style and architecture of the system (*1)... putting dependencies into the folder sounds somewhat alike to "good old dll-hell" (or is at least is to be called redundant, as it means that one has to copy his personal "patches/templates/tiles" from ones working/design/bla folder into the games directory with each change) - and most modern applications are putting their defaults into their folder and add for customizations/3rd party addons a folder for that game/app in my_documents - and phoebus basic sets are in that semantic 1st party (belonging in the app folder), whereas personal tile patches are 3rd party addon stuff And in the end, that one setting is only interesting for the people like me who are keeping some personal tiles which aren't default phoebus ones - so the average customer of the set wouldn't need that option at all...

So the better way (as in my previous suggestions) is to do not enforce a particular way to the user but to let him stay in control...

*1: like having seperate partitions for OS/Temp/Swap/Apps/Data - in times ago that even was considered the "organized way" (unless we are talking *nix based systems) :p And all installers/etc. wich didn't make use of the environment variables and weren't able to choose the destination folder where considered bad style/programming (aimed at those "whats RTFM?-kind of lazy users" and beeing a PITA for us old-timers/geeks who likes to be in control of their system)....

[Jeoshua]

I just feel that tying a program that doesn't use registry or "My Documents" kind of files (Dwarf Fortress itself) with a program that does do these things (the proposed change to the ever-so-simple Tileset Assembler) is kind of a mistake.  If both programs work on similar assumptions about where their data is, they will work in the same environments.  If they use wildly divergent ideas, their compatibility is no longer guaranteed to be in the same state when one moves from computer to computer (ie, it may work fine on a home computer but not on a kiosk)

[Shandra]

I just feel that tying a program that doesn't use registry or "My Documents" *1kind of files (Dwarf Fortress itself) with a program that does do these things (the proposed change to the ever-so-simple Tileset Assembler) is kind of a mistake.  If both programs work on similar assumptions about where their data is, they will work in the same environments.  If they use wildly divergent ideas, their compatibility is no longer guaranteed to be in the same state when one moves from computer to computer (ie, it may work fine on a home computer but not on a kiosk)

So either .ini or command line parameter - having the advantage of further parameters that could be added like tilesize_x, tilesize_y - so that this fantastic work could be easily adopted for the ironhand-set or such - if that's not aimed for a environment variable would still be the third option (so for portable users that would mean a .bat wich sets the variable and executes the app, other users may just enter it in setup/system/etc. but then CLI Par is far more convenient from a programmers POV)

[*1: And in a way DF currently has a separate folder in my_documents on my system - thats where I keep my saved .mht WIKI Articles, my custom gfx-files, my custom raw raws, my *science* files, etc.]

[Jeoshua]

And in a way DF currently has a separate folder in my_documents on my system - thats where I keep my saved .mht WIKI Articles, my custom gfx-files, my custom raw raws, my *science* files, etc.

That's really not what I was talking about.  Those aren't necessary to have Dwarf Fortress.exe run.  Those are Documents in your Documents folder, as it should be.  Also it's a personal choice, not a program architecture question.

So my opinion is .ini files absolutely.  or Tileset_Init.txt or however you want to slice it.  Registry settings would seem to me to be a horrible fit for this game.  Anyways, inside the file, there could be a path that tells where Data\Art is and where the Tileset\ directory is too, in relative path terms.  All programs generally start with ".\" as their working directory, meaning they run where they are.

Done like this, it would be guaranteed to work in the exact same situations that DF does, and would be able to be freely placed on any hard drive in any folder on the computer.

[Phoebus]

I'm not changing the tileset module directory, I'm just adding different sources, so you can use the DF subdirs for easy access and temporary storage, or "roaming"/"my Documents" for a more stable storage location for your tileset mods.

I've already completed filters and config files. Tilesets no longer need to be 256x256 if they have a .txt config file. Config can control the copying of tile per tile, or areas to areas. Tiles can be relocated (Ex.: several tiles in a small png can be relocated to several different parts of the final tileset). Tile can clear the previous/default stuff or can even restore the background texture (which can now be changed).
Filters and/or config can control which parts are left untouched, which are cleared and which are restored to the ground texture, all before copying the tile image.
I've also changed the category system. Two new categories were added "Ground Mods" and "Customization". Both are multiple choice categories, ground mods modify the ground texture, and customizations modify the final tileset. I've dropped some specific categories I've also merged the ground and floor categories. Special changes (flat ground, punctuation & grimdark) have been moved to the custom categories.

All that is already completed.

I will most likely try to publish the default modules in a packed (zip) form when installed, for maintenance reasons. (Deleting obsolete files is a pita.)

[Jeoshua]

Hmm... as long as the Roaming directory is not required for the program to work in the first place, it shouldn't be a problem.  As I stated above, my only concern is in DF's continued compatibility with Library computers, such that let one run .exe files, in which one cannot modify c:\ in any way... since half the time that's my only option.

Pseudocode:

if Roaming\Tileset Assembler exists then
  use it
else
  go on to using the files in the local path.

[Phoebus]

*Updated* 0.31.25v15
Sanitized the Tileset Assembler. (Warn me if there's any bugs/problems with it.)
Streamlined the list of Symbol Charts and Rough Walls.
Added an extra tileset for Mac/Linux users: Smooth.

[Phoebus]

The Tileset Assembler will also seek files in "\AppData\Roaming\DwarfFortress\TilesetAssembler\" and "\My Documents\DwarfFortress\TilesetAssembler\"

Config files need to have a .txt extension and be named the same as their .png.

Tags:
[DIM:Tileset_Width:Tileset_Height:Tile_Height:Tileset_Width]
[Tile:Command:X:Y]
[Tile:Command:X:Y:W:H]
[Tile:Command:X:Y:To:X:Y]
[Tile:Command:X:Y:W:H:To:X:Y]

Commands:
"Overlay" will draw the content over without altering the content.
"Clear" will delete the tile.
"Group" will delete the tile and replace it with the ground texture.
"Filter" will alter the tile using the Filter file ("SameName.Filter.png"). White = replace with ground, Black = clear, Transparent = don't alter.

Tilesets without config files default to "[DIM:16:16:16:16][Tile:Filter:0:0:16:16]"
Walls, Stone Walls and Stone Symbols have different default config set to only copy the appropriate tiles.

Standard tileset, with several tiles being redrawn. Tile tags are treated in order.

Code: (Base__Standard.txt) [Select]

[DIM:16:16:16:16]

[Tile:Overlay:0:0:16:16]
[Tile:Clear:2:1]
[Tile:Clear:5:2]
[Tile:Filter:12:3:3:1]
[Tile:Clear:15:5]
[Tile:Filter:2:9]
[Tile:Clear:3:9]
[Tile:Filter:12:13:4:1]

Custom tileset mod size:

Code: (GroundMod_Flat_Soil.txt) [Select]

[DIM:4:1:16:16]

[Tile:Clear:0:0:To:0:6]
[Tile:Clear:1:0:To:7:2]
[Tile:Clear:2:0:To:12:2]
[Tile:Clear:3:0:To:14:2]


[Jeoshua]

That looks almost exactly like the DF graphics files!

I knew I believed in you, Phoebus

[Phoebus]

The goal of the tileset assembler is not only to make my life easier and provide more tileset combinations to the user, but also to allow other member of the DF community to contribute/exchange their own tileset work as easily as possible.
I will be collecting tileset mods over the weekend and release them as a big pack on Sunday, or, hopefully, earlier if there's a DF update. *wish* *wish*

[krenshala]

WinXP Pro SP3, tried to run the Tile Assembler and it died with "Cannot initialize 0xC0000135".  Does the .exe need to be moved for it to work right?

[Phoebus]

WinXP Pro SP3, tried to run the Tile Assembler and it died with "Cannot initialize 0xC0000135".  Does the .exe need to be moved for it to work right?

Edit: No, it needs to be in the same directory as Dwarf Fortress.exe.
Did the old TilesetAssembler.exe crash the same way?

Try this version to see if it fixes the problem: TilesetAssembler.exe @ MediaFire

Edit: Why no feedback! ;_;

[Jeoshua]

Because you made the game so pretty you made us all want to play?

No news is good news! Working fine over here!

[krenshala]

WinXP Pro SP3, tried to run the Tile Assembler and it died with "Cannot initialize 0xC0000135".  Does the .exe need to be moved for it to work right?

Edit: No, it needs to be in the same directory as Dwarf Fortress.exe.
Did the old TilesetAssembler.exe crash the same way?

Try this version to see if it fixes the problem: TilesetAssembler.exe @ MediaFire

At work right now, but I'll give that a try when I get home.  The rest of the v15 DF install is working fine, so I wouldn't be surprised if it was something peculiar to my computer.