Print

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

[Gorobay]

With TrueType fonts available, will DF be able to display non-ASCII characters? Specifically,—this has bothered me for a while—will accented characters now be capitalized correctly?

[SmileyMan]

If work on displaying strings is going on, any chance on taking the one-time hit to change to unicode?  Nice for us non-stateside peoples!  Plus, you know, more accents than you could shake a stick at, for those who want to mod in new languages...

[G-Flex]

Two different things:

- The proportional fonts. I've already talked that over with Toady, and he's fine with the proposed interface - as you guessed, there was already an "add this string to the output" function, which I'm just modifying. I'm fine with speaking authoritatively on that, as it's near-guaranteed to go in.

- Scheme UI builder. Not even discussed it with toady. Did I strike the wrong tone there, then? It's just an attempt to show him another way to do things, not something I expect would affect DF as such..

I apologize for being a little presumptuous/confrontational there. It wasn't called for.

Along with the in-game encyclopedia for new creatures, would it be possible (and useful vs above comments) to procedurally generate descriptions of what the various metals are good at?

Well, documentation is documentation, and we've obviously been lacking there.  Having random metals would allow for a natural improvement of the descriptions for the stock stuff, so maybe that would be a good ticket.  We got the reaction lists up for stone sometime in the past, and I guess it would be something like that, where it would be able to compare the value of metals.  I don't want it to display kPA values and stuff, but I guess it could display a list of the common metals and show where your dwarves think the metal/material in question fits in to the picture.

Isn't that basically how Moh's hardness scale works already?

If you're implying that the Mohs hardness scale would be good for judging material effectiveness, that isn't really the case. There's correlation there, but it's very far from absolute. In fact, often the hardest things are the most fragile (and for good reason).

If work on displaying strings is going on, any chance on taking the one-time hit to change to unicode?  Nice for us non-stateside peoples!  Plus, you know, more accents than you could shake a stick at, for those who want to mod in new languages...

This would be amazing. It has pretty neat implications for the future of the text display mode (if that sticks around) and graphics support, as well.

[Baughn]

No Unicode at the moment, sorry, but I suppose having truetype support in would make adding that a little easier in the future.

One potential problem is that I'm not removing the *old* string display code, so it wouldn't be possible to display uncode in all modes. Hm, but I suppose we could look at replacing the tileset as such with a fixed font, once the "full graphics support" goesin and it's reduced to just text.

I'll have to think about that some more later. It'd be a lot more work for Toady, too.

[Tormy]

No Unicode at the moment, sorry, but I suppose having truetype support in would make adding that a little easier in the future.

One potential problem is that I'm not removing the *old* string display code, so it wouldn't be possible to display uncode in all modes. Hm, but I suppose we could look at replacing the tileset as such with a fixed font, once the "full graphics support" goesin and it's reduced to just text.

I'll have to think about that some more later. It'd be a lot more work for Toady, too.

Eheh yeah, but it wasn't important for Toady ever. Hopefully he will end up separating txt/gfx eventually...'til than I play in ASCII mode, because I don't like the half-assed tilesets. [I am talking about the engine limitations, some of the tilesets are looking good. ]

[Mephansteras]

Toady, can you describe how the weapon sizes work in relation to the creature sizes? For example, I've seen dwarves happily pick up and use a modded in weapon one handed even though it has [TWO_HANDED:62500]

On a related note, it seems like all of the two-handed weapons are from the Dwarf/Elf/Goblin point of view. That two-handed sword could be wielded one-handed by even a smallish human. Same with Pikes, Great Axes, and Mauls. This seems a bit odd. Shouldn't the humans have some weapons that are two-handed for them?

[Tormy]

Toady, can you describe how the weapon sizes work in relation to the creature sizes? For example, I've seen dwarves happily pick up and use a modded in weapon one handed even though it has [TWO_HANDED:62500]

On a related note, it seems like all of the two-handed weapons are from the Dwarf/Elf/Goblin point of view. That two-handed sword could be wielded one-handed by even a smallish human. Same with Pikes, Great Axes, and Mauls. This seems a bit odd. Shouldn't the humans have some weapons that are two-handed for them?

Heh, as long as our dwarves can pick up and carry a wooden cage full of elephants, I am not complaining. ..but yeah I agree with you lads of course.

[SmileyMan]

One potential problem is that I'm not removing the *old* string display code, so it wouldn't be possible to display uncode in all modes. Hm, but I suppose we could look at replacing the tileset as such with a fixed font, once the "full graphics support" goesin and it's reduced to just text.

While it's not a "beautiful" solution, if you stored strings internally as UTF-8, and had the string display function check for a byte-order mark (U+FEFF, 0xEF,0xBB,0xBF in UTF-8) and if it doesn't find it, default to DF's modified CP437.  That way, the functions that call the string display could be upgraded piecemeal, rather than requiring a big bang approach.

Re-writing the language files etc. as UTF-8 encoded is easy, since I've already got a program that does it for the log files.

[Baughn]

You're right, that's more along the lines of a horrifying hack - but it does have the advantage of a clean upgrade path to non-hacky code later, by removing the lack-of-BOM special case.

I'll have to think about it some more. Come to think of it, is a BOM even allowed in utf-8?

[SmileyMan]

I'll have to think about it some more. Come to think of it, is a BOM even allowed in utf-8?

Ah, that depends on who you ask.  If you ask the Unicode Consortium, they say it's not necessary, since a stream is either valid UTF-8 or it isn't.  However, it's not illegal.  In DF, you could probably use some never-printed-as-text character as a marker instead, but you might as well use one that makes sense in a unicode context.

Effectively it's just a way of passing an additional parameter to the function (a Unicode/non-Unicode flag) without changing the function signature.

[Tabithda]

How will the new population rewrite affect cave dwellers like the kobolds? Will they get things like small hunting groups scattered around their caves and small raiding parties wandering around attacking unwary travelers, or are they just going to remain as they are right now?

[jfs]

While it's not a "beautiful" solution, if you stored strings internally as UTF-8, and had the string display function check for a byte-order mark (U+FEFF, 0xEF,0xBB,0xBF in UTF-8) and if it doesn't find it, default to DF's modified CP437.  That way, the functions that call the string display could be upgraded piecemeal, rather than requiring a big bang approach.

Re-writing the language files etc. as UTF-8 encoded is easy, since I've already got a program that does it for the log files.

How about converting all text to UTF-8 everywhere and using UTF-8 strings everywhere, and simply have a function that translates UTF-8 to CP437 for the cases that need it?
You could also implement a data file (init, raw or otherwise) that contains a translation table from Unicode to tile indexes. So you could map U+0041 to tile 204 if you really wanted to. This also creates a neater solution to the issue of advanced tilesets modifying the language files to remove accented characters: Instead just make accented character codepoints translate to the unaccented tile images.

[SmileyMan]

While it's not a "beautiful" solution, if you stored strings internally as UTF-8, and had the string display function check for a byte-order mark (U+FEFF, 0xEF,0xBB,0xBF in UTF-8) and if it doesn't find it, default to DF's modified CP437.  That way, the functions that call the string display could be upgraded piecemeal, rather than requiring a big bang approach.

Re-writing the language files etc. as UTF-8 encoded is easy, since I've already got a program that does it for the log files.

How about converting all text to UTF-8 everywhere and using UTF-8 strings everywhere, and simply have a function that translates UTF-8 to CP437 for the cases that need it?
You could also implement a data file (init, raw or otherwise) that contains a translation table from Unicode to tile indexes. So you could map U+0041 to tile 204 if you really wanted to. This also creates a neater solution to the issue of advanced tilesets modifying the language files to remove accented characters: Instead just make accented character codepoints translate to the unaccented tile images.

Well, I don't want to speak on his behalf, but I think Baughn's overriding principle is "make no extra work for Toady," which is why the idea for a function that works exactly the same for all the existing call points in Toady's code, but if at some point in the future he wants to try out a Unicode string or two, it's in there ready to go.

[Yobgod]

There are equations for acceleration on an inclined plane.

They aren't really needed for the discrete timescales you're dealing with.

All you really need is conservation of energy, lessened by friction.
So... set a value for kinetic energy lost to friction per tile rolled over and a value for kinetic energy gained per tile dropped. This is also nice since it would let you drop a boulder several z-levels to build up speed before it hits your ramp. Velocity is technically then related to the square root of the boulder's current kinetic energy, which indicates how many squares you move each step.

If you wanted to get slightly more fancy (and tone down speeds), count friction for a ramp as 1.5x that for a flat (approximating the square root of two for the longer surface).
If you wanted to get even more fancy, you could define the rolling/sliding friction for all the various floor surfaces (or all materials), so that the boulder would roll very quickly down your ironclad hallway, then quickly come to a stop when it hits that patch of sand.

The interesting (and harder to program) question is what happens when a fast rolling boulder hits a ramp up, or a sideways ramp. The easy solution would just ignore them and roll onwards, shedding energy when forced to go up, but it potentially sets things up for crazy Dwarven Marble Madness. 

[colinmarc]

Two questions!

How will sending out armies/raiding parties relate to embarking? Could you conceivably embark somewhere in the foothills of a mountain range and build a road going up into the mountains (by sending out teams of masons/miners), and then build your mountainhome in the peaks? What about the other way around - embarking in the mountains and building a road to make it accessible by caravan?

and... (alright, this is a bunch of questions)

Since it seems like trading/travel/marching will be more specific in the coming releases, will geography matter to a fortress? That is, if the only/best way through a big mountain range is this one pass, could building your fortress straddling the pass be strategically valuable as a way of intercepting caravans/armies? If trade happens overseas eventually, could being a major port matter? What about controlling a specific resource? Finally, what are your thoughts on territorial behavior - goblins being more likely to attack a fortress that embarks in 'their' mountains, for instance?


Thanks!