building on burning oil

[wzdev-ci]

keyword_burning_oil resolution_fixed type_bug | by Terminator

---

Not only I can build on burning oil and AI can do it too.

---

Issue migrated from trac:1100 at 2022-04-15 20:06:40 -0700

[wzdev-ci]

Terminator uploaded file wz2100_shot_002.png (61.4 KiB)

[wzdev-ci]

Zarel changed status from new to closed

[wzdev-ci]

Zarel set resolution to fixed

[wzdev-ci]

Zarel commented

---

Hopefully fixed in [8493]/[8494].

[wzdev-ci]

Safety0ff changed priority from major to minor

[wzdev-ci]

Safety0ff changed status from closed to reopened

[wzdev-ci]

Safety0ff changed operating_system which not transferred by tractive

[wzdev-ci]

Safety0ff changed resolution from fixed to ``

[wzdev-ci]

Safety0ff commented

---

Still present.

Steps to reproduce:

• have a fire weapon kill a derrick,

• when the fire from the flamer goes out you can build on the resource.

If you look that the above screen shot you'll see a flamer (which likely killed the derrick.)
I've attached a very inefficient hack / patch to show where the problem occurs.

I'll leave it up to someone with better knowledge of the code base to choose the best solution.

This happens in 2.3 and trunk, the patch was made from trunk.

[wzdev-ci]

Safety0ff uploaded file firehack.diff (0.7 KiB)

Made from trunk

[wzdev-ci]

Safety0ff commented

---

It is be possible to increase the efficiency of the patch by using a separate list for fire (or just partitioning the list with the fire at the front.)
Also it should be possible to compare the positions directly without using mapTile().

The alternative is to have each tile have a variable to count the number of burning effects. Incremented when fire is created on a tile, decremented when fire is killed.

[wzdev-ci]

Safety0ff changed milestone from 2.3 to 2.3.1

[wzdev-ci]

cybersphinx changed milestone from 2.3.1 to unspecified

[wzdev-ci]

Per changed status from reopened to closed

[wzdev-ci]

Per changed resolution from `` to fixed