Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rochndil

Pages: [1] 2 3 ... 13
1
In preparation for the (hopefully soon!) new build of DF, I DLed and installed 43.05 (all my current work was still on 42.06). Installed all the necessaries (DF Hack, TWBT, Rubble), copied over my Rubble mod files, hit Build, and BAM! Everything (that I've figured out how to do yet) is all ready to roll. Migration almost pain-free. Rubble rocks!

Rochndil, who still has a TON of work to do, but that's always the case...

2
Good morning!

While TWBT 5.58 seems to be working fine, it's throwing an error on the DFHACK screen:

Warning: Plugin automaterial compiled for DFHack 0.42.06-alpha2-0-g6fd904f, running DFHack 0.42.06-alpha1-10-g6fd904f
Warning: Plugin mousequery compiled for DFHack 0.42.06-alpha2-0-g6fd904f, running DFHack 0.42.06-alpha1-10-g6fd904f
Warning: Plugin resume compiled for DFHack 0.42.06-alpha2-0-g6fd904f, running DFHack 0.42.06-alpha1-10-g6fd904f
Warning: Plugin twbt compiled for DFHack 0.42.06-alpha2-0-g6fd904f, running DFHack 0.42.06-alpha1-10-g6fd904f

I just re-downloaded everything, and the error is consistent. Again, though, it doesn't seem to actually be causing any problems, so it may fall into the "acknowledge and ignore" category.

Since this seems to be a compilation/version compatibility issue, it would be helpful to include a download link to the DFHACK version the TWBT version was compiled for.

Rochndil, finally getting back to mod development...

3
Good evening!

I just got the few free minutes I needed to test the latest build(s) and the strange issue I posted about above did NOT happen again. I did also have the chance to de-dust my box and re-seated all the critical components, so there's no way to know if the problem was actually caused by a code issue or hardware problems on my end. BUT, seeing a bug go away is always a good thing, especially since I NEED TWBT to continue developing the mod(s) I'm currently working on. Keep up the awesome work, and if I encounter anything else worth reporting I'll post here.

Rochndil, poking and puttering away...

4
Good afternoon!

I just confirmed (at least on my equipment) a repeatable bug. Install DF 42_06, gen pocket region, embark, looks fine. Add DFHACK, test same game, looks fine. Add TWBT (and minimal configuration to test), test, and within a few moments, the game will switch from rendered characters to colored bricks (one per character) for the entire interface. This takes from a few seconds to a minute or so to happen, but it does happen consistently. FWIW, TWBT seemed pretty stable with the previous test-build under 42_05. If you need any specific data/files/specs to check into this, please let me know. Tomorrow I'll re-test on my work PC.

Basic data:Windows 7x64, 8GB RAM, AMD 5770HD graphics.

Rochndil, who will have to continue development on 42_05 for the moment...

P.S. Checked the work PC today, and the problem does NOT occur. It's a good deal different, but neither system has had issues with DF before. Basic specs: Win10, 16GB RAM, Xeon processor, Nvidia GeForce 8800 GTS. It's not impossible my home system needs maintenance.

5
Good morning!

Thanks for looking into the issue. The thing that's odd is that ALL the graphics in this set have the old-school magenta background, but ONLY the Dwarf graphics are showing the background. The files (that I've been using for years) did NOT show this behavior before conversion, and all the creature graphics (that I saw in testing) worked fine. It seems fairly unlikely that the original files were different in some way, but not impossible. I suspect there's a difference in the way the race/major files are being processed, supported by the fact that their tile pages are rendered differently than the creature/mans files (horizontal instead of vertical).

A couple of small things to add.

First, a bug/issue. The GUARD/ROYALGUARD tags are deprecated now, and should instead be LAW_ENFORCE and TAX_ESCORT respectively. An easy enough thing to fix in the output, but better to have it right from the start.

Second, I'd like to suggest an enhancement. I take the output from your process, and run it through the Rubble process. The difficulty is that, first, Rubble has issues with mixed-case filenames. So I had to convert all the filenames, AND REFERENCES, to lowercase. In addition, Rubble also wants the TXT files and the PNG files in the same directory, which means updating all the PNG references in the TXT files. Exporting everything in lowercase consistently wouldn't really change anything (other than the processing inside your code), but would save a lot of modding time on the other end. Changing the references to eliminate the subdirectory is pretty trivial, so if you want to leave that off (I can see that it could introduce issues with the subdirectory structure you use).

All that said, your program has performed an amazing amount of work for me. The process took longer than it probably should have, but that's largely my fault, since I broke some stuff and had to fix it the hard way. Even with that, if I were doing the whole thing by hand I'd probably STILL be working on it, not looking at an almost-completely-perfect update/conversion.

Rochndil, fiddle-poking at stuff to see what breaks...

6
Got a bug.

It's pretty small, but definitely there. Here's the header from a graphics TXT file, before Rubble parses it:

Code: [Select]
graphics_qs_st_crt_annelids

[OBJECT:GRAPHICS]

[TILE_PAGE:CRT_ANN]
[FILE:qs_st_crt_annelids_16x16.png]
[TILE_DIM:16:16]
[PAGE_DIM:1:5]

The filename, unsurprisingly, is: graphics_qs_st_crt_annelids.graphics.txt

Now here's what Rubble drops into the /raw/graphics folder:

Code: [Select]
graphics_qs_st_crt_annelids.graphics

# Automatically generated, do not edit!
# Source: addons:dir:Rochndil/Graphics/Chariot/graphics_qs_st_crt_annelids.graphics.txt
graphics_qs_st_crt_annelids

[OBJECT:GRAPHICS]

[TILE_PAGE:CRT_ANN]
[FILE:qs_st_crt_annelids_16x16.png]
[TILE_DIM:16:16]
[PAGE_DIM:1:5]

You can clearly see that the filename parsing doesn't strip off the .graphics extension when it creates the new first-line-same-as-filename, though it DOES do so when it actually names the saved TXT file. On the up side, DF doesn't seem to care, and didn't error on any of the files.

You might want to check the code that parses the filename and then adds the header, or, alternatively, you could just rename the file, keep the (redundant in this example) original first-line-same-as-filename header, and insert your two #-fronted lines between that and [OBJECT:GRAPHICS] - whichever makes more sense.

Rochndil, still hunting for and finding bugs...

7
Not recognizing uppercase extension is a simple oversight on my part, an easy fix.

Good morning!

I look forward to testing the new version, since I JUST finished the Chariot graphics changes (not without a few bugs) and need to test them anyway.

I had a sneaking suspicion that case-insensitive filenames would be complicated to implement. In my day-job work, I've seen our programmers struggle with similar issues. NOT doing it, but documenting the NEED for case-sensitivity, is a perfectly acceptable choice.

As I work through this project, if anything else relevant crops up, I'll let you know. Thanks!

Rochndil: test...bug!...fix...test again...

8
Good afternoon!

I'm basically done with the "purist" version of Chariot's graphics, but have an odd error. Everything seems to work just fine, EXCEPT that the Dwarf graphics are being rendered with their magenta backgrounds, while the creature graphics are not. I did an experiment and flattened a copy of the Dwarf file so I could set the transparency, which worked. I'm a bit mystified why that was ONLY necessary with that file.

I can, of course, do the same with all the race files, but I'd like to know what happened to cause the problem in the first place, and either avoid it in the future (if it was something I did) or submit it as a bug (to improve the program).

Here's the archive, updated and standardized: http://dffd.bay12games.com/file.php?id=11824

Once I know what's going on, I'll fix the error and post a final copy.

On a different note, I did find that the "couldn't find find the file" error log I was looking for WAS in the "Lines_with_problems.txt" file, but I didn't notice it at first.

Please let me know what you find. I'll work on some other things in the meantime.

Rochndil, with many irons in the fire...

9
Good morning!

I've (mostly) completed the conversion process, and overall your tools worked just fine. I had two small issues, which would be good to document for other users.

1. The system needs to be rebooted after installing the MATLAB program, or your tools can't find it. It's also a little tricky to know if you HAVE successfully installed MATLAB, because it doesn't leave a lot of footprints in the system.

2. In order to process properly, the graphics mod files need to be in /dirname/raw/graphics or the tool(s) won't "see" them and just go through the motions.

Both are easily corrected by documenting. Preventing user failures (and frustration) is always a good thing.

Now, once I got things actually working, your instructions were pretty much right on the money, and while I did have problems, they were on my end. It would be helpful, if possible, to have a little error-checking in your program. The main problem I had was the file-references for my PNG files were wrong in my TXT files, but the program never identified the problem, and therefore didn't LOG anything about it. If your tools could add lines to the output "icon referenced in file(x) line(n), but image not found" it would have saved me a lot of time and head-scratching.

Other than that, everything went fine. I need to try a merger next, and if I encounter anything else noteworthy I'll let you know. Thanks for the great tools, you saved me hours, if not days, of work.

Rochndil, still working on updating Chariot's classic graphics...

10
Good afternoon!

I am very much looking forward to using this tool to help with my current project (rehabbing Chariot's graphics). The only problem (at the moment) is the sheer size of the MATLAB program, which is taking forever to download. Rest assured that as soon as I have the ability to do so, I'll be doing an actual project with your tools, and I'll give you detailed feedback. Thanks!

Rochndil, watching the MATLAB download waffle on either side of 1+ hours to go...

11
Well, after a lot of trial-and-error (LOT of error on my part) I've got the graphics mod working properly. I even set up a little hierarchy for all my current (one) and future (many more) mods with meta tags and stuff. There's a ton of clean-up to do on Chariot's stuff (the last time he updated was around 2010), but that's all on me to take care of.

I'm very pleased to have compiled (successfully) my first Rubble mod, knowing that it'll be the LAST time I have to do all that jiggering, and can simply apply it to future versions of DF in moments. Yay!

Future projects will get a lot more complicated, but one step at a time. I can't wait to see soil inclusions again.

Rochndil, with probably a day or two of work to finish the current clean-up...

12
Good afternoon!

I'm finally moving forward with my perennially-delayed MMO mod, and just today started messing with Rubble-izing some of its components. I started simple, or so I thought, but I'm not having a lot of success. There's a very weird problem with the Graphics mod parsing. I won't bore you with all the debugging steps I've taken, but instead point directly to what seems to be the problem. I tried to get my old Chariot graphics working as a Rubble mod, and the parsing works without errors...but does NOT write anything to the raw/graphics folder. However, the included vanilla graphics mod DOES work, so I spent some time trying to tease out the reason why.

It seems to be the double-extension used (which, coming from a long history of DOS use, was a huge no-no once upon a time).

The two files in the pre-packaged "vanilla" mod, which DO work, are:

user_graphics_vanilla.graphics.txt and user_graphics_vanilla.graphics.bmp

I was looking at this for ages before I finally noticed the . instead of the _ character. If you modify one of the files to take out the extra extension, it then FAILS to move over to raw/graphics, which is how I finally noticed the problem.

All that said, though, the file reference in user_graphics_vanilla.graphics.txt points to user_tilesets_vanilla_graphics.bmp - which is the wrong filename for user_graphics_vanilla.graphics.bmp once it's copied over as user_graphics_vanilla.bmp - so there's an actual error as well as a lack of clarity going on.

Now that that's all figured out, I need to fix all my names and see if I can get this to work. Add one more tiny bug and a documentation change to your list.

Rochndil, who is always all about the documentation...

P.S. Just did a little more testing, and found 1 bug and 1 issue. Bug: the program wouldn't move the PNG files (after adding the .graphics) because the extension was .PNG instead of .png. Issue: Rubble sees a sub-directory as a separate mod, instead of a part of the MAIN mod. It's messy to have to have all my images and text files in the same folder, but if that's the way it is, I can live with it.


13
Thanks for the reply, I think you may have nailed the behavior I was seeing. I'm still working my way through the tiles. It's been so long since I started this round that some of the tiles I added are no longer relevant! But, on the up side, that means more open spaces to do neat stuff with.

Rochndil, who got to spend Sunday covered in mud and unable to wash (digging up and repairing house water line)...just like a dwarf!

14
Good afternoon!

I've been working on my compilation tileset, and just started testing my overrides. Most of them work just fine (once I got all the definitions coded properly), but I'm having trouble with my QUIVER and BACKPACK entries.

This one works fine:

[OVERRIDE:088:I:BIN:BIN::ovr:004] (though I need to find a better bin graphic, my art sucks)

These two do not:
[OVERRIDE:146:I:BACKPACK:BACKPACK::ovr:008]
[OVERRIDE:146:I:QUIVER:QUIVER::ovr:009]

They don't display incorrectly (wrong graphic, blank, etc.), they just default back to the main tileset (archers and soldiers carrying chests on their back is somewhat amusing). It's not an end-of-the-world thing, but I'm just not sure if I did something wrong, or if it's a bug of some kind. I tried to double-check the ID and Type, but the .h files referenced in the documentation don't seem to be part of the HACK source currently.

Any help or suggestions will be appreciated!

Rochndil, working on the MMO project...again. One of these years it'll actually be done!

15
DF Modding / MMO* rides again!
« on: April 10, 2015, 01:08:51 pm »
*Metals and Minerals Overhaul

This is probably the third or fourth time I've re-worked this mod, let's see if I can finish it this time!

For the moment, this is a *very* in-progress project, but I'm hoping that with some of the new tools available I'll actually manage to finish it this go-around. I'm already taking advantage of TWBT's capabilities to dramatically improve tile handling. It's not QUITE full graphics, but darned close. Once I finish rebuilding the tileset (again!!), I'll switch over to Rubble and (assuming I can figure it out) use that to apply the tileset changes as well as the rest of the mod (which also needs radical overhauling to account for game changes).

In the meantime, I'd like to offer a little side-project that turned out to be an interesting adventure. In the process of rebuilding my main tileset, I discovered that there wasn't (or at least I couldn't see) a way to do "overrides" for world-gen map tiles. Then, quite by accident, I discovered that process was using the text tileset. Since quite a few of the characters for the world map weren't used anywhere else AS TEXT, I could replace them with more appropriate ones. This is the result, and perhaps someone who has ACTUAL GRAPHICS SKILLS (unlike me) might take the idea and run with it.

16x12 text tileset, primarily the work of the awesome Lord Zorinthrox http://dffd.bay12games.com/who.php?id=703, with additional tiles bungled together by me, or stolen from various much better tilesets (I have complete records, which will be included with the actual release).
https://www.dropbox.com/s/f5d8iyy43dko5pi/MMO_12x16_text.png?dl=0

There are additional tiles I could have replaced (=nV for example), but I decided to leave them either because they WERE used in text, or were better left alone for thematic reasons. A great challenge (for me) in this project was that many of the tiles needed have never (to my knowledge) been drawn before. Since I couldn't easily borrow, I had to forge many of them myself, which isn't pretty!

Here's a map example - looks pretty good if I do say so myself.

https://www.dropbox.com/s/20w7iu220ih1qf0/twbt_world.jpg?dl=0

It'll be a couple of weeks before I finish the main tileset, but when I do I'll also post it here. In the meantime, feel free to steal any of the knowledge I've discovered through this little side-track, and keep on digging!

Rochndil, who was planning to make this post THIS MORNING, not near 2pm...

P.S. I couldn't see an easy way to get DB to drop the images inline, but if someone knows how I'll happily edit to fix it.

Pages: [1] 2 3 ... 13