Bay 12 Games Forum

Hmm, good point thare.  I tried it, and yes creatures take on the same properties.  Aggrivating thing is the names use the creature colors, so it happens in the units list as well.

So, messing around for my tileset work led me to try out the "color values of 8-15 with non-zero brightness" thing to see what exactly "strange effects" means, as the wiki mentions it.  So I got this:


Each red rectangle highlights the next location of the two trees I singled out as I move the map around.  The rectangle representing the next space the pair is to move to within the DF window is half colored with the foreground color of the tile there.  When the tweaked-out, wierd tree with colors set to [10:13:1] moves to that location, the foreground color takes on the color of the tile that was there before the map moved and the background color (magenta) remains the same.  On load, the foreground color defaults to black.

Since the behavior is explainable and regular, I suggest adding this to the wiki. I thought it would be better to ask here first since the last time the colors discussion page was updated was Nov 2007.

Hmm...interesting idea.  And a big one; coding projects like this are complicated and error prone.  You thought seg-faults were bad?  Trying tracking these kind of seg-faults.  Sounds like a nightmare, but obviously people have done similar.

One thing that helps is Toady appears to be a reasonably accomplished programmer; the kind of changes that pop up on the dev log with regularity imply he has structured his code rather well, which I would assume might make a code injection easier, but by no means simple.

A second process would be much easier to handle, and since much of the research into the structure of DF memory, it may even be pretty straight forward to reverse engineer the map.  But here is the problem:

It is glutted, bloated, inelegant, and hackish.  Granted, the very nature of Modding, especially in the good-ol' days, is cracking the game code.  How easy the developer makes this is up to them, and the mere fact that there is enough nerdom on this forum alone to allow things like Dwarf Manager and 3Dwarf to even exist is a testament to both Toady and the community.

But an exterior program spying on the DF memory so it can render a "nicer" 3D or psuedo 3D GUI in real time I don't think helps the game itself much.  Yes, it is cool.  Yes I use 3Dwarf, yes I speak the graces of an ASCII art GUI while at the same time grinding away at graphics sets and tilesets to make the GUI look "nice," but that is because I am a geek.  At the end of the day, it is just a PSD file, just an image that uses what the game already has and does.  Building a huge thing that augments the GUI by spying on the original is cool, but not necessary.  A better investment of our time would be to develop a document specifying what the 3D interface should be, after much discussion and work, and even some prototyping.  The major hurdle in any GUI design is the design phase and the research that goes into it, something that Toady can not do on his own because he simply doesn't have the man power. 

We get away with an all-keyboard interface because that makes sense to us, and the affordances we make as geeks make it okay that the hot key for a floodgate can be any of three different keys.  I think we can safely assume that a great majority of the DF community is used to command-line OS control and programming, including HTML.  This level of arcanity (hah, that should totally be a word) is okay because we are in the trenches dealing with it anyway.  Furthermore, a single developer for a game as complex as DF is not exactly the best person to design a GUI, because he is in the middle of it.  But he is the best person to implement it, especially since this is Toady's livelihood..

So my opinion is that any work in this area should be at least a thought experiment, at most an organized, concerted effort to figure out how the hell one would actually go about controlling a game that seems to be so well suited to 2d layers and not isometric slices.  That way the Bay12 Team has a good starting place at worst, a detailed design document at best.

So some updates. 

The typeface itself in action, along with my tinkered color scheme.

Barrels, crates, some of the soil/stone tiles in action.

The wall tiles in action.  Nothing no one has done before, but a nice set nonetheless.

I personally can not help; I have too many other programming/modding/life matters as is.  But I can offer some advice off-the bat.

You probably want to use Python, as it is user friendly and practically made for this application.  In fact, it is your best bet if you are inexperienced with scripting anything; the file reading API is robust enough and straight-foreward enough that you should be fine.

You will probably want to convert the data to a *.obj file.  Every piece of 3D software can open one because it is REALLY easy to parse.  You can read them yourself: a *.obj is in plain ASCII text.  BEWARE: *.obj is the native format of the defunct Wavefront programs (Maya was one), which means it was likely developed for UNIX type systems, which further means that the ASCII character used for a new line in the file may be simply 'line feed,' code point 10, rather than the Windows use of Carriage Return then Line Feed, codes 13 then 10.  This might screw up your parsing.

jaked122, Python uses C++ syntax except indentation actually means something: no braces or parentheses.  Highlights include implicit typing, garbage collection, and I am pretty sure pass by reference.  The data types are all documented as to their representation in the C++ implementation of the run-time environment.  Assuming you write neat code, Python would not actually be a problem for you.  I mean, C++ has arcane things that are more confusing than Python, what with templates and inline and two kinds of bloody strings... Until you get into some nitty-gritty things that the average user doesn't and this scripting project wouldn't touch upon, Python is easy to pick up.  So if you want to help SolarShado, you are more than capable.

Would it be possible to assign borrows in areas you haven't mined out yet?  For instance, let's say that I want to find a magma pipe which I know is on the map, but it's quite a way away from my main fort.  Could I assign a big borrow in an area where I want to dig, and get haulers to take food/ booze there for the miners?  It would be preferable to have unskilled haulers running back and forth to the mining area than my miners spending all their time running back to eat/ drink.

I am pretty sure he mentioned that you could assign a burrow to an area with a mining designation so that only your legendary miners would mine it, if it has a vein of something.

Which means implicitly, yes.

Wow...I really can't wait.  When DF is done completely, whenever that happens, it might just be the best game its genre.

Yes, even though it is kinda the only game in its genre...

Alert status is gonna kick so much butt; hell, with that kind of system, you could REALLY organize everything.

Here's a question: will alert statuses have control over other things, like could I make an alert status called "Immigrants!" that causes all carpenters to build beds?  Or would that be more of a Manager feature?

I know this is not in this release, but if one could designate an area to mine within an alert status type object, that would be really cool.  As above, I set alert status to Immigrants! and that whole housing area I had designated for rooms only gets mined NOW, as it is part of the alert status.

Similar area: Alert Status adds "Pull Lever" tasks to certain diabolical SDT-sensitive levers?  That one would be REALLY useful and make up for anything lacking in the Alert status this time around.