Print

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

[Button]

Sorry for double-post, but in case anyone saw my previous post I thought I should make a new one.

After looking at the raw changes in 0.42.01, I see that nothing has changed that BAMM! cares about. As soon as tileset makers have adjusted their scroll/quire/book/etc. graphics, it should be ready to churn out graphicsenated mod-raws for the new release.

[TheDorf]

This seems like a wonderful tool, but I just can't get it to work :/

The three lines I'm supposed to edit in my run config file looks like so:


But when I run the program, I get this:




The "phoebus" folder is simply a renamed version of the phoebus tileset, without any modifications. "_df_42_01" is the folder where I keep the latest version of DF, and "_df_42_01_phoebus" is an empty folder. Where am I going wrong? :/

[Button]

You are doing absolutely nothing wrong. I fucked up.

I did that thing where you add a new feature, but you're not really ready to release it yet, and then you push a changes in a different file and accidentally take that new feature for granted.

QUICK AND DIRTY SOLUTION that'll get you up and running before I get a chance to fix things:

Add a line to your run.config setting extra_source equal to whatever your source property is. So in this case:

Code: [Select]

extra_source=C:\Users\Felix\Documents\Dwarf_Fortress\phoebus
ACTUAL SOLUTION:

I need to handle optional properties better. That'll have to wait til tomorrow though, cause it's 2 AM, I need to shower still, and I have work in the morning. Stupid sexy Dwarf Fortress.

[TheDorf]

Well, now it executes without errors, but I end up with the ascii version of the game in the output folder. 
Maybe I fucked up? I put the "extra_source=C:\Users\Felix\Documents\Dwarf_Fortress\spacefox" under the source, like so:

Code: [Select]

templates=resources/graphicstemplates.config
source=C:\Users\Felix\Documents\Dwarf_Fortress\spacefox
extra_source=C:\Users\Felix\Documents\Dwarf_Fortress\spacefox
target=C:\Users\Felix\Documents\Dwarf_Fortress\_df_42_01
output=C:\Users\Felix\Documents\Dwarf_Fortress\_df_42_01_spacefox
save=resources/graphics_output_directory
ascii=resources/ascii.config
verbose=True

[Button]

Hm. The easiest way for me to debug this is if you would upload your run.config, bamm.log, missing.log, your spacefox directory and your target directory to dffd so I can look around directly instead of asking you "What does bamm.log say? What are the files in each directory?" etc.

[Button]

Hey TheDorf,

I ran the old Spacefox with the new raws through BAMM and it modified the raws correctly. But, it reminded me that there's a bunch of stuff that isn't the raws, exactly, that Spacefox changes. So:

• Confirm that the raw modifications happened properly by looking at your output directory's raw/objects/creature_amphibians.txt . If it contains the string CREATURE_TILE:163 , the raw changes have been correctly applied.
• To make the Spacefox tileset available, manually copy the file Spacefox_16x16.png from data/art into data/art.
• To use the Spacefox creature graphics, copy the contents of raw/graphics into raw/graphics.
• To activate the Spacefox tileset, copy the file init.txt from data/init into data/init.

Additionally, I found a problem with the color and d_init graphics transfer, so I need to dig into that.

[TheDorf]

Hey TheDorf,

I ran the old Spacefox with the new raws through BAMM and it modified the raws correctly. But, it reminded me that there's a bunch of stuff that isn't the raws, exactly, that Spacefox changes. So:

• Confirm that the raw modifications happened properly by looking at your output directory's raw/objects/creature_amphibians.txt . If it contains the string CREATURE_TILE:163 , the raw changes have been correctly applied.
• To make the Spacefox tileset available, manually copy the file Spacefox_16x16.png from data/art into data/art.
• To use the Spacefox creature graphics, copy the contents of raw/graphics into raw/graphics.
• • To activate the Spacefox tileset, copy the file init.txt from data/init into data/init.
  
  Additionally, I found a problem with the color and d_init graphics transfer, so I need to dig into that.
  

Thanks, got it working now! This is freaking awesome, seeing as I'm not a huge fan of ASCII but still wanna play the latest versions of the game. [/list]

[Button]

Thanks, got it working now! This is freaking awesome, seeing as I'm not a huge fan of ASCII but still wanna play the latest versions of the game. [/list]

Thank you for helping me find problems with my utility!

Also I edited the previous post to fix the list. 

[PeridexisErrant]

A long-overdue PTW; I'm interested in the direction is taking and would love to get into PyLNP when it's ready.  The only requirement is that it works, and any complex logic must still work if fed an installed copy of the content, which it sounds like you're trying for anyway

Re: code - do you have java experience or similar?  Python programmers tend to say "Flat is better than nested", so I'd put all the source files directly in the src directory.  There's a bunch of other idiom that I'd be happy to talk you through and work on (some for clarity, others avoid bugs).  Interested in pull requests?

[Button]

A long-overdue PTW; I'm interested in the direction is taking and would love to get into PyLNP when it's ready.  The only requirement is that it works, and any complex logic must still work if fed an installed copy of the content, which it sounds like you're trying for anyway

I already use it to install graphics to the Modest Mod and variations - that's why I developed it, tbh . It's also been my testing ground, which is why I didn't find the color problems until just now.

Re: code - do you have java experience or similar?

Python programmers tend to say "Flat is better than nested", so I'd put all the source files directly in the src directory.

 

Yeah, I've been told before that my directory structure is a giveaway. You should see how nested the packages are at work. 5 directories deep minimum.

I actually went with what I thought would be the minimum level of nesting, given that I hoped to get the project into the LNP eventually. Surely with module names like 'config' and 'parsing' namespace conflicts are inevitable without packages? But I was also under the impression that module names are to be kept concise...

There's a bunch of other idiom that I'd be happy to talk you through and work on (some for clarity, others avoid bugs).  Interested in pull requests?

Sure! I've been using the PyDev plugin for Eclipse & its style checker, so the basic whitespace etc. requirements should be met, but I'm sure I'm making tons of harder-to-finger stylistic errors.

Incidentally, I really despise the line length limit. I like descriptive, unabbreviated variable names, and any kind of text parsing is going to use multiple loops. I know it's supposed to improve readability, but between forcing less-descriptive (thus less readable) variable names, encouraging the extraction of sub-methods for reasons other than "this makes logical sense as a separate function" (making the logic harder to follow/thus less readable, for me anyways) and the ubiquity of widescreen monitors (making long lines more readable than they were in The Old Days), it makes me want to scream. [/rant]

[PeridexisErrant]

I'll make a pull request and we can discuss this over on GitHub

[Button]

Thanks! I got through 2 of your 5ish commits last night and will continue working through them.

[milo christiansen]

I don't know if you've thought about it, but BAMM would make a great lint tool if you had rules that fully described all raw tags and how they relate to each other. It only took a few lines of code for me to add a lint mode to Rubble's tileset merger (which is basically a BAMM re-implementation), but of course the rules are harder (even with Rubble's extended format).

[Button]

I don't know if you've thought about it, but BAMM would make a great lint tool if you had rules that fully described all raw tags and how they relate to each other. It only took a few lines of code for me to add a lint mode to Rubble's tileset merger (which is basically a BAMM re-implementation), but of course the rules are harder (even with Rubble's extended format).

I hadn't thought about lint, but the full description of all raw tags etc. is the ultimate goal.

Unfortunately for BAMM, it's Modest Mod that people prod me for updates on. I should be able to get back to PeridexisErrant's suggestions Soon™, and after that, work on fixing the COLOR bug and expanding the merging capabilities to plant raws. (Chosen because I'm familiar with them and because Expanded Plants is still something I want to finish at some point.)

[milo christiansen]

Well, I am working of full rules, but they use the Rubble rule format extensions...

If you want to implement the extensions you can use my rules, or I could write a simple program to transform extended rules into the basic one-rule-per-line format BAMM uses (unless you changed the format and I never noticed).

Currently only inorganics and material templates (and by extension syndromes) have complete rules, but I will add more over time...

Note that my lint rules are for matching only, they use all '&' wildcards.