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 - Astarch

Pages: [1] 2 3
1
DF General Discussion / Re: Future of the Fortress
« on: January 31, 2015, 03:54:34 am »
Quote from: GreenScape
Have you switched to c++11/14? How much did it make a coding easier?

I don't know about the 14 one, but if I remember, 11 had the auto keyword, which I thought was very useful.  I didn't find anything to do with the other 11 features that I recall, like the lambda stuff.

14 was mostly minor cleanup, changes to constexpr etc...

The simplest way lambdas are useful is that you can use the functions in <algorithms> without needing to add tons of boilerplate.

c++11 has a few other features that don't really necessitate a massive rewrite, the explicit nullptr to replace NULL, range based for loops:
Code: [Select]
for (auto& thing : someContainer){foo(thing);}static assert if you do any metaprogramming, technically not needing to put a space between each > when nesting templates is a c++11 feature that was added really early. Stuff that is nice but might require rewriting old code is move constructors, smart pointers, and initializer lists.

Quote from: GreenScape
Have you switched to c++11/14? How much did it make a coding easier?

I don't know about the 14 one, but if I remember, 11 had the auto keyword, which I thought was very useful.  I didn't find anything to do with the other 11 features that I recall, like the lambda stuff.
C++14 mostly works a few kinks out of C++11 -- little fixes and enhancements to the stuff that didn't even exist before. If you like auto, one thing of note is that in C++14 auto works for function return types (not to be confused with writing auto before the function name in order to write the return type after, which was already in C++11 for similar yet different reasons). I also recommend, even in C++11, becoming passingly familiar with decltype, which can be used to get auto-like effects (of tying a type to a variable rather than repeating the type explicitly) in some situations where auto wouldn't work.

C++11 auto/decltype function signatures are a huge pain in the ass and probably aren't worth it if you're not doing a lot of generic programming, which I suspect is not going on in DF. C++14 auto function signatures are nice, but I don't know if Toady is using new enough compilers for them.

Quote
As for lambdas, as far as I can tell they're mostly to help support functional programming composability styles -- sort of thing you'd find useful to no end if you came from a Haskell background, but it's an entirely different mindset with its own pros and cons...

Toady's an algebraist isn't he? I bet he'd enjoy Haskell.

2
Finally we can have a multi-monitor DF setup.

3
Is the plan to only offer a dfhack integrated version now that it's working with the 40.* series, or will there also be a non-dfhack version maintained?

4
Utilities and 3rd Party Applications / Re: DFHack 0.40.08-r2
« on: August 27, 2014, 08:48:12 pm »
I had the bright idea to convert .dfmap files to .pngs so people could use them with the various blueprint utilities, but mapexport isn't showing up in the list of plugins when I run dfhack. The last commit to it is over two years old, has it been discontinued?

5
DF Suggestions / Re: More robust food industry
« on: July 12, 2014, 11:17:54 pm »
I think a nutrition implementation might add too much micromanagement to be feasible.

Lack of any real scarcity is a problem, having vermin and grazers go after crops might help a little, but dwarf farms are able to be placed in much safer locations that real world farms so I dunno how much toady can realistically do in that area.

6
DF Suggestions / Re: More robust food industry
« on: July 12, 2014, 09:36:49 pm »
Something else I forgot to put in: Portion sizes. It's pretty weird that a dwarf gets as much sustenance from a single artichoke heart as they do from a dragon roast.

7
DF Suggestions / Re: More robust food industry
« on: July 12, 2014, 02:47:10 pm »
Just FYI, most of these can be modded. (Incidentally, I am planning to do most of them when I understand plants a bit more in the new version and things have settled down.) I'm not saying that's a reason for Toady not to consider them. Just letting you know that you don't have to wait around for all of these necessarily. Anyway:

(1) Preservation at the very least should definitely be in the default game.
(6) Also absolutely occasionally diseased water should be in the default game. This is actually much easier than a food rework - Toady would just had to add some extra types of contaminants to natural water bodies with procedurally generated syndromes. Which he already has coded for weird rain in terrifying biomes, and he also has contaminants coded in water (mud, salt, etc.). However, it is a myth that nobody drank water in the middle ages, or that doing so is just always dangerous or whatever. People who could afford it would drink beer more often, but it was simply too expensive for everybody to. It would probably be most realistic to have coin flips for which water sources in game are considered contaminated, with higher likelihoods for downstream and for standing water. Possibly ALSO a coin flip for every drink. So for instance, something like "Stangant water = 100% contaminated. Brooks = 25%, rivers 75%. Aquifers can still pass salt and maybe toxins or even viruses depending on how porous the rock is, so maybe 20%? Whatever, something like that.  Then also like 1-2% per drink on top of that (sometimes a random animal dies or something upstream now and then). This would model reality pretty well, with poor desperate people able to get by, but it being best to have preservable drinks, and some areas simply being contaminated, period.
(5) Yes, it should require water as an ingredient. Really most things in the game should require water... though if so there would need to be a much better system in place for making water reactions way less annoying. How about: either a bucket of water in the reaction OR you can build it over a water source and not need it, just like magma forges work?


(4) Yeah probably would be nice. This one is completely trivial to modify yourself, though. Just go into the "plants_standard" and "plants_garden" etc. raws and find the "alcohol" material definitions, which will include the name of the booze. You can just write in whatever else you want, and have your turnip vodka and whatnot.

Random other comments:
-- Hops are not just for flavor, or even mainly for flavor. They were originally used for their strong preservative qualities, considering that "small beer" was only a couple of percent alcohol at most, which wasn't enough to guarantee clean long term storable drink by itself. 1-2% alcohol + hops is much more stable.  Wines and spirits would not require these additional preservatives.
--Stills seem like they should require fuel as well, at least for some things, maybe all (possibly even magma stills as an option. Seriously). Even for just beers, you generally boil the wort prior to actually beginning fermentation, whether wild or cultured yeast are used, at least in modern times. And definitely, of course, distilled things.  For wine and for medieval beer, I don't know if they actually boiled prior to fermenting or not. Might be worth looking up.

4) Yeah, I'm actually doing this right now. Just because a change is trivial to mod in doesn't mean it shouldn't be added to the main game though.

Some of this can be modded in the current game, but only to an extent. I can make a workshop that combines the correct ingredients to produce bread or mayonnaise or whatever, but I won't be able to have my dwarves use those items correctly.

8
DF Suggestions / More robust food industry
« on: July 11, 2014, 09:29:39 pm »
This seems like an appropriate time to start talking about changes to the food industry, since the latest release added a ton of new plants.
Not addressed here are issues like food being too valuable, which should in theory be fixed when trade goods become valued based on availability.

In general what I'd like to see:

1) A bit more work done with spoilage vs. preserving food. Fortress mode has some weirdness with how quickly time passes, but in general it would be nice if we could cure, smoke, pickle, or otherwise preserve raw food, and had a good reason to do so.

2) Intermediate foods. We already have a bit of this in that we can press nuts and mill grains, but I want to bake bread and make mayonnaise.

3) Recipes. Obviously if we have intermediate foods we need foods made from those, and while a mayonnaise roast is nicely surreal, I really want to make my fortune exporting high quality sandwiches.

4) Maybe have some drink names besides <plant name> beer/wine.

5) More involved brewing in general, require other materials like water and hops, maybe stills need to have some number of barrels on hand just to brew things in, and those barrels need to be swapped out periodically, dwarves with preferences for booze brewed in barrels of certain materials, hipster dwarves who only drink dwarfish microbrews etc...

6) Probably beyond the scope of a food rework, but historically booze has been a preferred beverage because plain water was unsafe to drink. Something with diseases in certain biomes would be interesting, and add an additional penalty for running out of booze.

7) Skin/Hair Care. What's the point in having all these new nuts if my dwarves can't massage the oils into their lustrous beards?

9
DF Dwarf Mode Discussion / Re: First Impressions .40.01
« on: July 07, 2014, 11:34:45 pm »
I did a regular embark on a heavily forested site with a brook adjacent to some pretty shear mountains. Everything looked pretty normal until some time passed and the map EXPLODED with cottongrass, garlic, rhubarb, lentils, chicory, spinach, all sorts of plantlife. Haven't figured out how to do anything with the cotton yet, but my dwarves will have a pretty diverse diet at least.

And extremely smooth poops.

10

An embark rectangle of 2x2 gives a fortress size of 96x96 pixels. As far as I know the max an embark rectangle could possibly be is 16x16 or 768x768 pixels. I can't see a reason for making an image wider than 768 pixels.

It's not exactly a likely scenario to exceed that size, but some people do like to have padding around their actual blueprint.

Realistically the average user is not going to attempt to pass in an image that is too large to handle(for starters, they'd have trouble creating that image on the same computer) so you can probably get away with having no restrictions, but have a really big image trigger a warning that it might run slowly.

11
Looks nice! Some of the restrictions you have are weird though, why are you limited to 64 colors if the user is required to use 32bit or higher color? Is this only for the dig phase? How are you storing your color selections internally? If you're using C# it should be pretty easy to save them to a file that the user can edit by hand if they want to do something more complex.


I wrote my own image to blueprint converter a while ago, if you're looking to expand on what you've done so far feel free to take a look, it's open source.
http://dffd.wimbli.com/file.php?id=7994

12
Basically the game is at a point where most changes have a big ripple effect in the codebase, so a lot of relatively minor stuff will end up taking several days or even weeks to implement. Since Toady doesn't really want to put out biweekly updates with like, three changes, we get updates roughly once a year or so.

13
When I stopped playing for a couple months and was able to resume without looking anything up.

14
Small update:

FIXED incorrectly using a comma as a separator when quickfort expected a semicolon.
CHANGED alias.json now contains aliases for most common commands.
CHANGED you can now specify a config file with the --config=PATH_TO_FILE flag.


Hey guys, I've been really annoyed with trying to build quickfort blueprints by hand, and I don't particularly like chromafort, so I decided that as part of teaching myself Haskell I'd build my own blueprint generator.

dorfCAD will generate all four quickfort phases from a single image (or a list of images, if you want to get fancy), allowing you to easily lay out your fortress visually.

Here's the README
Spoiler (click to show/hide)

The executable, along with an example using the windmill villas from the wiki, is here: http://dffd.wimbli.com/file.php?id=7994

The github page is here: https://github.com/Hrothen/dorfCAD

The executable on dffd is for windows machines, if you're running something else you'll need to compile from source, which is kind of a pain if you don't already have the Haskell platform installed, sorry :(

15
Awesome, thanks.

Pages: [1] 2 3