Bay 12 Games Forum

I don't know what to say about that?

Quote from: wags on January 11, 2018, 03:12:43 pm

Quote from: Brutaka001 on January 11, 2018, 01:23:59 pm

Speaking of civ-specific, is it possible to have different tileset dependant on the caste of the civilian? Like a merchant-caste dwarf or smith-caste?

That doesn't really make sense in Fortress mode. Could you please elaborate?

Ok my bad for sounding confusing as all hell. "Castes" in the meaning of the word that I am using, is the way Dwarf Therapist separates dorfs when you click the "caste" option instead of, say, migration wave or military status. In the Dwarves case, "castes" are the different guilds. Fisherman's guild, Mason's guild, Hunter's guild. In the case of the Kobolds, it's the different signs they are born under. Turtle, Eel, Dartfrog, Rat, etc.

I was just wondering if there was a way, by some sprite making magic voodoo, to distinguish these separations of Caste by visual imagery instead of using the broad racial tileset for each Dorf or kobold, and using DT or menus in game to determine caste.

No, caste specific graphics are not possible.

Hmmm I agree that generally speaking, with no additional scripting and no extreme game changing effects, No is the answer.  We basically can only do profession specific graphics.  but I did devise a way to disallow a skill from growing no matter the number of times its used by a particular caste, meaning that you could restrict all non fisherdwarf guild members from obtaining above dabbling skill level in fishing and then only fisherdwarf guild members would obtain fishing caste images.  Basically the caste displayed is based on the highest skill obtained.  You would have to apply similar restrictions to all skills and only open the skills for that specific caste, but its "doable",  understand that it also means that skills of the caste will only improve if they are of the ones not restricted. 

I can set both a max experience and a max skill rating, so you could even have "sub castes" and require those sub castes to re apply to the next caste level, or in other cases, let them "evolve" like a pokemon game as they gain enough skill to obtain the next caste.  So you could have say this:

1. Peasants - starting caste that all the members of a society are forced into ( I can check for little ones and enforce a strict adherence to this so that all members under age X are peasant caste
2. Apprentice {guild} - entry level member only can gain 5 ratings max in the skills of the group. (or even 5 ratings max across all skills of the group, lol).
3. Journeyman {guild} - 10 ratings
4. experienced {guild} - 15 ratings
5. master {guild} - 20 ratings

additionally I could for the support of other skills allow non guild skills up to say 1/2 the guild skills. so they could never obtain it as their title, but they could support non guild related skill tasks.

Its something I played with for a bit a couple of months back.

There are a few creatures that appear in more than one file... they are all independently named internally, but may appear with the same name in game.

Makeown has been buggy for awhile.  May have adverse affects.

Either Dwarf Therapist is saying weird things, or the castes are broken. Latest version.

Spoiler (click to show/hide)

As you can see it's a guard dwarf but at the bottom it says that he gains significant xp boost for things he shouldn't.

Update your dwarf therapist to the lates version by clemente.  The one packaged here has not been updated and shows errors.

I can answer that.  masterworks has minimal FPS increasers, primarily DFHack item removers and item destroying reducing buildings such as the crematory, along with buildings to accomplish functions that normally reduce fps like the magma wells instead of using pump stacks.  Additionally mass creation allowing raw resources to be pushed into large batches of items through everything from Modest Mod inclusions and batch shops, all designed to make the game faster as the need for multiple jobs to accomplish the same task are reduced.  Other additions such as colored bricks and usage of blocks to make furniture means reduced mining and decreased rock needs for a sustained fortress.

all and all its not the mods you have that determine FPS.  Its primarily the complexity of the fortress, size of embark, age and size of the world, number of civs active in the world, etc.  The number of units and the number of jobs currently waiting to be completed also has a huge impact on a map.  As I have debugged many maps, the worst offenses are:
setting 1000+ stone to be smoothed,
setting every tree on a map to bee chopped,
digging out multiple (3 floor plus 100x100 plus) large chambers,
opening up the caverns and hell (which never made sense to me they were always open just invisible, suddenly they are a problem when you make them visible),
too many jobs not enough workers,
Fire,
Magma pumped to the surface,
Water dropping any distance,
mist, steam, miasma, any other form of gaseous flow,
overtly spread splatter including raining blood etc.
too many units whether idle or not.

and that last one is the worst problem... generally speaking if 50 units drop your fps from 100 to 50; 100 units will drop your fps to 25; 150 units will drop your fps to 10.  and that includes all units, including the pets, attacking armies, random creatures roaming around.   And some units cause more havoc to the FPS especially if they cause any of the stuff above that such as fire etc.  The only way to compensate is to have a system that works faster, more cpu power to do the path computation faster.  everything else, item count etc is minor, you can fix that.  I work on a laptop on DF all the time, It doesn't matter how much other stuff I'm doing at any moment.  The FPS is going to decline at a steady rate with the increase of units on any given map. i.e. deal with the other stuff the best you can, but it wont matter if you are getting to the 10s by the time you hit 100 units, it wont matter if you have 100 items or 100 million items.  Unit FPS reduction is the biggest frame killer once you avoid the other stuff.

Quote from: Amostubal on December 23, 2017, 09:02:53 am

the + still needs some sort of appearance of providing turns as a dwarf ordered to push across one will still make a turn on it.  the new + looks like the N-S E-W are forced and turning isn't allowed.

I think, in real life, it does not seem that two railways that intersect at 90 degrees have normal fork with the possibility of changing the direction of motion - there is always a rather confusing denouement - but I'm not a specialist railroader, I can be wrong.

How in DF works + fork have no idea - never used rails.

Аnyway, I drew what you described. Previous post updated.

Spoiler: Track + forks (click to show/hide)

number 3 is more like how it functions, it can allow a dwarf to "guide" it but the implied direction of movement in "pushed" or "ride" mode is straight unless a wall is present.

how carts work:
lets say you have this setup:
1---+---3
    |
    2
where 1,2,3 are defined track route stops.
If a dwarf is ordered to push|ride at point 1 he will give the cart a shove and the cart wont turn at the + and continue until it reaches 3(and if there is no wall beyond 3 and no actual track stop building that can break it, it wont stop it will just keep going).  At that point a dwarf will retrieve the cart and drag it to point 2 along the straightest route...even over no track.  if 2 is also a push|ride he would then shove it and it would continue north past the + if there is no wall, otherwise stopping at the + if there is a wall past it.  At which point the dwarf drags it to point 3 and if it was the same thing... at least then the cart would reach point 1 and hopefully there is a wall and it stops there and a dwarf doesn't have to drag it back to one.

If the dwarf is ordered to guide it, he would move it from 1 to 2 then 2 to 3 then 3 to 1(if 2 and 3 are guides too). at the + or T or any other turn he would make the appropriate turn needed to finish the path.  guided routes across connected track is the easiest to ensure completion.  Of course this means a dwarf has to follow the cart everywhere.

Fun is when you design complex automated cart systems with ejectors, impulse ramps, decelerator rooms, dumping track stops, and all the other fun stuff that one can build.  at which point the + T intersections are the least useful unless they are built on ramps.  Even more fun is when you design it with riders and make it into a roller coaster and try not loose your passenger as you move it through system... The greatest fun is when you use it to eject material in complex assault systems that allow you to grapeshot the tavern with a cart full of daggers...

The main point of carts and tracks is to remember that shoved carts will follow curves only when they are 1-in-1-out or if its on a ramp and only 1 out is to the lower floor.  The cart will remain on the track as long as its under derailment speed(which without impulses or other ramp tracks is easy) or there is a wall blocking the forward movement(and thus also blocking derailment), forcing the cart to stay on the track and seek a single lower exit from the tile.  additionally track tiles main purpose is to reduce the friction of the cart against the surface.

so if a cart is moving at decent speed and reaches a set of tracks that look like this:
----|||||||+++----
It will move across these as if they as a straight line.  even if a dwarf is told to guide across these... the dwarf will get confused and just start dragging the cart across the straight distance... which means he will drag across these and the friction is less anyway on these tiles... well as long as there isn't a straighter path available that circumvents these tiles,such as this:
+------------------1
|WWWWWWWWWWWWWWWWW   WWWW - walls with a gap in it. and the track doesn't connect so the dwarf will just drag from 1 to 2 through the gap.
+----|||||||+++----2

I could build some actual track images and explain some of this a lot better with images.  but I think that covers what we was discussing.