Print

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

[ACE91]

Okay, somehow all of this talk about framerate and optimization has hijacked my thread. That wasn't even the point. As far as I know, there won't be a significant slowdown from the changes listed in this suggestion. Profit, you seem to be really ticked by DF's slowness, but if you want to complain about it please start your own thread.

[profit]

Okay, somehow all of this talk about framerate and optimization has hijacked my thread. That wasn't even the point. As far as I know, there won't be a significant slowdown from the changes listed in this suggestion. Profit, you seem to be really ticked by DF's slowness, but if you want to complain about it please start your own thread.

You are right I am ticked off about it's slowness..  But... Hijacked?  You want to add more calculations to an already burdened system.  I find it highly relevant.

And since were on the subject, how do we know it WON'T massively slow things down.  I mean, if done right anything is possible it seems, but when so much has already been done that isn't right, why do you think it will become right all the sudden.

This is kinda like giving 700,000,000,000 Dollars to banks who cant hack it.  They have done things over and over and over the wrong way and now congress thinks they will do it right? (LOL Its actually unraveling already only 78 days after they spent close to a trillion dollars)

*note to self:Might be using too many government metaphors lately, but its hard to find another group of people that screw up so often that everyone understands who I am talking about.

[ACE91]

This is kinda like giving 700,000,000,000 Dollars to banks who cant hack it.  They have done things over and over and over the wrong way and now congress thinks they will do it right? (LOL Its actually unraveling already only 78 days after they spent close to a trillion dollars)

At least there's something I agree with you on.

Certainly, this suggestion could end up making the game slower. Then again, it could even make it faster, because tiles would be limited to 10 objects instead of the infinite objects that can be placed in a tile now. We really don't know, and getting paranoid about the fact that it might cause slowdown does seem an awful lot like derailing the thread.

[profit]

A limit will also cause slowdown because of the limit checking that must go on.

Unless item themselves are limited in some fashion, just limiting the number of items per tile will not speed it up.

Derailing the thread would be if I started talking about Dwarfs with Longer legs or something.   This is a genuine concern when you start adding occupancy to a massive number of tiles.

There is no MIGHT to this, its merely how much slow down it will cause and how extreme it will be.  Perhaps the optimists are right and we will never notice it because its less than .0001% of the time taken in simulation core the game.  History however does not prove this likely and I expect this will add a noticeable slowdown in certain situations if for some reason it was implemented.

As an example..  a fairly low number of jobs are created when you designate a bit of forest to be cut, but quite often it can cause significant hesitation if you have a couple wood cutters.  If this was programmed ideally, it would be unnoticeable, but the real world performance shows even what amounts to probably under 100 additional calls for calculation(obviously the number of calculations themselves must run in the billions to delay a machine for a second but the game operations its probably less than 100) can cause a significant amount of lag.

[Impaler[WrG]]

Besides, useless fluff when the core is broken.

I completely concur with your sentiment that DF is getting way too much 'fluff' when far more basic issues are not being addressed, though I tend to put the focus on the UI and broken game play elements (Fish Dissector!?) over the speed optimizations.

But your still out of your league when it comes to addressing the CPU cost of features and you have indeed thread-jacked here over your unfounded assumption that the OP suggestion is CPU intensive.  We know the game ALREADY has some means to limit the number of items stored in bins and applying similar rules to empty tiles is not going to do jack to the game speed.  The ability to have more fluid types probably dose present a challenge but 1) its already in the design plans so presumably Toady knows how to do it 2) We don't know enough about the fluid code to say how CPU intensive it will be.

[profit]

Besides, useless fluff when the core is broken.

I completely concur with your sentiment that DF is getting way too much 'fluff' when far more basic issues are not being addressed, though I tend to put the focus on the UI and broken game play elements (Fish Dissector!?) over the speed optimizations.

But your still out of your league when it comes to addressing the CPU cost of features and you have indeed thread-jacked here over your unfounded assumption that the OP suggestion is CPU intensive.  We know the game ALREADY has some means to limit the number of items stored in bins and applying similar rules to empty tiles is not going to do jack to the game speed.  The ability to have more fluid types probably dose present a challenge but 1) its already in the design plans so presumably Toady knows how to do it 2) We don't know enough about the fluid code to say how CPU intensive it will be.

Moving stuff to bins IS INDEED cpu intensive as well, but I do not know if it is the path finding code for the dwarves or the actual bin logic though. So, now add possibly thousand more bin logic code calls into the pile and it is founded although I still admit it might be another part of Dwarf fortress and not the bin logic since I do not know how to or care to test them separately. 

And your right, I probably am out of my league, I only repair programs I very rarely write them anymore, and fixing bugs is just time consuming you do not need to have a mad amount of programming skills to do it, but still, based on what I see and how I see dwarf fortress working this has mad potential to cause massive grief.

But in any event I can now see that I have monopolized this thread a bit, and there are hundreds of others that equally deserve attention for the fact they would cause a significant amount of additional computations.   

Now... to bring to the light the dark side of that other fluff!!!!

[Draco18s]

Your flow suggestion won't work.

What happens when a dwarven wine flow and a goblin blood flow meet?

What happens when that flow meets water flow?

What happens when THAT flow meets a swamp whiskey flow?

What happens when that meets an orange juice flow?

What happens if I dump magma on top?

[Footkerchief]

Responding directly to the OP: your stacking ideas won't work.  If there's a max size for stacks, it has to be item-dependent for small items like coins and bolts.  Items spilling into adjacent tiles is an interesting idea, but there needs to be some distinction between deliberately stacked items (don't spill) and carelessly dropped items (do spill).

Restacking also has some complexities that you might not have considered -- Toady had some posts about it a while back.

combine stacks / better stack handling
-- this has been a problem since before the first public release, and the two ideas were basically to actually do it and to fake doing it via interface presentation of item lists etc.  Actually combining items would virtually require losing information, or you'd almost never do it (most items carry a lot of info), so I've grown to dislike this option.  The other option is to make the player think its happening more or less, and that's fairly easy in the interface lists.  The problem comes with jobs -- dwarves need to learn how to use multiple item stacks and consider it in all of their thoughts, which makes it sort of a pervasive rewrite.  As with job priorities, just something I haven't jumped into, but definitely there to be done.

Coins have their coin batch index (year for dwarves) and the material, but there's also ownership, contaminants, temperature, damage, age, storage information, maker id, flags based on if your fort owns/made it, melt/dump/forbid/hide designations, job information...  and probably more.  Some of it can be scrapped or otherwise dealt with, but it's not a triviality if you want to keep track of things.  Even if it checks all of these things and consolidates equal stacks (which would be rare -- or with age+maker id, virtually impossible), seeing it happen in some cases and not others with identically named objects would lead to false bug reports, I think.  Probably more profitable is addressing the main concerns in other ways -- getting dwarves to grab all the bolt stacks they need when they go to get a one bolt stack or making coins work in a sensible fashion don't really depend on stacking so much.  Increased CPU drag from broken stacks is probably the main thing that can't be dodged without some direct handling, and I'm leaning toward not suppressing the information by using some extra objects (could use the same ones as the interface would I guess, though there are all sorts of ways to think about it).

This is roughly what I meant by "extra objects", except for the "just" part.  The main point is that it's not only an interface problem.  If items are potentially contained in fake stack items, all the job handling needs to be revised to support that.  It's a bit less of a pain if you restrict to only coins or bolts say, but there are still things to be considered.  Take bolts for example.  Your guy wants to equip some.  First it needs to recognize the container as a valid ammo object.  Depending on exactly what you choose to stack, some members might not be as eligible as others -- what if some in the stack were forbidden, or tasked for a job, prior to stack formation, for example?  Those cases would need to be disallowed or handled.  Then the equipment checker needs to realize he's got the bolts when he places the container in his quiver.  Not so bad, possibly handled by current code, but something to check.  Now he wants to fire a bolt -- shooting needs to be rewritten to support bolts in the fake objects.  Sort of a piece of the quiver code already, maybe nothing needs to be touched at all, but takes some checking and testing.  There are side issues like valuations and stocks screen stuff, which might be handled already, and other thises and thats (environmental functions would need to be taught about fake containers -- rain for example should get the bolts wet, but currently there's no mechanism for jumping through a container on the ground to get the inside stuff wet, I think, since containers are generally real -- not hard, but yet another issue), as well as any applicable storage jobs, which run into some of the first problems I mentioned.  As you get to other objects, like food, you inherit more difficulties (vermin need to see and realize that they can eat food in stacks for free, etc. etc.).  As far as I can tell, the problem is not super difficult, and a lot of the issues just need a nudge one way or the other, or no nudge at all, but there are a Lot of issues that turn this into a tedious and long haul.  There's generally more to do and check than people expect.

[PTTG??]

I talked a little about tile occupancy... let me see:

http://www.bay12games.com/forum/index.php?topic=5384.0

Though I think I have a better one that included calculation for things like brush and debris.

Ah! Here it is:

http://www.bay12games.com/forum/index.php?topic=19466.0

I liked that one.

[codezero]

After reading Toadys' posts footkerchief dragged up, there does seem to be a lot of work. But one idea that might work is to add a 4th dimension for item location. So to stack an item on a tile that's already occupied, the item goes to the space tile(x,y,z,n+1) where n is the amount of stuff previously stacked on that tile. So if Urist is looking for a stone and that stone is on x,y,z,5, he still just goes to x,y,z. Another variable would sum the total space used on the tile, and another for the n-counter.

loo(k)ing at the tile might show similar to the way construction material e(x)pansion does. Odds are that any x,y stockpile tile will contain similar stuff, so it might say:
gold coins(4000)
silver coins(2000)
and that expands to
500 Gold Coins(204)
500 Gold Coins(204)
(...)
500 Silver Coins(202)
etc..
Though the UI problems sound less inhibitive than the job/hauling mechanics, which this solution attempts to lessen.

Of course there's probably all sorts of problems with this way as well.

EDIT: similarly you could multiply the z level by 7 or 10 and only path to every 7th z level. that has the advantage of making a full tile walkable from 1 level up.

[Random832]

What happens when a dwarven wine flow and a goblin blood flow meet?

Add a teaspoon of goblin blood to a barrel of dwarven wine, and you get sewage. (kidding aside, the solution may be to have a flow type that's just "mixed fluids", maybe with a list of what materials it contains, associated with the entire flow [connected area])

I think the best solution for restacking, given all the variables involved, would be "virtual bins" - where you've got an actual list of items rather than a single item's information and a number, but those items are contained in a single item which is treated as a unit (until it's broken out by a dwarf who only needs two extras to have a full quiver)

You could have a single 'stack' of just plain "bolts" in a stockpile which contains [3] +steel bolts+ (a true stack), [2] -steel bolts- (another true stack, from a different batch), bronze bolt, Xbronze boltX - a dwarf takes [2] +steel bolts+ from the first stack to put in a quiver, leaving the 'stack' with +St+, [2]-St-, Bz, XBzX.

And, yeah, job handling has to be revised, but really job handling should be looking in all containers to any nesting depth anyway; how often have people here been frustrated that e.g. the smelter doesn't look in barrels?

[Felblood]

The stacking issues are going to have to get dealt with eventually, particularly with arrows and coins. I wouldn't mind a hack that just took care of arrows and coins, but eventually, you want to be able to work with stacks of anything.

Just being able to stack things that where once in the same stack would be worth it, though equalizing the temperature of the stack would be tricky. So long as all items are in the same state (don't stack melted coins with solid ones), you could average out the temps under most circumstances.

Dwarves shouldn't mix stacks of +steel arrows+ and -kobold bone arrows-. What if I want to seperate those into distinct stockpiles?

Eventually, of course, the stacking and possibly the fluids, will have to be re-written to accomodate things like fountains of beer and rivers of blood.

Determining if you've got a bloodflow contaminated with beer, or a beer flow contaminated with blood is both important, and non-trivial to implement.

That said, those things should probably be updated after, or in the same release as a lot of engine efficiency tweaks.

I consider the changes Toady is making a lot more than fluff, particularly the armor stands and worldgen stuff, but if he keeps adding more cool things, I'm not going to be able to play at all, pretty soon.

[Random832]

Dwarves shouldn't mix stacks of +steel arrows+ and -kobold bone arrows-. What if I want to seperate those into distinct stockpiles?

Then make separate stockpiles for them, separated by quality, material, or both. Nothing in my proposal is stopping you

[Felblood]

What would such a stack display as? "Mixed bolts"

Stack Id and Brem's plump helmets together and that's great, but there's no reason for plump helmets to stack with dimple cups.

I'd like to see -steel bolts- stack up, whether they're made by Urist or Cog, but I don't even want Urist's -steel bolts- to stack with Urist's +steel bolts+. This isn't exactly the same, but many of the same problems arise.

Stacked objects are supposed to be, for practical purposes, interchangeable. Nobody but Urist cares that he made those bolts, but Urist; we can't even tell he made them. Which bolts are actually being fired needs to be tracked, so we know who freaks out when his masterworks get broken, but it makes sense that we as the player don't know who made which ones(a fact that is only important if one of the dwarves in question is to dead to worry about his masterworks.). However, the quality and material of those bolts have distinct, concrete effects that need to be kept separate.

Put em in the same bin? Fine. Store them in the same quiver? Fine. Mix them in the same stack object? Why!?

Stack the bronze arrows next to the iron ones, or even in the same tile, but you don't need to merge the stacks. There should probably be an (O)ption for "Dwarves re-stack damaged arrows," since whether having inferior stuff mixed with new is worth it, is a matter of whether you have enough new stuff at the moment.

Why try to make a system that can somehow communicate to the player all the several types of items in a single stack, instead of making a stack for each type of item. That's more work for Toady and doesn't give us anything really useful back, when they could just be two sacks of similar bolts.

Moreover, how big should arrow stacks be allowed to get? You don't want one dwarf cramming every arrow in he fortress into his quiver.

Being able to reach inside artificial stacks and manually Melt/forbid individual true stacks (which would then fall out of the stack object) could be useful, if you late want to , for example, remove a damaged arrow that was re-stacked.

One point I'm not sure about is bone bolts of the same quality, but from different animals. should -kobold bone bolts- stack with -horse bone bolts-?

[Random832]

What would such a stack display as? "Mixed bolts"

"bolts"

I'd like to see -steel bolts- stack up, whether they're made by Urist or Cog, but I don't even want Urist's -steel bolts- to stack with Urist's +steel bolts+. This isn't exactly the same, but many of the same problems arise.

Stacked objects are supposed to be, for practical purposes, interchangeable.

Says who?

Put em in the same bin? Fine. Store them in the same quiver? Fine. Mix them in the same stack object? Why!?

Why not? There's no game effect except that they're on the same stockpile square and move as a unit when they're moving bolts from that stockpile to some other stockpile.

Moreover, how big should arrow stacks be allowed to get? You don't want one dwarf cramming every arrow in he fortress into his quiver.

Um, quivers would have a hard limit on the number of ARROWS, independently of the stack.

Being able to reach inside artificial stacks and manually Melt/forbid individual true stacks (which would then fall out of the stack object) could be useful, if you late want to , for example, remove a damaged arrow that was re-stacked.

Right - I thought this was implied in my proposal.