Bay 12 Games Forum

Quote from: Urist Tilaturist on March 16, 2017, 03:34:48 pm

Fire lances are the oldest gunpowder weapons, but they're far from the only ones which would qualify at a late medieval technology level. In order to cut off at fire lances you'd be putting the date at 1100, not 1400, so goodbye full plate armour and 2 hand swords.

I actually wouldn't mind an early medieval mode with maille armour and 1 hand swords and spears. Viking age dwarves.

Again, I said fire lances instead of later gunpowder weapons because: Toady already messed up by putting the cutoff date well after the advent of gunpowder weapons. Giving an example from the 1100s (that's also a lot easier to balance in a fantasy setting) means I've set my expectations a lot lower. 3:

This launched me into an interesting evening of research on wikipedia. 

I believe the "1400" choice was not based on gunpowder but on prevalence of cannons.  This is probably because Toady wants humans to be building tall flat walls (which is the standard fantasy-castle trope), and real humans stopped building like that because artillery chews them up.  While various gunpowder toys and weapons were available far earlier, you don't start seeing sieges decided by artillery until the 15th century.  The notable fall of Constantinople is a famous example. 

Another point to note is that De Re Aedificatoria (written between 1443 and 1452) contains a section on walls and fortifications (book iv, chap iv), with a bunch of advice on how to build nice standard curtain walls (indicating they were still seen as useful at the time), but with this little tidbit, which is arguably the starting point for star-fortifications:

In my Opinion one very
good Way of Building a strong Wall, capable
to stand the Shocks of Engines, is this: make tri−
angular Projections out from the naked of the
Wall, with one Angle facing the Enemy, at the
Distance of every ten Cubits, and turn Arches
from one Projection to the other; then fill up the
Vacancies between them with Straw and Earth,
well rammed down together. By this Means
the Force and Violence of the Shocks of the
Engines, will be deadened by the Softness of the
Earth, and the Wall will not be weakned by
the Battery, only here and there, and those
small Breaches, or rather Holes, that are made
in it, will presently be stopt up again.

TL;DR: The year 1400 cutoff was probably chosen because Toady wanted there to be castles, and people stopped building like that around that time because of cannons. 

OK wow that is a bunch of words.  I'll try to give some answers here (though honestly I only skimmed). 

Yes, history tends to get very rowdy after worldgen.  There are two reasons for this:

• Worldgen and the post-worldgen activities are modeled by completely separate mechanisms.  Ideally they would match up exactly but not everything that happens in worldgen can happen during play, and not everything in play can happen during worldgen.  The goal is that someday they will be indistinguishable, but it was only quite recently that there were any worldgen-like activities happening during play, so things are in a very very early stage.
• The world is intentionally more violent after worldgen, since otherwise there would likely be nothing for an adventrer to interact with.  Worldgen wars have a battle or two a year, and wars are frequently short-lived.  At that rate, no players would ever see any of the action.  Making the civilizations violent fixes this problem by making more stuff happen. 

I'm not sure there's a way to "fix" this for now, at least not without impoverishing worldgen as well.  Your best bet right now is probably to use some third-party tool to filter out irrelevant events.

I found a little wonkiness with Stonesense's creature sprites, ...

Ah, yeah if it can't find the top-level sprite, stonesense doesn't read the rest of that xml block because it assumes you've made a mistake and prints an error message, however it can still draw the initial sprite if there's enough information there to point it at an image file (this is why when people mess up their xml, they usually get naked dwarf spites). 

I think technically you still want to use the term "skin" when referring to the creature's body in the stonesense xml.  Stonesense looks up the bodypart by the bodypart name, not the TLCM_NOUN.  It should still get the correct color, since it does a case-wise lookup to figure out which color to use, since it is still actually called "skin" in the raws (TLCM just changes how it shows up in text boxes and descriptions I think).  If that doesn't work, open up the stonesense init and turn on debug mode, then use "v" to look at the creature in DF and place the DF/Stonesense cursor on the creature and you should get a detailed description of the known bodyparts and colors - so use whatever words it uses there in your xml.

Also, I think the "fail-over" behavior you're describing is just stonesense failing to find a bodypart, so if just defaults the value to the first bodypart, which just frequently happens to be skin.  Looking at it, I think it really should fail-out in that case rather than try to guess, since it confuses people more than anything. 

Let me know if that works - and if it doesn't please post the error message you got, since that can be helpful.

I have a little problem. Using DF0.34.11 and Stonesense that comes with DFHack r5.
When I make big screenshot (Ctrl+Shift+F5), it for some reason don't render everything past z-level 110 (11z-levels above ground). Here are screenshots, to illustrate the problem.

Spoiler (click to show/hide)

This is how it looks on Ctrl-Shift-F5-screenshot:


This is how the bridge looks in Stonesense window:


Windmill farm

Is there any way to fix it?

Try changing the number of z-levels you're using for normal stonesense rendering (larger is probably better, or maybe try just a single z-level) and take the shot again.  I remember it liked to cut off near the top of the sky sometimes.  (grr full-embark screenshot code always breaking!)

Progress on the trees is looking good!

@Dark_Tundra
I think that would be possible.  I haven't rummaged around too deeply in the sprite-directionality code, but as I recall it happens after buildings are loaded.  Bars and windows and the like would also probably make sense in the same context.  I'll take a look next time I'm down in those parts to see how much sense it makes.

---

Regarding the status of overlay-related things, progress is being made, though the time I have to put towards it is limited.  I have constructions now using a similar system to the one for designations.  Constructed tracks are handled by DF in a super strange way, but I'm pretty sure I got it all converted (reeeeeeeally long switch statement).  What that means is that all constructions and designations will be handled in the same way as regular tiles, so if somebody wants to draw different sprites for them or make them a different color or whatever they can (the main motivation for doing this was to not have to duplicate the track-drawing code). 

Next up is room-display (so you can see what's going on when you designate your dining hall or whatever), and then I need to figure out how multi-tile cursor stuff (like when you are plopping down constructions or buildings) happens.  I'm a little concerned about the cursor because I honestly have no idea how it is being handled, but hopefully it isn't buried too too deep.  There's more that needs doing after that, but those are the big show-stoppers that make the overlay unplayable in it's current state. 

Keeping at it.  Slowly.

@ easykiln, PeridexisErrant
Yeah, the intention is to have it be toggleable.  All the framework for doing that is present, since the overlay needs to switch off when you enter a menu screen already - I'll hook in a keybinding for toggling the overlay at some point.

In other news, after a couple situations where I did a bunch of work, then realized what I was doing wouldn't cover some of the cases that were needed, I've got a solution to the "how to display designations/constructions" thing that should be effective.  I've treated construction and designation as "materials" so all the configurable xml stuff that already exists can be applied easily to them.  Designations and constructions will alter the tiletype reported on the tile.  The display of constructions/designations is toggleable (default keybinding is 'd' right now).  I believe I've got everything including designated tracks working already, so that's the major one finished.  It shouldn't be too difficult to get the same handling for constructions. 

I still need to sort out how the building/construction/room placement cursor stuff works, but hopefully that won't be too bad. 

Hi there!

Go to the stonesense/terrain folder, and open index.txt.  Change the lines "Track_Floors_128.xml" and "Track_Ramps_128.xml" to "#Track_Floors_128.xml" and "#Track_Ramps_128.xml" ('#' at start of line tells the resource loader to ignore that line) and try starting up again.  You might have issues with creatures/index.txt as well (generally just comment out lines ending in _256 or _128 and you should be OK). 

Hope that helps!

Good news all round! Any chance that this could mean an interface breakthrough?

Well, I think the main "breakthrough" was made months ago when I worked out how to hijack the image buffer of the DF window.  From here on out making it actually useable in that form is just a lot of little stuff.  For example I started on designations today:

So far I have smoothing, engraving, digging/trees/plants and all the stairs/ramps sorted out, but track engraving designations are different.  Also need to test if fortification carving is in the same place as the other engraving/smoothing stuff.  Then we need to come up with a good way to display the information (the image above is the simplest placeholder to do, but is ugly). 

Anyway, it's a process.