I can't promise anything. I've not been the best maintainer. But, if BNW could do something to help you, I may get it done. :-)

Thank you much Omni, I'm a big fan of Brave New World - obviously.

I figured out the bots spontaneous dieing, which had nothing to do with BNW code. There was an issue with crashes when someone leaves the game. You'll see that's commented out in RemoveOrResetPlayer function. I need to further test this with others online. I used to revive the body when I teleported to 0,0 but that was causing crashes on the create_character call. So they remain invisible if I restart them. No crash, clean up works well. Also I've noticed a crash when people leave the game, which I need to monitor, I believe I fixed that.

Were there any bug fixes between 4.1 and 4.2 ? My mod is based off of 4.1.1. I see changes to support seablock, but I haven't dug deep enough to see if there were any bug fixes.

The Seablock changes involved some minor restructuring. The purest version of the diff between the revision of BNW you have, and the Seablock merge is this:

https://github.com/Omnifarious/Braver_New_World/compare/1ae2c5d802b04405c28756c527f62132458437c3...48ebcd2153333e768082df3679eb1797ddf61763

I put in a re-arrangement of functions because KiwiHawk decided he liked a different ordering, and I thought he was right, that the ordering he prefered was better. And I didn't want the Seablock changes and the reordering to appear in the same commit because it made the diff a lot harder to read. :-) So I put in my own version of the reordering before I did the merge. That's why the diff I linked to should be the cleanest.

I posted a request for help debugging THE crash. This is the only issue I seem to be having in dropItems.
https://mods.factorio.com/mod/brave-new-world/discussion/63bdf2c5250457ccc6d7c56c

I'm not sure what caused any items to be dropped, I was in the process of pushing roboports, and laser turrets to clear areas, Not building.

@Omnifarious I have resolved the crashes. They were some issue with WSL2. I used WSL2 to write and test alot of Linux code, but hosting of Factorio - although it seemed to work, was not stable. I switched to a Windows server, and haven't had a crash after about three days of continuous hosting and many people joining/quiting. I'll post this on your server as well.

Interesting. Alright.

Might I recommend hosting on native Linux? :-D

Ya, I prefer hosting from Linux, the Windows hosting was just a side test, and quite a bit easier for me to start up.
Anyway - I have something that you may want. I noticed that the roboport does not attract biters. The radar next to it may make a biter go through the roboport ending the game, but if you remove the radar, or they attack from the radar side, they won't kill the roboport. I've changed that to make the starting roboport really piss off the biters, causing them to attack it. No other roboport is impacted. This is going into my 4.1.6 release.

That is interesting. That's an idea for something to do, a startup option that makes the roboports considered 'military' or maybe just the starting roboport would be considered 'military'.

Exactly - and this benefits on discovery of end of game situation in event on_entity_died

I made a "roboport-main" - in data.lua:
mySpecialRoboport = util.table.deepcopy(data.raw["roboport"]["roboport"])
mySpecialRoboport.name = "roboport-main"
mySpecialRoboport.is_military_target=true
data:extend({mySpecialRoboport})

myLogiRoboportItem = util.table.deepcopy(data.raw["item"]["roboport"])
myLogiRoboportItem.name="roboport-main"
myLogiRoboportItem.place_result = "roboport"
data:extend({myLogiRoboportItem})

control.lua:
script.on_event(defines.events.on_entity_died, function(event)
-- check if roboport was destroyed
if event.entity.name=="roboport-main" then
-- game over dude
end

This also aided me in determining WHO on the force was killed and reset only that one player. Since my mod allows multiple players to join in different areas around the map. So I can reset only the player that died, and not impact the other players.

@Omnifarious - I think I found a bug that has been haunting the game for a while. I'll call it the GHOST bug :)

It crashes on the last line in dropItems:
entity.surface.spill_item_stack(entity.position, {name = name, count = count}, false, entity.force, false)
stating invalid entity.

Inside this if statement:
if count > 0 then
-- now we're forced to spill items
entity = entity or global.forces[player.force.name].roboport
-- log("Spilling items for: ".. entity.name .. "for count: ".. count .. "player force: ".. player.force.name)
entity.surface.spill_item_stack(entity.position, {name = name, count = count}, false, entity.force, false)
end

Error while running event level::on_player_main_inventory_changed (ID 34)
LuaEntity API call when LuaEntity was invalid.

stack traceback:
[C]: in function '__index'
...oaming/Factorio/game1/temp/currently-playing/control.lua:650: in function 'dropItems'
...oaming/Factorio/game1/temp/currently-playing/control.lua:613: in function <...oaming/Factorio/game1/temp/currently-playing/control.lua:552>
5621.000 Error ServerMultiplayerManager.cpp:92: MultiplayerManager failed: "The scenario level caused a non-recoverable error.
Please report this error to the scenario author.

Error while running event level::on_player_main_inventory_changed (ID 34)
LuaEntity API call when LuaEntity was invalid.
stack traceback:
[C]: in function '__index'
...oaming/Factorio/game1/temp/currently-playing/control.lua:650: in function 'dropItems'
...oaming/Factorio/game1/temp/currently-playing/control.lua:613: in function <...oaming/Factorio/game1/temp/currently-playing/control.lua:552>"

I reproduced multiple crashes, if I did find this - it is only an issue using ghost images, which brave new world uses quite a bit.
It runs dropItems when the entity that is dropping is an "entity-ghost". I changed the last if block to this and it has hit it in the failure case, but has not crashed:
if count > 0 then
-- now we're forced to spill items
entity = entity or global.forces[player.force.name].roboport
if (entity.name == "entity-ghost") then
log("WOULD HAVE CRASHED !")
else
entity.surface.spill_item_stack(entity.position, {name = name, count = count}, false, entity.force, false)
end
end

Let me know if you have a better solution. This tends to take many hours of gameplay before it shows up. When it does, it crashes pretty frequently.

Seems there is more than 1 crash of this type - i'm driving a tank around, running over stone and biter nests. This one crashed just as I hit a biters nest:
The log and control.lua I'm using:
https://www.dropbox.com/s/ljl6f80bw7lo8ah/BNW%20-%20pr%20-%20crash.rar?dl=0

This one is slightly different, it crashes just accessing entity.position after:
entity = entity or global.forces[player.force.name].roboport

and always it's when the item is stone

The second crash is if I'm in a tank, and run over stone, the dropItems crashes.
I've made a slight hack of checking if I'm in a tank and the item being dropped is stone, then I just allow it to go into the tank.

Interesting. I'm wondering why the crash happens. Why can't the items be dropped on the ground at that moment?

One approach could be to filter all inventory slots so that there were only slots for things that were allowed, with the rest (since only one stack of each allowed item is allowed) set to some object that doesn't exist. Hmmm....

ya - someone on the help forum recommended the inventory filter as well. The crash (so far), occurs for multiple reasons in dropItems. One was a ghost-entity was placed on top of stone and this triggered a inventory change event and the entity was ghost-entity, but call to spill caused a crash. Second was driving in tanks - over stone, this results in the event being nil prior to the spill, but also "invalid". The problem almost always has to do with Stone being the item/name in that routing. Changing assembler recipes, spill works just fine. The code I've been running and seems to work now is:

    if count > 0 then
        -- now we're forced to spill items
        entity = entity or global.forces[player.force.name].roboport
        if entity and entity.valid then                    
            if (entity.name ~= "entity-ghost") then
                log("dropItems: Spilling items for: ".. entity.name .. ", type: " .. entity.type .. ", at " .. GetGPStext(entity.position) .. ", entity force: ".. entity.force.name)
                entity.surface.spill_item_stack(entity.position, {name = name, count = count}, false, entity.force, false)
            end
        end
    end