Fog of War

[DerVVulfman]

Well, as I previously stated...

It needs some cleanup by my standing, and I want an optional means to flag events besides within the config page. So not done yet.  BUT it is performing the options you've requested... and more.

So additional work will be performed.

I was able to apply your options TO my demo, only the mild correction to the 'check_adjacent' method within Spriteset_Map being necessary.

Why my version has an altered 'check_adjacent' method

The original check_adjacent method asked for five parameters:

i : x-coordinates
j : y-coordinates
k : layer (whether dynamic or static)
grid : map grid
flag : a called flag

The thing is, in every instance, the grid was always $game_map.fow_grid.  And in every instance, the flag requested was the Fog_of_War::REVEALED flag.   To me, it didn't make sense that these two values would be requested every time when they could just be IN the method itself.

That's why my version just requests the i, j, and k parameters, and have both grid and flag defined in the method itself.

However, whilst it worked with your edits, I encountered an issue.  When the player moved about on the map, the player erased the fog within the 3-tile range prescribed by the FOW_RANGE_DEFAULT configuration variable.  After standing for some time, the area around the player erased more, returning to the 5-tile range defined within the FOG_MAPS array for map 3.  So it did not properly erase the  area around the player whilst moving as it should, only that around the player when standing still.


The update_fow_tilemap section does have long code, some quite similar to one another. Do note that he has comments that his work is designed to 'only process fow currently on the screen'. And for that, he used routines that had lines such as:

if @fow_tilemap.map_data[x, y, 1] == 96
    @fow_tilemap.map_data[x, y, 1] = 96
end

Now while it ensured that the data within the coordinates of x/y became whatever value it demanded, it only performed the data change if the x/y coordinate data wasn't.  Odd as it sounds, performing the check and skipping takes slightly less time than arbitrarily changing it every time.  Go figure. 


Some of the content you 'removed' thinking redundant within the update_fow_tilemap was was actually present to prevent errors and map glitches, particularly around the static secondary static map section when it indeed needed to see if areas needed to be SKIPped.  The SKIP flag is called into play both within this area and tested for when a map is initialize or re-initialized, this to reduce more lag and fog processing.

And further below is the area that updates the tileset based on 'range'... likely where it sees (at least within mine) the proper area range for the player or the NPCs and the area to erase.

Meanwhile, changes I made to  update_fow_tilemap include both the request of x/y coordinates of the target character (player or any event), and a speciic range for said player or event. The range passed into it directly related to the area you erased near the bottom of the method.


Again, I do state it needs some cleaning up.  But some facets of the script need remain in place, or optimized rather than wholly removed.