I got into a temple (finally) after finding a particular item on an NPC, only to find that the only tiles that weren’t covered in solid rock were the upslope tiles. I got the bright idea of blowing them up with some C4, so I got some from the back of my car, went down, set it, went up, waited a safe distance away for a while, and went back down, only to meet my immediate demise as the C4 popped back into existence, realized that its two turn timer was up (despite twenty or thirty turns having already passed in the aboveground world), and blew me to tiny bits of ex-survivor. (Fortunately, suspecting that this might happen, I had backed up my save before trying this, so the only harm I got was the trauma of having to immolate my own corpse, which it turns out burned very nicely thanks to the couple of molotovs I had been carrying at the time of my death.)
The same thing happens with fires. Light a scrap of paper on fire and drive away, spend months in another cell, and come back, and that scrap of paper will be merrily blazing away where you left it.
This also has the side effect of making forest fires actually not dangerous at all: as long as you can move faster than the fire spreads, it’ll never spread from the place you started it to a place you’d rather not see burned to the ground, even if there’s a contiguous forest between point A and point B.
I’m not saying that the game should track the timers and spread-to-adjacent-tile rates of all out-of-bubble elements, which sounds more or less impossible. But as something to consider for future releases, maybe some intermediate solution could be reached?
One thing I’m trying to figure out is if its possible to extend the “realitybubble” because on my desktop, I’m not too worried about raping my CPU, and I doubt it will eat ALL 16 GB of ram… ._. maybe? It would be a nice option to have…
…Care to share some of that RAM? Or CPU? XD An increased reality bubble would be nice but isn’t CDDA already doing a fuckton of calculations per “tick” ?
…Care to share some of that RAM? Or CPU? XD An increased reality bubble would be nice but isn’t CDDA already doing a fuckton of calculations per “tick” ?[/quote]
no. get your own D:< I waste my paychecks, you go waste yours
again, joking aside, I debugg’d a bunch of ammo into an area, then set it all on fire, the absurd number of calculations didn’t hit my CPU as hard as the old bug when sleeping or reading.
lol only 16GB of ram, what do you do? run a rock banging simulation? I run 32 GB on my desktop.
although my laptop(which I use at college or when away) would hate expanded reality bubble, but at my desktop I would love have a greatly expanded reality bubble.
Maybe there’s some shortcuts they can take to simulate “OORB”[Outside Of Reality Bubble]. like not perform every single calculation and maybe simplified ones when it takes place “OORB”.
One thing I was considering (for fire, not bombs) was setting up a condition where the game would run a querry to find the “longest burnable path” from a fire at the time the fire left the player’s reality bubble, then create a counter. If the fire enters the player’s reality bubble before the counter increments, it clears the longest burnable path and destroys the counter, and creates a new one if the fire leaves the reality bubble again. After a certain amount of time (say, 4 hours) the counter increments. When the counter increments, it throws to an if/else:
in Vague and Poorly Considered Pseudocode ™ !
first, destroy the fire and everything on the fire’s square, replace it with a square of appropriate rubble
if the longest burnable path is 0, destroy the counter
else if the longest burnable path is greater than 0
check the burnability of everything within n squares of the origin tile
if burnable, create a fire there
Create Flag 1 = true
if the longest burnable path is greater than or equal to the number of squares in a tile
check the burnability of adjacent tiles (houses = true, forest = true, plain = false, river = false, etc).
if burnable, Create Flag 2.
When the counter increments again (after another 4 hours (or whatever)
if (Flag 1 == true)
destroy all existing fires and everything on the fire’s square, replace it with a square of appropriate rubble, set Flag 2 = false
else end immediately and destroy the counter
consult adjacent squares
if (flag 2 == true)
set everything on fire in the square
set Flag 1 = true
check the burnability of adjacent tiles (houses = true, forest = true, plain = false, river = false, etc).
if burnable, Create Flag 2.
repeat the last step every time increment.
As an added complication, it could attach a “burnability factor” for each square type instead of just a flagged truth value, and roll a die against the factor before doing the last step. That way fires would have a chance to die out on their own, even in the middle of a forest.
That way the engine could simulate the spread and death of fires without having to do per-square per-tick calculations.
Accelerating fires and other things properly is definitely on the list of things to do, though we are still not quite sure about the implementation yet. The big thing to look at is with things that spread, such as fire. Here’s a point where the problem could be visible:
The player lights a big fire in the middle of the forest, then leaves.
The fire “spreads” out into the forest.
The player moves back towards the fire, passing into an area that the fire should have “spread” too, but hasn’t actually reached the fire yet. This area is still green because the game hasn’t update the fire yet.
The player moves close enough that the fire is reloaded. Within a single tick the fire is accelerated to the current time, turning the entire surrounding area into ash, or in a worst case scenario, into a raging inferno.
The alternative method is, as you mentioned, to reload the fires occasionally and update them, but then we face a different problem, that of performance. Is every single fire tile handled individually? If so that’s a lot of calculations that need to be done every X hours by the game. What if we chunk the fire into 4x4 squares or so? Does that mean that if I light a big fire in the middle of a square, leave for a few hours, and then come back I’ll find a 4x4 chunk of fire, despite nothing burnable being nearby but the wood I left there?
We’re still looking at different implementations and trying to discover one that works both efficiently and accurately models the real world.
I’ve increased MAPSIZE from 11 to 21 and DAYLIGHT_LEVEL (max sight range) from 60 to 120. With adjustments elsewhere to remove bare numbers in the code, it works great, laggier of course but only noticeable during rain, and that was fixed with a recent change to keyboard input.
At MAPSIZE 41 it keels over and dies for an unknown reason. (But it’s not ram). If I figure out WTF is causing it, I’ll try to make it an option, but it -will- break saves in interesting ways.
I’ve lit most of the entire reality bubble on fire during nuclear bomb testing which slowed the game significantly. The way I corrected this was to move fire and smoke processing entirely out of the field class and into an [MAPSIZE12][MAPSIZE12] array of struct { short firelevel;short fireage; short smokelevel; short fireage; }. Combined with lightmap improvements (which got merged) this reduced the lag an incredible amount, and this was -without- changing the actual fire logic. The biggest delay ( < 10% of original) became syncing to and from the (terrible) field storage system, and item/item_tag checks (which were needlessly repeated).
I’d have PR’ed it but since it involves ‘map’ and ‘field’, I’m fairly confident it would have been rejected, so it’s collecting cobwebs in a pre 0.7 branch on my harddrive.
(snip)
The alternative method is, as you mentioned, to reload the fires occasionally and update them, but then we face a different problem, that of performance. Is every single fire tile handled individually? If so that's a [i]lot[/i] of calculations that need to be done every X hours by the game.
Long distance fire processing - as described above - might be feasible. There would be zero impact on lightmapping, and one of the biggest remaining bottlenecks - items etc - would be reduced the further away the player is, if everything was done in a chunked fashion; 5, 10, 20 turns of burnage at a time, with burnable stuff abstracted into relevant values (how much do they contribute, and for how long)