Construction bots and build events

[JamesOFarrell]

At the moment the events for watching when entities are built or picked up by the player are some of the more useful events in the game but I have just noticed that items build or picked up by construction bots do not trigger these events. This can lead to inconsistent behavior in mods when tracking entities by taking note of when they are built and picked up.

I am not sure if they should trigger these events or if there should be separate events when construction bots do their thing but I am happy with either solution. Thoughts?

[darius456]

I have noticed it too so I allways destroy ghost building (in control.lua) to prevent rebuilding by bots, but I have no idea how to prevent bugs caused by:
1. picking up my entities by bots
2. building my entities by blueprint.

[Rahjital]

Indeed, this pretty much breaks any mod that relies on these events since robots are one of the more major Factorio features. Perhaps it should trigger for both players and bots and one of the arguments of the event should be the entity that triggered the event? It will be needed once multiplayer comes around anyway.

[Rseding91]

Surprised this still hasn't been done. There's a lot of stuff that's limited mod-wise because robots don't trigger "on built" or "on mined" events :\

[JamesOFarrell]

Surprised this still hasn't been done. There's a lot of stuff that's limited mod-wise because robots don't trigger "on built" or "on mined" events :\

Maybe it is time to re-post it as a bug or get ssilk to move the thread to the bug forum.

[FreeER]

Maybe it is time to re-post it as a bug or get ssilk to move the thread to the bug forum.

Except it's not a bug, it's a lack of a feature; even if that feature is something considered 'essential' to consistent mod results. The devs know about this and will implement it when they decide they have the time to do so. I imagine that by the time multiplayer is 'working' (not necessarily finished) there will need to be a number of api changes (at least internally) to support it as well, give them time. Until then continue letting players know that they need to build the mod entities (or rebuild them) if they use bots or give them a way to tell the code where those robo-built entities are after they're built (OR hook into when players' place blueprints, and watch that area until all ghosts are gone...I think that would be possible, but I haven't tried...)

hm...I'm going to do a little testing. edit: well, entirely unsuccessful (as expected) lol. I tried to see if I could find out what the entity being built was from a ghost, not possible. The only way I can currently think of is to find when the player uses a blueprint (with onplaceditem) and storing a reference to all ghosts (found via findentitiesfiltered), once they are no longer valid do a findentities[filtered] for your entities and see if there are any (and that they aren't already in your tables)... though that still won't catch 'manual' ghost entities.

[JamesOFarrell]

Except it's not a bug, it's a lack of a feature; even if that feature is something considered 'essential' to consistent mod results. The devs know about this and will implement it when they decide they have the time to do so. I imagine that by the time multiplayer is 'working' (not necessarily finished) there will need to be a number of api changes (at least internally) to support it as well, give them time. Until then continue letting players know that they need to build the mod entities (or rebuild them) if they use bots or give them a way to tell the code where those robo-built entities are after they're built (OR hook into when players' place blueprints, and watch that area until all ghosts are gone...I think that would be possible, but I haven't tried...)

You are correct, It is not a bug.

hm...I'm going to do a little testing. edit: well, entirely unsuccessful (as expected) lol. I tried to see if I could find out what the entity being built was from a ghost, not possible. The only way I can currently think of is to find when the player uses a blueprint (with onplaceditem) and storing a reference to all ghosts (found via findentitiesfiltered), once they are no longer valid do a findentities[filtered] for your entities and see if there are any (and that they aren't already in your tables)... though that still won't catch 'manual' ghost entities.

I've been thinking about this a bit recently, you can catch manual ghosts by checking for ghosts every time the player places any item. We would only need one mod to do this and throw an event. Then other mods can require it. This would get us over the hump until the devs get a multiplayer sorted.

[FreeER]

We would only need one mod to do this and throw an event.

true
something like this should work (though this code specifically is untested right now, I have done similar elsewhere), a couple possible changes would be to use a custom event (avoid possible issues with mods depending upon createdentity being a rich Lua/Entity instead of a table substitute) or wait to raise the event until it's actually built and pass the real entity...

Code: Select all

game.onvent(defines.events.onputitem, function(event)
    local ghost = game.findentitiesfiltered{name="ghost", area=getBoundingBox(event.position, 2)}[1]
    if ghost then 
      game.raiseevent(defines.events.onbuiltentity, {
          name=defines.events.onbuiltentity,
          tick=game.tick,
          createdentity=fakeEntity(game.player.cursorstack.name, ghost.position), -- can't pass 'rich' data, same as interfaces
          mod="ghost-detector" -- some easy way to know that this is not raised by Factorio directly, also says exactly which mod raised it.
      })
    end
end)

getBoundingBox(position, radius)
  return {{position.x-radius, position.y-radius}, {position.x+radius, position.y+radius}} 
end

function fakeEntity(itemname, position)
  return {valid=true, name=game.itemprototypes[itemname].placeresult.name, type=game.itemprototypes[itemname].placeresult.type, position=position}
end

edit: thinking about this, it's very probable that the ghosts would not actually be created until after the onplaceditem event had ended, so this would actually need to insert the relevant info (itemstack name and position) into a table and check for the ghost in ontick. I'll do some more testing with this tomorrow if no one does before me Obviously a 'proper' mod for this would handle blueprints as well as the manual ghosts, but that's a very similar procedure.

Hm, I have been trying to gather a few of my 'useful' functions into an 'extra utilities' mod thing, but I don't have very many lol. I could probably add this to what little I have and throw it up on Github for others to add to and improve (another feature I'd like to add to eu would be easier entity interfaces...not entirely sure how that would best be implemented however).

[JamesOFarrell]

The other issue we have is that there is no bot mined item event. This can be handled by tracking entities in mods but it would be a nice to have an event. Maybe track the deconstruction tool and use a similar method for finding entities, then throw an event when they become null. You would also have to register for the other events and stop tracking entities if they are destroyed or mined to avoid those nasty edge cases.

Hm, I have been trying to gather a few of my 'useful' functions into an 'extra utilities' mod thing, but I don't have very many lol. I could probably add this to what little I have and throw it up on Github for others to add to and improve (another feature I'd like to add to eu would be easier entity interfaces...not entirely sure how that would best be implemented however).

This is a really good idea, if you do this I will add something to handle entity groups with some utility functions for dealing with syncing inventory and health. I am also putting off rewriting TheFatController at the moment but when i get around to it I will be writing a new train tracking class for it so I could always include that as well.

[FreeER]

The other issue we have is that there is no bot mined item event.

I really wasn't thinking of this as much of an issue since bots don't signal the mining event, and scripts calling destroy on something typically do not raise an event manually (neither, of course, do commands entered via console, eg during debugging/testing or rare cases of players doing so), then without entity.valid checks errors are likely anyways. However, it wouldn't be hard to include, just a bit time/memory consuming to track everything; I suppose it'd be easy to have mods 'subscribe' during oninit and start tracking then but that causes inconsistencies when adding mods to saves (for vanilla entities that weren't being tracked before). hm, which obviously leads to the idea that vanilla entities could be tracked from start and mod entities would be tracked when subscribed...though that needs a 'list' of vanilla entities, unless all entities were tracked by default and the 'subscription' would cancel the tracking....

Any suggestion as to whether these should be done via custom events or should it be done with the Factorio events and 'fake' entities (where required)? I think the 'fake' entities would prevent most potential errors (though probably not all), and prevent other mods from having to do anything different, whereas with a custom event there can't be any errors but mods would need to be updated to use it.

I will add something to handle entity groups with some utility functions for dealing with syncing inventory and health

Sounds good, I'd like to have two 'versions' of the EU mod. One for development/debugging (with error("message", level) statements to point to the actual 'wrong' line) and one that's for 'release' that is as fast as possible (no runtime error checking, assumes correct input)

One 'issue' I come to is that it shouldn't be an actual mod since script interfaces can't pass rich data, including functions (which would lead to, potentially, numerous calls to findentities to get Lua/Entities from passed positions, hardly optimal)... I'd initially thought that it could be placed in the core/lualib folder so that there's only one copy that all mods can use (which means it's easy to update and there aren't duplicates wasting hard drive space), however some of what would be added needs a control.lua to run...I suppose it'd be possible to setup the functions and have mods call game.onevent(event_def, eu.event_def)...hm, well I'll think about it some more tomorrow Maybe someone will have some other good ideas (and/or solutions) and post them between now and then.

[FreeER]

I could probably add this to what little I have and throw it up on Github

GitHub ExtraUtilities, I don't feel it's ready for an actual 'release' (probably a couple bugs right now) so no mod topic yet
btw, I'm sure there's a better way to implement the sound 'feature' (it was something I'd wanted to try since I managed to get the CC mod to load). And the 'timer' code that's there is A) completely untested in Factorio and B) the first time I ever tried using OOP in lua, so I've no idea how useful it would be lol (and I've never used a timer object with Factorio so I don't know how people would want to use one anyways)

One last comment here... I did just receive a Factorio crash (not responding), but I've no idea what caused it.

[JamesOFarrell]

Tracking Stuff

Tracking all entitles for deconstruction would be a pain in the ass and use a lot of CPU. I was thinking of a script interface to add entities to be tracked but I think it is probably not worth the effort.

One 'issue' I come to is that it shouldn't be an actual mod since script interfaces can't pass rich data

I've never used scripting interfaces before so I didn't realize the limitation was that bad. Not being able to pass around anything but primitive types is going to be really limiting. As you can have more than one of the same entities in the same position there are always edge cases with fake entities that we would never be able to get rid of. Do we know how factorio stores references to in-game objects? Can we serialize the references and pass it as a base64 string? Even that means people will have to include a bunch of code in their mods to work with this library but it would get rid of all edge cases. If we have to write it as a library for people to include then every mod that is interested in ghosts will have to track the ghosts interdependently which really defeats the purpose.

GitHub ExtraUtilities, I don't feel it's ready for an actual 'release' (probably a couple bugs right now) so no mod topic yet

I'm looking through this now. Some useful functions in here. That sound module is very cool, something similar could be done for animation as well.

[FreeER]

Not being able to pass around anything but primitive types is going to be really limiting.

Yep. The reason is that mods are in separate Lua states, unfortunately that does mean that without more work by the devs the interfaces only allow passing primitives (even lua function callbacks could be a fairly useful).

Do we know how factorio stores references to in-game objects?

If I recall correctly it's userdata with the __self metamethod set to a lightuserdata of the actual entity object...now I've no idea if that can be serialized or not

If we have to write it as a library for people to include then every mod that is interested in ghosts will have to track the ghosts interdependently which really defeats the purpoe.

not completely, a library would mean that no one has to waste their time writing something that's already been done, which also provides such features to new modders that have little programming experience, and abstracts the code away for when the devs eventually make it easy to do this (mods wouldn't have to immediately update to use it, just need the library to be updated). But no, it wouldn't be the optimal solution.

Some useful functions in here

Thanks, that was the point

That sound module is very cool, something similar could be done for animation as well.

Animation would be a good next step. As for the sound... I dislike the fact that they are so visible to the player (player targets the enemy units and the turret displays an out of ammo icon...). I think it'd be possible to use something like the explosions to play the sound, but I wanted to try the turrets first since it eliminates (theoretically) the need to create a new entity every time...hm, I seem to recall that the devs changed how ammo worked a few updates back, maybe that could be useful (or apply to other entities...)

[Rseding91]

Robot related events where added in 0.11