Question about nests VS creep

[veden]

Question about nests VS creep

[garrotte13]

I consider another approach - replace selection tool with special entity. Then creep collecting can be done via on-tick events. Wube's selection item is a nice-looking feature, but bad in everything else and can be left to krastorio.

[veden]

I'm not sure I understand what you mean by special entity.
To the first question, it would involve recording unit_number on chunks to be able to do a localized search. If you have an easier alternative then that works.

[garrotte13]

I'm not sure I understand what you mean by special entity.

I mean special some kind of 'items collector' building player is installing and that building starts to remove creep slowly (once per tick or even once per 60 ticks). Then it will have enough time to obtain information.

To the first question, it would involve recording unit_number on chunks to be able to do a localized search.

Will that number distinguish entities of different bases?

[veden]

map[chunkX][chunkY] = {
    unitNumbersOnChunk = {1=true,2=true,3=true},
    baseId = 1
}

would be roughly the data structure. Then you could take the cursor position convert to chunk X Y and do a small search of the area.
Even with a special entity you will still need to perform some type of spatial analysis.
If you have an idea in mind with a special entity over many ticks, then I would go with that idea first. If you want me to look at an implementation of an idea I would be willing to.

[garrotte13]

Is unit number equal to creep tiles number or enemy buildings in chunk?

Even with a special entity you will still need to perform some type of spatial analysis.

Yes, it will also allow to do an individual search for particular to-be-removed candidate tile taking required ticks for it. Not dumb check for entities in selected area like it is done now.

[garrotte13]

And special building will also be more fun. It will consume energy, despite being not so fast as area selection tool it will correctly prioritize what tiles should be cleared first. Player will have to protect this building from enemies. But that's off-topic.
I'm still trying to understand how particular enemy building can be associated with a "base" - group of buildings, to know exactly that particular "base" doesn't exist anymore (all buildings were destroyed) and creep can be collected.

[garrotte13]

Aah, special building must also be able to timely detect the moment of "base" destruction and creep footprint unlocked for gathering.

[garrotte13]

I read a little about pixel connectivity and came to conclusion, that for Rampant-generated bases I can replace 2-chunks radius of selected area entities search with simple 4-connected or 8-connected algorithm to get all tiles belonging to one "base". After that I need to check all of them for abscence enemy worms/nests colliding with them.
4-connected gives a chance to separate two merged bases when player goes far from starting zone.

What do you think?

[garrotte13]

Factorio already has 4-connected algorithm implemented https://lua-api.factorio.com/latest/LuaSurface.html#LuaSurface.get_connected_tiles

[veden]

Just making sure I understand the question.
Is any creep that has at least one tile separation between creep patches consider a new base?
If a enemy structure is on one of those creep patches, none of the connecting creep can be collected?
You are wanting a player built structure to harvest creep at some rate within a certain radius around itself?

[veden]

If creep merges multiple patches, does one of the bases take over all the patches?

[garrotte13]

Is any creep that has at least one tile separation between creep patches consider a new base?

Yes. And that is provisioned by no creep tiles were removed by player beforehand - it happens 100%, as creep protection should not allow to touch any creep tile.

If a enemy structure is on one of those creep patches, none of the connecting creep can be collected?

Yes, that is it! If making a special structure to gather creep, then yes.

In theory two creep footprints could be the same base, but every nest/worm creates creep patch with radius of 5 or more around it (for evo 9%, 6 for 19%, 7 for 29% and so on). Therefore first hives at 31% appear when minimal radius of creep is 8 - it should generate buildings around it 17 tiles away, I saw no further than 10-12 tiles. Am I wrong?
So the only situation is when some Rampant defending squad builds nests/worms after player started creep gathering (and already destroyed all old worms/nests in the area) - I see no problem to consider those new nests/worms as a separate base.

Yes, I suppose to make a small building with function of gathering creep. And I suppose built-in connected-tiles search code won't be good with it, unless it is implemented in C and much-much faster than lua implementation. Gathering by building doesn't need to be very fast - it can warm up for a few seconds (200 ticks for example) before starting to collect free creep.

I'm trying to check performance of built-in connected-tiles search method right now with manual collecting via area selection by player.

[garrotte13]

If creep merges multiple patches, does one of the bases take over all the patches?

Yes. And the main idea is that I don't need such complex logics of detecting bases like in your mod. I need only to separate creep footprints and prohibit collecting true creep before all nests/worms of particular footprint are killed (there is also fake creep, which looks like creep, but doesn't give biomass and is generated in distal part of footprint - I don't want to protect collecting this type of creep)

[garrotte13]

I made some working code for manual collecting. It works fine for making up tiles footprint via built-in Factorio API 4-connections and successfully finding enemy buildings on it, BUT as I don't want to build 2 and more footprints (to avoid lags during area selection; I'll support it in collector tower if I'd decide to implement it) I added a check for tiles to be in the same footprint and this check doesn't work properly unfortunately. Something about position array comparison with sub-array of tiles positions. Or maybe Factorio API has issues and returns not with accordance to its documentation. It allows to take creep from protected area if player stands on the border to reach tiles in both footprints and makes a big selection.

There are two creep types - fk-creep and kr-creep. Only kr-creep is generated under enemy structures and near them. fk-creep is in distal zones, therefore I'm using both for footprint creation, but make enemy collision checks only with kr-creep to decrease amount of entities searches and to allow collect fk-creep even from protected footprints as far as there is no direct range protection by enemies.

Could you please take a look?
https://github.com/garrotte13/Warmonger/blob/7e7a3df8227fbcc9b97224e9012ed403838c2afc/scripts/creep-collector.lua

[veden]

There are ways that you could optimize the code. What you have looks to get the job done. Are you wanting general feedback or suggestions? Also are you wanting to keep the creep shovel? There are ways to hide the computation and have it work. There are tradeoffs that will most likely need to be made if you are wanting a building. I have some code in this repo around picking up items from the ground which is similar to what you are doing.

[garrotte13]

1. This code has one problem now as I wrote above - it doesn't detect correctly situation when kr-creep tiles from more than one footprint are selected. Instead of filtering them out and printing their number it always detects them as part of one footprint array. I thought maybe you could have a look and find the reason why it happens.

2. I'm still not sure, that building is better. The only advantages are that it will allow to automate creep collection (running around with shovel is not a factorio-style play - people complain about it in mod feedback, I wonder why they don't complain in Krastorio2 about the same...) AND that I'll be able to slow down the process - removing up to 314 tiles in one tick isn't realistic.
   Thanks for idea about your items collector mod code. I'll take a look. Right now I found a very good example of your airfilter. :-)
   But anyway it requires much more complex logics than that: find and process all creep footprints in tower range, detect and solve conflicts if 2+ towers have overlapping ranges, re-scan and re-calculation of footprints and enemies protecting them as objects may change while tower slowly collects one tile per 2-4 seconds, prioritizing tiles colliding with player buildings, showing range circle while player has tower in cursor. Big code challenge while I'm not a fan of coding :-)

[garrotte13]

I'm 99% sure, that something is terribly wrong in this search cycle:

function IsTileInArray (tile_position, tiles_array)
  for a=1, #tiles_array do
    if ( tiles_array[a][1] == tile_position[1] ) and ( tiles_array[a][2] == tile_position[2] ) then return true end
  end
  return false
end

because I tried to use it in other mod's function and got into trouble. It seems to me that this search always returns true on the very first member of array ('tiles_array' in this example). I don't know why.

[garrotte13]

yes, confirmed the problem in LUA emulator with this code:

local tiles_array = {
{x = 10, y = 20},
{x = 40, y = 30},
{x = 21, y = 55},
{x = 48, y = 23}
}

local tile_position = {
x = 21, y = 55}


for a=1, #tiles_array do
 if ( tiles_array[a][1] == tile_position[1] ) and ( tiles_array[a][2] == tile_position[2] ) then
  print("yes, it is ".. a)
  break
 end
end

But I don't understand why it doesn't work as it should

[veden]

for a=1, #tiles_array do
 if ( tiles_array[a].x == tile_position.x ) and ( tiles_array[a].y == tile_position.y ) then
  print("yes, it is ".. a)
  break
 end
end

The keys are fields on the table not indexes.
Factorio based luaObject positions behave differently because they are rooted in C objects.

tiles_array[1][1] == nil
tile_position[1] == nil
tiles_array[1][1] == tile_position[1]

[veden]

 AND that I'll be able to slow down the process - removing up to 314 tiles in one tick isn't realistic.
Thanks for idea about your items collector mod code. I'll take a look. Right now I found a very good example of your airfilter. :-)

Nothing says the event needs to add something to the players inventory in the same tick. Spreading the computation over say 30 ticks is 0.5 seconds which isn't probably going to be that noticeable.

[garrotte13]

as LUA emulator gave me the same trouble I'm pretty sure Factorio LUA engine is not bad. It's me not good in LUA...

[garrotte13]

Yes, I also come to conclusion, that comparison gives true, because I compare nil vs nil :-)
I wonder how to compare positions. I can't compare tile_position vs tiles_array[a] , because LUA doesn't allow to compare entire sub-arrays.

[garrotte13]

wow, I made it work this way:
if ( tiles_array[a].x == tile_position.x ) and ( tiles_array[a].y == tile_position.y ) then return true end

Both in LUA emulator (https://www.lua.org/cgi-bin/demo) and in Factorio.

[garrotte13]

 AND that I'll be able to slow down the process - removing up to 314 tiles in one tick isn't realistic.
Thanks for idea about your items collector mod code. I'll take a look. Right now I found a very good example of your airfilter. :-)

Nothing says the event needs to add something to the players inventory in the same tick. Spreading the computation over say 30 ticks is 0.5 seconds which isn't probably going to be that noticeable.

The thing is not in inserting all biomass into inventory at once, but in instant removing of 300 creep tiles from planet with one shovel, not even with 300 construction bots.

[garrotte13]

Is any creep that has at least one tile separation between creep patches consider a new base?

You're right. Thanks! After fixing the tile search issue it irritates a little when start collecting from center of a patch and making separate footprints as a result. But I won't replace built-it 4-connections algorithm (probably C++ implemented) by my own slow lua 48-connections (to ignore up to 3 tiles separations between patches). It won't solve inconvenience completely. Only separate calculations for all footprints will do. And it's very dangerous to do in realtime calculations with shovel collector. I'll better do it with creep collecting building.

[garrotte13]

Made a test prototype for creep collecting building (burner and electric energy sources) via assemblingmachine prototype, but result is too boring and Factorio API doesn't allow to manage energy consumption directly - I was planning to consume energy per tile purged and for other preparation activities building provides, but it can't be done for any of energy sources. Looks like radar prototype also won't help here. :-( Maybe will make direct resource consumption: e.g. 1 coal unit for 1 creep tile, but see no similar way for electric power).

[garrotte13]

As I see in your Item Collector mod, I can implement creep tile purge via sector scan function. Mining drill could be even more universal approach if it would allow to work without resource type entity, but making internal syntethic activity.
From other point of view electrical creep miner can be enough - player won't remove creep till some technological progress event (for example electric-energy-distribution-1 research). He still will be able to survive.

[garrotte13]

Yes, you were completely right about radar-based structure. It suites best this goal. And I need to change only some part of prototype code. Thanks a lot!

[garrotte13]

I implemented connect-36 algorithm in Lua and as expected it takes a lot of time. Using it in 'shovel' runtime mode leads to severe UPS decrease (40 UPS in moment). And I don't see a way to make it tick-based (creep can be generated/removed in parallel). Also I don't want to make some big global objects to store this info and update it (merge/split arrays when creep footprints are united or cut into two) - it's too difficult. I want to play, not to code all the way like you do :-)

Instead of all these I came to other ideas how to restrict creep collecting by special creep mining buildings - for example I take into consideration that Rampant triggers other 'bases' to send helper squads when some base is under attack. So presence of any enemies (including units) in miner's chunk (or maybe even adjacent ones too) will prevent true creep excavation.

Thank you for help and ideas!