Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 8 9 [10]

Author Topic: Stacking and Hauling Improvements (optimization)  (Read 31382 times)

NW_Kohaku

  • Bay Watcher
  • [ETHIC:SCIENCE_FOR_FUN: REQUIRED]
    • View Profile
Re: Stacking and Hauling Improvements (optimization)
« Reply #135 on: May 30, 2012, 10:31:13 am »

Well it's Toady's decision anyway:) I think a lot of info is unimportant to store but i am not a developer of dwarf fortress:)

"Important" generally means "is used for something" (except for the engraving/improvement data, which is purely aesthetic, but still reasonably important, although I still don't think it's justified for coins,) so it's not likely to be changed.

Anyway, I've already said how you can keep every bit of data in a stack that could be held by items individually back in the front page, so there's no reason we can't stack.

Topic for discussion: 
Quote
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.

What would you say can be offloaded, converted to the stack info, or dumped.  Every one of those has to be one of the three.

Well, assuming I am correct in interpreting that "offloaded" means "it's got a pointer to manufacturing data" and "stack info" is "the stack applies this data to everything in the same stack", and "dumped" means "Screw it, we don't need to track this at all", then...

  • Coin batch index and material data - offload (Although possibly having some sort of generic "item type" data that would be stack data. That way, you don't have to search where the pointer points to see something very basic like "this is a bolt stack" when you're looking for something like iron bars.)
  • ownership - stack
  • contaminants - stack
  • temperature - stack (Actually, should this be by stack, or by tile, anyway?)
  • damage - ***
  • age - offload
  • storage information - stack
  • maker ID - offload
  • fortress or import flags - offload
  • melt/dump/forbid/hide designations - stack
  • job information - stack

*** Damage is the only problematic one.  Items in the same stack with one another should probably be damaged the same, but the problem is that they will all start with different damage values.  Probably, the best way to really handle this is to make every individual item in the stack have its pointer to the offloaded data, the number of items exactly like that, and also a damage value.



Edit from a long time later:
Actually, you could track item wear or damage more abstractly, if you don't mind a loss of granularity over some types of items.  (If you are stacking them, anyway, then you shouldn't be all that concerned with granular details.)

Simply track an abstract "Average" wear or damage number, and then a "Standard Deviation" number, and bell-curve the results abstractly.  Hence, throwing a badly damaged item into a stack of reasonably well-maintained items will result in not just a drop in the average wear, but also a spike in the standard deviation, so the bell-curve will be spread out, and abstractly include plenty of low-wear items as well as a few outlier damaged items.

Dwarves could simply draw at random or puposefully pick the most damaged or most repaired ones as specified (so that if they are looking for socks in a sock pile, they would probably want to pick the least threadbare socks to own for themselves).
Logged
Personally, I like [DF] because after climbing the damned learning cliff, I'm too elitist to consider not liking it.
"And no Frankenstein-esque body part stitching?"
"Not yet"

Improved Farming
Class Warfare

Kogut

  • Bay Watcher
  • Next account: Bulwersator
    • View Profile
Re: Stacking and Hauling Improvements (optimization)
« Reply #136 on: June 02, 2012, 05:30:15 am »


In that timeframe, as well, we will be slamming into the Carrying Capacity of the Earth, where humanity will have to destroy itself over the finite resources no longer being able to be stretched further, no matter how much more productivity we may have. 


http://www.space.com/15395-asteroid-mining-planetary-resources.html

This is a company that has just recently been formed that has plans on harvesting asteroids, so there may be a finite amount of material on Earth, but you can't forget the space based resources.

You don't mine for food.

The carrying capacity of the Earth is the amount of people we can feed if we convert every arable patch of land solely to the production of more food.

It is the functional wall into which our world will have to start killing each other over the scarcity of food as portions of humanity start to starve to death and tax our natural resources to the point where we will cause severe environmental degradation that will make our planet less capable of feeding even the few remaining humans.

This will only be averted by either severely limiting human population growth, invention of "superfoods" that take far less arable land to grow, or interplanetary colonization on a scale that allows us to just export excess humans into space. 

Bottom line, the next world war is probably going to be fought over water.
World war over water is impractical - there is no reason why China would attack USA over water, but increasing number of local conflicts is very likely.
Logged
The worst bug - 34.11 poll
Tired of going decades without goblin sieges? Try The Fortress Defense Mod
Kogut, the Bugfixes apostle of Bay12forum. Every posts he makes he preaches about the evil of Bugs.
Pages: 1 ... 8 9 [10]