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

Pages: 1 2 [3] 4
31
DF Dwarf Mode Discussion / Re: Dwarves won't dig any further down?
« on: January 01, 2008, 05:03:00 pm »
*smacks forehead*  I had thought that I'd designated stairs, but. . . for some reason I hadn't.  I managed to do it right for every other level except that one. . .  IGNORE ME!  :(

32
DF Dwarf Mode Discussion / Re: Dwarves won't dig any further down?
« on: January 01, 2008, 04:54:00 pm »
The level they refuse to dig into is level 145.  I can '>' down to level 136, 19 levels below the surface (where the wagon was).

33
DF Dwarf Mode Discussion / Dwarves won't dig any further down?
« on: January 01, 2008, 04:36:00 pm »
My latest fortress happens to also be my most successful one.  I've lasted longer in the old 2d version, but I can't say I accomplished as much as I have in this fortress.  Unfortunately the game crashed and I lost the last couple seasons of my 3 year old fortress.

Anyway, I've been trying to dig deeper, but my dwarves refuse to.  I'm not really deep, yet.  I'm in the fourth level of the igneous intrusive layer and the next layer seems to have more olivine (which indicates more gabro, an igneous intrusive layer rock).  Of course, I have one level that has a combination of sedimentary and igneous intrusive rocks, so that next level might be a transition zone.

Is it a coincidence that my dwarves refuse to dig into the next geological layer or is there some other reason?  I know it's not that there's other work.  They've completed all other dig jobs and sit around idling until I designate something above that level.  If it helps, the deepest level in which my dwarves have actually inhabited (sorta. . . it's my tombs) is six levels above the problem level.

EDIT: Here's my region:

[ January 01, 2008: Message edited by: Ostsol ]


34
DF Dwarf Mode Discussion / Re: Fractal bedroom complex ideas
« on: December 30, 2007, 03:09:00 pm »
Here's the typical setup that I use:

Blue spots are doors, red are tables, brown are chairs, and yellow are stairs.  The entire space is 57 squares wide and has 128 2x3 bedrooms.  The dining room has seating for 48.  Arranged differently the dining room could seat more, but this setup is fairly aesthetically pleaing and dwarves don't eat all at the same time anyway.


35
quote:
Originally posted by wereboar:
<STRONG>excuse me for an unrelated question, but how do you make the tiles look square in windowed mode?</STRONG>

Use a character set with square characters.


36
That sounds about right for a large cave system. . .

37
DF Dwarf Mode Discussion / Re: Killing carp
« on: November 12, 2007, 12:17:00 pm »
quote:
Originally posted by DJ:
<STRONG>No it doesn't. At least not any worth mentioning. It also has a tiny mouth, so I just don't see how could a carp bite someone.</STRONG>

Pfft!  Next you'll tell us that elephant tusks aren't for skewering dwarves. . .   :roll:

[ November 12, 2007: Message edited by: Ostsol ]


38
I think Toady also mentioned an idea about sappers, basically allowing siegers to make their own tunnels right into your fortress, bypassing doors and traps entirely.

39
DF General Discussion / Re: Future of the Fortress 4
« on: June 08, 2008, 09:34:00 pm »
I was going to write a big post revisiting the issue of threading.  However, I think it suffices to say that it's not such a difficult issue anymore.  I spent today messing around with Intel's Threading Building Blocks (tbb) and found that it really is easy to use.  I modified a Fractal Brownian Motion (fBm) terrain generator to use tbb and was amazed by the results -- not just in performance, but in the possibilities of its use.

When most laymen or amateur programmings think of implementing threading into an application they tend to think of dividing the program into two or more major tasks.  For example, in a first person shooter one might think of one thread being devoted to rendering, one to physics, one input, one to AI, one to streaming new content, etc. . .  Intel's tbb has shown me that that line of thinking only scratches the surface.

I used tbb to thread each of the three loops in my fBm generator.  The first loop consists of a dozen iterations at most, while the second and third loops consisted of a thousand.  Normally I would never even have considered trying to split such loops into multiple threads.  How many iterations per thread?  How many threads should I have in total?  The answer depends on the platform and would normally require one to write a system to analyze the platform the program is running on.  Use too many threads and you bog down the system with context switches.  Use too little and you're not getting the most out of the hardware.  tbb figures this out for you.  It's easy and it works quite well.


40
DF General Discussion / Re: Beginning C++ programming
« on: May 19, 2008, 06:05:00 pm »
I recommend Python.  While it's not fast, it's an easy language to learn and forces you to learn good indentation style.  While the latter may not be particularily important to you, it sure helps if you ever want someone else to try and read your code.

On a related note:

Python also compiles down to a byte code.  The difference between this and Java is that when you actually run the code Java will compile again to whatever native code the platform uses.  This is known as a "just-in-time" (JIT) compiler.  The result is that Java should theoretically run just as fast as any natively compiled programming lanugage, like C/C++.  Any difference in speed is due to the efficiency of the compiler and the libraries.

Python, on the other hand, does not utilize any JIT compiler in the basic distribution.  Its byte code is interpretted by software, though there are instances where code can be as fast as natively compiled code.  This is most often with libaries written in C.

C# and other .NET langauges are similar to Java.  They compile to a platform-independant byte code (Common Intermediate Language [CIL]) and a JIT compiler is utilized during runtime.

There are distributions of Python that do take advantage of the JIT compilers in .NET and Java: IronPython and Jython, respectively.  For the basic distribution there's also a library called Psyco, which procides JIT compilation (though only on x86 platforms).


41
DF General Discussion / Re: Future of the Fortress
« on: September 03, 2007, 10:25:00 am »
It may be drawn as a bitmap character, but Curses doesn't allow what you are suggesting.  Curses simply provides a framework for building textbased interfaces with fixed-sized fonts.  What you are suggesting could not be done without either extensive modification to Curses itself, or abandoning Curses entirely.

[ September 03, 2007: Message edited by: Ostsol ]


42
DF General Discussion / Re: Future of the Fortress
« on: August 17, 2007, 11:31:00 pm »
LOL!  Sort of a bar-room brawl on a grand scale.

43
DF General Discussion / Re: Future of the Fortress
« on: July 25, 2007, 09:13:00 pm »
Another revisitation on threading in DF.  I recently noted Intel's http://threadingbuildingblocks.org/  via Slashdot.  It may be worth experimenting with. . .

44
DF General Discussion / Re: Future of the Fortress
« on: July 25, 2007, 08:54:00 pm »
Rewalling gives me images of dwarves reinacting "The Cask of Amontillado" with their nobles. . .  ;)

45
DF General Discussion / Re: Future of the Fortress
« on: July 06, 2007, 09:19:00 pm »
quote:
Originally posted by qwertyuiopas:
<STRONG>But with the Z axis, couldn't you just build down? There would be plenty of space.
So, even without a mountain, you might still be able to play.</STRONG>

If one could dig down into the bedrock that would be feasible.  However, if the water-table is above that, you'd constantly find your hole-in-the-ground filling with water.


Pages: 1 2 [3] 4