Re: Mylon's Many Mods
Posted: Fri Feb 16, 2018 2:22 pm
I put out a big update for Dirt Path. It's such a small mod, but it has a nice impact. Changing it to 0.16 tiles makes it much more satisfying.
There's still no support for modded ores with storage and some not being targeted.What's wrong with TTSFN? I updated it recently to fix some of the bugs here.
Code: Select all
--- \Bluebuild_1.1.9\control.lua
+++ \Bluebuild_1.1.9\control.lua
@@ -124,11 +124,11 @@
if builder.get_item_count(module) > 0 then
local modStack = {name=module, count=math.min(builder.get_item_count(module), modulecount)}
revive.insert(modStack)
- builder.remove_item(modStack)
+ -- builder.remove_item(modStack) -- this line caused modules to be removed twice -- this one needs a bit of testing
end
end
-- game.print("Removing item from inventory.")
- script.raise_event(defines.events.on_put_item, {position=revive.position, player_index=builder.index, name="on_put_item"})
+ script.raise_event(defines.events.on_put_item, {position=revive.position, player_index=builder.index, name="on_put_item", direction=revive.direction}) -- added direction. Miniloaders crashed due to its absense
script.raise_event(defines.events.on_built_entity, {created_entity=revive, player_index=builder.index, tick=game.tick, name="on_built_entity"})
table.remove(areaList, index)
Code: Select all
function cleanDirt()
if not global.dirt then
log("Dirt Path not initialized!")
return
end
for k, v in pairs(global.dirt) do
global.dirt[k] = global.dirt[k] - 1 -- this line throws error: "attempt to perform arithmetics on field '?' (a table value)"
if global.dirt[k] <= 0 then
global.dirt[k] = nil
end
end
end
I suspect you should not be raising "on_put_item" at all here. Since "on_put_item" doesn't have a field for the item being used, the assumption is that the item being placed is the one in the player's cursor_stack. In the case of Bluebuild, the item the player is holding likely has nothing whatsoever to do with the ghost that was revived or the newly built entity.Mylon wrote:Good catch about the missing direction. I'll have to test ghost reviving. I don't think the game will auto-insert modules if you have them, which is why I had that logic in there. I had to simulate inserting them.
Bluebuild is intended to simulate the behavior of the player pressing "q + click" over a ghost, which does fire the event.Deadlock989 wrote:Hi,
I'm fielding reports of odd behaviour with Bluebuild-built loaders from my Compact Loaders mod (https://mods.factorio.com/mod/DeadlockLoaders). I've tested and confirmed that there is an issue. It seems that undesirable things are happening because Buildbuild fires the player on_build_entity event when it revives a ghost.
My understanding of the game logic behind that event is that it is meant for when a player manually places an item in the world. There is a separate event provided for construction bots, which my mod deliberately ignores. on_build_entity is for when a player creates a brand new entity in the world in an empty space. on_robot_built_entity is for when a ghost is being revived. I have the same issue with Nexela's Nanobots, which does more or less the same thing. I have code running on_build_entity which changes the orientation of brand new entities. Such code should not be running when it involves reviving a ghost, because blueprints have the orientation very carefully defined already.
So I'm now faced with the choice of either making special exceptions for a potentially unlimited number of other mods, or completely re-writing that part of my code in some other way, because a few other mods are using events for things which I don't believe they were intended for.
Ideally, Bluebuild would use on_robot_built_entity instead, since this is clearly a form of robot building and it revives ghosts.
Many thanks.
I do seem to be using on_put_item incorrectly, or at least passing the wrong parameters. But it it is raised when building over a ghost. As I stated before, Bluebuild is intended to simulate the player performing a "q + click" to place an entity. But I just tested and on_put_item fires when placing a ghost, when placing an entity, and when placing an entity over a ghost.Therax wrote:I suspect you should not be raising "on_put_item" at all here. Since "on_put_item" doesn't have a field for the item being used, the assumption is that the item being placed is the one in the player's cursor_stack. In the case of Bluebuild, the item the player is holding likely has nothing whatsoever to do with the ghost that was revived or the newly built entity.Mylon wrote:Good catch about the missing direction. I'll have to test ghost reviving. I don't think the game will auto-insert modules if you have them, which is why I had that logic in there. I had to simulate inserting them.
For comparison, in vanilla on_put_item is raised when the player puts down a blueprint, and is not raised when a robot revives a ghost into an entity.
The performance benefit for this is negligible. Some mods (Dirt Path) use the logic, but for most mods it's not worth an update by itself.mrvn wrote:Any plans to use the new on_tick_N (or what is was called) function instead of checking every tick if it's time to do work?
Q simply pipettes the item that's being hovered over, i.e. if you hover over a ghost and you have the required item in your inventory, it puts the stack onto your cursor. It doesn't even always get the orientation right. The player still then has to manually click and place the item down themselves, making it a player-driven event. They could also change their minds and build something completely different over the ghost. Either way, it's not a bot reviving the ghost, it's the player. In fact it's not even a ghost being revived, it's being built over.Mylon wrote:Bluebuild is intended to simulate the behavior of the player pressing "q + click" over a ghost, which does fire the event.
I just tested it and on_put_item fires too. Even when placing ghosts, which is strange.
Nanobots inserts an additional revived=true parameter when it raises on_built_entity. When my mods see that parameter, they treat the whole thing as a robot (automated) build rather than a player build. It would be nice if Bluebuild would do something similar.Deadlock989 wrote: My understanding of the game logic behind that event is that it is meant for when a player manually places an item in the world. There is a separate event provided for construction bots, which my mod deliberately ignores. on_build_entity is for when a player creates a brand new entity in the world in an empty space. on_robot_built_entity is for when a ghost is being revived. I have the same issue with Nexela's Nanobots, which does more or less the same thing. I have code running on_build_entity which changes the orientation of brand new entities. Such code should not be running when it involves reviving a ghost, because blueprints have the orientation very carefully defined already.
Deadlock is 100% correct here. There are bunch of things that Q+click can't do that reviving a ghost will do. In particular: when reviving a ghost, the new entity may get circuit connections, may have circuit and logistics conditions already configured, and may set up an item-request-proxy entity to request modules from the logistics network. For renameable entities like train stops, they may already have a name configured. None of these are possible with Q+click.Deadlock989 wrote:In fact it's not even a ghost being revived, it's being built over.
To truly simulate the whole operation, you'd need to raise events for the pipette and cursor_stack changes, too:Mylon wrote:I do seem to be using on_put_item incorrectly, or at least passing the wrong parameters. But it it is raised when building over a ghost. As I stated before, Bluebuild is intended to simulate the player performing a "q + click" to place an entity. But I just tested and on_put_item fires when placing a ghost, when placing an entity, and when placing an entity over a ghost.
There are very few perfect solutions when you're modding a game to do something not built into the core engine. I'm less concerned about being surprised than I am about having no way at all to distinguish between a real player really building something and a fake player literally doing the work of a construction bot. If people need a bot-less bot build event, I'd say that's a feature request.Therax wrote:As for using on_robot_built_entity instead, that's not a perfect solution either. Some mods likely assume that if on_robot_built_entity is raised, there is an actual construction-robot entity around, referenced by the robot parameter. No matter what you do, somebody will be surprised since automated player construction doesn't really fit any base event perfectly. FWIW, I thought the exact same thing you did at first: viewtopic.php?f=93&t=54343&start=60#p334828
That's easy enough to do.Therax wrote:Nanobots inserts an additional revived=true parameter when it raises on_built_entity. When my mods see that parameter, they treat the whole thing as a robot (automated) build rather than a player build. It would be nice if Bluebuild would do something similar.
Code: Select all
/c script.on_event(defines.events.on_built_entity, function() if game.players[1].cursor_stack.valid_for_read and game.players[1].cursor_stack.valid then game.print(game.players[1].cursor_stack.name) else game.print(nil) end end)
It's a good idea. It's even already implemented: http://lua-api.factorio.com/latest/even ... ised_builtDeadlock989 wrote:If people need a bot-less bot build event, I'd say that's a feature request.
The important event for the cursor stack is "on_put_item", which is raised before the entity is actually built, so the cursor stack should still be valid. This is the one that's confusing Miniloader, because Bluebuild can trigger on_put_item while the user has a blueprint in the cursor, and my mod thinks the user just placed a blueprint, and starts looking for existing entities that are being built over. It actually crashes because Bluebuild doesn't currently provide "direction" in the event.Mylon wrote:When placing the last item, it prints nil. So cursor_stack isn't always valid during the event, even during normal build behavior.
Actually Q+click has gotten better in 0.16. For example when you Q+click an assembler over a ghost then the newly built assembler will have the recipe from the assembler. Underground belts go the direction of the ghost. I can't wait for placing over a ghost to preserve the circuit connections. It's just a matter of time till they do.Therax wrote:Deadlock is 100% correct here. There are bunch of things that Q+click can't do that reviving a ghost will do. In particular: when reviving a ghost, the new entity may get circuit connections, may have circuit and logistics conditions already configured, and may set up an item-request-proxy entity to request modules from the logistics network. For renameable entities like train stops, they may already have a name configured. None of these are possible with Q+click.Deadlock989 wrote:In fact it's not even a ghost being revived, it's being built over.
[/quote]Therax wrote:To truly simulate the whole operation, you'd need to raise events for the pipette and cursor_stack changes, too:Mylon wrote:I do seem to be using on_put_item incorrectly, or at least passing the wrong parameters. But it it is raised when building over a ghost. As I stated before, Bluebuild is intended to simulate the player performing a "q + click" to place an entity. But I just tested and on_put_item fires when placing a ghost, when placing an entity, and when placing an entity over a ghost.
At some point you'll of course have to remove the item from the player's inventory, and I could see the case for doing it anywhere in this sequence. Even then you're not guaranteed compatibility since some other mod may not expect all of this to happen within the same tick, but there's only such much you can do.
- set the player's cursor_stack to the appropriate item, saving the current cursor_stack somewhere safe. This gets a bit tricky if the stack in the cursor is complex, like a fully populated power armor or a blueprint book.
- Raise on_player_pipette and on_player_cursor_stack_changed.
- Raise on_put_item.
- Actually revive the ghost.
- Remove the item from the cursor stack and raise on_player_cursor_stack_changed to reflect the use of the item.
- Raise on_built_entity.
- Reset the player's cursor stack to its original contents, and raise on_player_cursor_stack_changed again.
I don't think this level of precision is required, but you'll at least want to change cursor_stack so that the state is correct when on_put_item is raised. In a Q+click scenario, the item in the cursor is the item being built, not whatever random thing the user has in the cursor when they walk near a ghost. My recommendation would still be to not raise on_put_item at all, and just do what Nanobots does, which is to raise on_built_entity with an extra revived=true parameter: https://github.com/Nexela/Nanobots/blob ... l.lua#L395
Bulk Rail Loaders should handle this case more elegantly. It should never be destroying an in-hand item accidentally. I'll have a look. BTW, if Bluebuild sent revived=true, it would already be handled correctly.mrvn wrote:When the bulk rail loader fails it replaces whatever I hold in my hand with the loader. The blueprint or circuit wires disappears. VERY BAD interaction between the mods. Putting the loader into the players hand temporarily would avoid this ugly bug.