Mylon's Many Mods

[Mylon]

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.

[Seth_Seth]

What's wrong with TTSFN? I updated it recently to fix some of the bugs here.

There's still no support for modded ores with storage and some not being targeted.

[Dimava]

A couple of changes for Bluebuild
Still needs a bit of testing though

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)

[Mylon]

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.

[Dimava]

Double insertion seems to be caused by Picker Extended, which also auto-inserts modules on manual grost reviving.

Last (1.1.2) version of Dirt Path throws a error in on_nth_tick(108000)

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

[Mylon]

I fixed Dirt Path. I thought I had put in a migration to stop that bug from cropping up, so I gave up on the migration plan and switched to on_configuration_changed.

[Deadlock989]

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.

[FuryoftheStars]

Can you add user settings for Bot Servicing that control the following?

• Construction bot break chance
• Logistic bot break chance
• Resource cost to repair (on/off)

Currently I feel as though Construction bots break too frequently for my tastes, while Logistic bots don't break enough (my assemblers for construction bot repair vs logistic are showing 368 vs 8, respectively). Rather than you trying to balance the numbers that makes the most number of people happy, you could just make the values editable for us in game so we can adjust it ourselves.

The resource cost to repair on/off switch is because while some of us don't play in marathon mode, we'd still like there to be at least a nominal cost to repair other than just time and energy (although I guess technically everything traces itself to time and energy, doesn't it? ).

Otherwise I'm loving this and haven't encountered any other issues with it so far.

Oh, and perhaps something that will make it so the bots won't break over belts or will at least fall on the next closest available non-belt tile? It does become a pain when they hit the belts and get sucked up into whatever system the belt feeds. If the bots could pick up broken ones from belts, then it wouldn't be so bad, but I'm guessing that's a game limitation.

[mrvn]

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?

[Therax]

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.

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.

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.

[Mylon]

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.

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.

[Mylon]

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.

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.

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.

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.

[Mylon]

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?

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.

[Deadlock989]

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.

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.

[Therax]

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.

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.

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

In fact it's not even a ghost being revived, it's being built over.

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.

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.

To truly simulate the whole operation, you'd need to raise events for the pipette and cursor_stack changes, too:

1. 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.
2. Raise on_player_pipette and on_player_cursor_stack_changed.
3. Raise on_put_item.
4. Actually revive the ghost.
5. Remove the item from the cursor stack and raise on_player_cursor_stack_changed to reflect the use of the item.
6. Raise on_built_entity.
7. Reset the player's cursor stack to its original contents, and raise on_player_cursor_stack_changed again.

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.

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

[Deadlock989]

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

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.

The adding of an additional parameter like the one Nanobots provides is second best, but at least it's throwing a bone I can catch. As long as everyone who ever raises a player build event when the player isn't building anything uses the same parameter ...

[Mylon]

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.

That's easy enough to do.

Though I did try this command out:

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)

When placing the last item, it prints nil. So cursor_stack isn't always valid during the event, even during normal build behavior.

[Therax]

If people need a bot-less bot build event, I'd say that's a feature request.

It's a good idea. It's even already implemented: http://lua-api.factorio.com/latest/even ... ised_built
Getting mod authors to actually adopt it, though, is another question.

When placing the last item, it prints nil. So cursor_stack isn't always valid during the event, even during normal build behavior.

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.

"on_built_entity" is the event Deadlock989 is interested in. It's normally raised after construction is finished, so the item is no longer in the cursor, leaving the cursor empty if the item placed was the last one, but there's a valid entity in the world for a mod to interact with.

[mrvn]

In fact it's not even a ghost being revived, it's being built over.

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.

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.

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.

To truly simulate the whole operation, you'd need to raise events for the pipette and cursor_stack changes, too:

1. 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.
2. Raise on_player_pipette and on_player_cursor_stack_changed.
3. Raise on_put_item.
4. Actually revive the ghost.
5. Remove the item from the cursor stack and raise on_player_cursor_stack_changed to reflect the use of the item.
6. Raise on_built_entity.
7. Reset the player's cursor stack to its original contents, and raise on_player_cursor_stack_changed again.

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.

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

[/quote]

I run into problems with bulk rail loaders here. The rail loader only has a partial collision mask and requires rails to be present and free space on the other side of the rails not included in the mask. So on placement those are checked and placement may fail. The way this happens is that the placed bulk rail loader is put back into the players hand.

Now with bluebuild I might be holding a blueprint in my hand. Or frequently I hold circuit wires because I need to connect things being built to existing stuff. 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.

[Therax]

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.

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.