raiguard / factorio-infinitymode Goto Github PK

Suddenly auto-construction on blueprints is not working in 0.17.67. Was working fine in .66. I'm not able to enable it either as the check-boxes are disabled.

Screenshot -

"Failed to load mods: Error while loading item prototype "super-productivity-module" (module): Key "limitation_message_key" not found in property tree at ROOT.module.super-productivity-module Modifications: Infinity Mode > Krastorio

Attempting to change the mode or priority of an infinity accumulator causes a crash with this error.

Looks like the refresh_ia_gui function needs to be moved above the change_ia_mode_or_priority function in order to not resolve to nil.

How to reproduce: remove the hidden tags from loader items.

data.raw.item.loader.flags = {}
data.raw.item['fast-loader'].flags = {}

Place a loader as if it is unloading an entity. Use an upgrade planner to change it to an other loader.

Result:
https://i.imgur.com/cV8cotM.mp4

The unloader swaps its belt and chest side, and becomes a dysfunctional loader.

As is in the title. Steps to reproduce:

1. Request anything.
2. Take the items you requested, and manually pick them up (so they are in your cursor stack).
3. Drop the items in the trash slots.

The requested items do not come back until you change the request amount. This same problem does not occur if you shift-click the items to the trash slots: that works as expected.

When deconstructing a infinity locomotive (with bots or by hand) converts the locomotive to a normal locomotive.

The loco forgets that it is infinite. ^^

In certain cases the icon of "infinity pump" is replaced by the icon of "infinity pipe".

This happens when the user:

• selects or sets a filter in a deconstruction planner
• selects or sets a filter in a upgrade planner

this does not happen when:

• creating a blueprint (neither in blueprint-icons nor the list of bluprint-items)
• setting filters in a cargo wagon
• setting filters in a logistic chest

example DeconPlanner:
0eNptj+sKgzAMhd8lvyvoJhP7KmMU0TjK2lTaOCbSd192Y8j2L/nOyeWsMGAfKHGce7aBzOQ6IoygV0jIbOmcHjUSW17MaB1jND4MCLpUWyzG4wrUedHA0mhJtGKyE4KSfsCbzGT1xzL76Wup8kkBR8RkOhpMDP0lmUBuAT12LqGI1uHPK0+Y0OErx5tnWcvo5do2Z/HJqeAqnwsB3ezLqq13dXNoc74Dh9RkWQ==

No Error:

I have IM installed so that I can work out things in my test world and then move to my primary world. My movement speed is insane in my primary world, but changing the movement modifier to anything else has no effect and is reset to 2 as soon as I close the window. I would like to be able to disable IM on my primary world altogether, but I also do not see that as an option.

After disabling IM and reloading my primary world, my inventory size and base speed are both completely screwed up. I'm really not sure what to do here because I don't have a backup of my world and the autosaves are for my test world. Are there some fields that I can change through the command line to reset everything?

I opened a thread on the mod page, but will close in favor of this.

After experimenting with the infinity loaders for awhile, I've noticed several abnormal behaviors in the snapping/belt type logic. (I've attempted to provide screenshots when possible, but I haven't actually tried linking images in an issue before, so hopefully it works.)

1. When a loader set to input mode tries to change belt type, the loader changes direction instead of switching to output mode. (Before/After)

2. Existing loaders don't respond to placing/rotating splitters despite the placement code specifically checking for them. (Before/After)

3. Placing loaders facing the sides of splitters can trigger a change in belt type despite the belts not connecting. (Before/After)

4. No checks are made for regular "loader" type entities at any point.

For 1, I've determined that the update_loader_types function is the source of the issue, but I'm not sure which line is causing the effect. Switching the order of the calls to update_loader_types and snap_to_belt in the on_built_entity listener seems to solve the problem, but the underlying bug should still be investigated.

Regarding 2, 3, and 4, it might be possible to solve all three by switching some of the logic to use the belt_neighbours entity property that was added in 0.17.59. This property only returns adjacent belt-related entities that have actually formed a connection, thus preventing 3 by default.

https://imgur.com/a/tV7gZDk

Factorio ExtendedPlus

mk1 - mk2 belts/undergrounds/splitters and deadlocks loaders are affected

When taking a "infinity personal roboport" out of a equipment grid the item converts to a normal "personal roboport mk2".

Tested with vanilla power armor mk2.

I tested a design, wanted to deconstruct it and the game crashed and sent me back to the main menu.

I then loaded an autosave and tried to remove the accumulator by hand, crashed again.

I shot at it with a nuke, crashed.

Tried it with the accumulator being connected and disconnected from any power network; no difference.

I opened and closed the menu of it, tried to deconstruct it again and it worked fine. huh...

See the picture below:

If Bob's equipment is present, it changes the icon of the personal roboport equipment to a different icon that is 64x64 in size instead of 32x32. Since in your "infinity-misc.lua" you set the icon_size of the infinity-personal-roboport-equipment to 32, this leads to the above situation. I think this could be easily resolved by changing the icon size to be data.raw['item']['personal-roboport-equipment'].icon_size.

As per the title, using the deconstruction planner on infinity loaders doesn't completely remove them. See attached images.

Not sure if this applies to other modded items as well.

Image 1 - "Ghost" infinity loaders
Image 2 - Error it gives when placing something on top

When creating blueprints of infinity logistic chests (storage, buffer & requester) the blueprint only saves the configuration of the infinity filters tab.

problem does not occur with passive- & active provider chests since they only have one tab.

example blueprint:
0eNq1lNGOgyAQRf9lnjFRa7cpv7JpDOrokii4MNiaxn9f0Idt2pq02fXJAJc794xkrlC0DnsjFQG/giy1ssA/r2Blo0Qb9mjsEThIwg4YKNHNK1VLJWmMyi+0FImS5IBRb/QgKzQwMa+o8AI8mdi7Zr2wdsUtnU4MUJEkiUvOeTHmynWFV/JkzdSSNqJBX7TX1l/XKsTxltGewQg8nossV3KLRFI1NkgMdnrA3PmzltBglYfw/oiMQwbL7pLlvrJ1hSUx12JQahd6vI8ZdLoKOrz4trUj3PTqNIV23TGla0yFq2sveETabYZUCtPo6CyaPzLt1pgMfjv/fYqVbIfln71XlaFaZHSh6Zcuid/Hy15+2w+U6WaQdetk9Q//bv/qFHhgyzZj613XP4USFLUoLN1R+TEyzyB+M/8YDN5+TnvYxckxS7PDx3GafgBhH8zo

source of blueprint (infinity buffer chest):

Sometimes, as I place a blueprint or paste something, my save crashes with the following error:

Error while running event InfinityMode::on_tick (ID 0)
LuaEntity API call when LuaEntity was invalid.
stack traceback:
	__InfinityMode__/scripts/util/conditional-event.lua:52: in function 'handler'
	__stdlib__/stdlib/event/event.lua:315: in function 'pcall'
	__stdlib__/stdlib/event/event.lua:335: in function 'dispatch_event'
	__stdlib__/stdlib/event/event.lua:413: in function <__stdlib__/stdlib/event/event.lua:369>
stack traceback:
	[C]: in function '__index'
	__InfinityMode__/scripts/util/conditional-event.lua:52: in function 'handler'
	__stdlib__/stdlib/event/event.lua:315: in function 'pcall'
	__stdlib__/stdlib/event/event.lua:335: in function 'dispatch_event'
	__stdlib__/stdlib/event/event.lua:413: in function <__stdlib__/stdlib/event/event.lua:369>

I'm on factorio version .17.68 and Infinity mode is version 0.5.0

I get the following messages when I try to use an infinity loader with any of the Bob's belts:

Unable to identify belt type. Please report the following information to the mod author via GitHub or the Mod Portal:
belt_name='ultimate-transport-belt', parse_result='ultimate'
belt_name='turbo-transport-belt', parse_result='turbo'
belt_name='basic-transport-belt', parse_result='basic'

From what I can tell, this is a load order issue: what happens is that your mod loads first and you create the infinity loaders in the data phase, but then Bob's Logistics loads after yours and creates its belts in the data phase after yours, so you miss Bob's belts when you create the loaders.

Here is a snippet of my log that shows what is going on:

When creating a blueprint of a infinity wagon the settings of the wagon are not saved.

When building the blueprint, the infinity wagon is placed without settings.

Failed to load mods: Error while running setup for entity prototype "infinity-chest-active-provider" (infinity-container): next_upgrade target (logistic-chest-active-provider-2) must have the same bounding box.

http://prntscr.com/py4mhf
Seems like a minor compatibility issue with the Subterranean mod? It adds underground belts and pipes that uses pipes or belts for whatever length you want them underground as opposed to a fixed value. Thanks for your mod, its a bit better than creative mode.

i got this erromessage:

The mod Infinity Mode caused a non-recoverable error.
Please report this error to the mod author.

Error while running event InfinityMode::on_player_setup_blueprint (ID 68)
LuaFluidBox API call when LuaFluidBox was invalid.
stack traceback:
[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:71: in function 'val2str'
[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:95: in function 'val2str'
[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:95: in function 'val2str'
[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:119: in function <[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:15>
(...tail calls...)
InfinityMode/scripts/infinity-wagon.lua:105: in function 'handler'
stdlib/stdlib/event/event.lua:315: in function 'pcall'
stdlib/stdlib/event/event.lua:335: in function 'dispatch_event'
stdlib/stdlib/event/event.lua:413: in function <stdlib/stdlib/event/event.lua:369>
stack traceback:
[C]: in function '__len'
[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:71: in function 'val2str'
[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:95: in function 'val2str'
[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:95: in function 'val2str'
[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:119: in function <[string "local n, v = "serpent", "0.30" -- (C) 2012-17..."]:15>
(...tail calls...)
InfinityMode/scripts/infinity-wagon.lua:105: in function 'handler'
stdlib/stdlib/event/event.lua:315: in function 'pcall'
stdlib/stdlib/event/event.lua:335: in function 'dispatch_event'
stdlib/stdlib/event/event.lua:413: in function <stdlib/stdlib/event/event.lua:369>

i'll do some research. the number of the BP seems low - it could be an old one.