requests regarding transport lines and belts

[Impatient]

hi devs, hi modders!

i am suggesting the following api-improvements/api-changes regarding transport lines and belts:

a)
read access to belt speed.
i moved this one to its own request thread: viewtopic.php?f=28&t=23187

b)

Code: Select all

LuaTransportLine.get_content_entities :: dictionary float → LuaItemStack

where the key/the float ranges from 0 to 1 and signifies the position on this piece of transport line. The key to be the position on the line is crucial for us modders to be able to work by the principles of FIFO. I request the value to be LuaItemStack as i read and tested, that items on a belt can also be stacks of items. I dont know if single items are also a stack of size 1 or a LuaEntity. If so, the value can be either a LuaItemStack or a LuaEntity. Does not matter. Anyhow i request access to the entities of the items on the line, which are inaccessible at the moment.

c)

Code: Select all

LuaTransportLine.extract_content(LuaItemStack)

This would extract the entity of a stack/item from the contents of a transport line and thus the item visible in game. The entity of the stack/item shall continue to exist, so it can be used somewhere else programmatically.

d)

Code: Select all

LuaTransportLine.insert_content_at_position(LuaItemStack, float)
and
LuaTransportLine.insert_content_at_back(LuaItemStack)

where the float again signifies the position on this piece of line with a value ranging from 0 to 1. this will allow to insert an existing stack or item entity into the line.

e)

Code: Select all

LuaTransportLine.halt_at_position(float or nil)

AND one of the events

script.on_transport_line_halting_position_set(LuaTransportLine, float or nil) (implemented as globally visible event)
or
LuaTransportLine.on_halting_position_set(float or nil) (implemented as event attached to a specific transport line entity)

where the float again signifies the position on this piece of line with a value ranging from 0 to 1.Items will not be moved beyond this position on the transport line. nil signifies that the position was unset, ending any halting on that transport line. Please note, that i only request the method and the internal implementation to set that position and halt item flow there. I do not request the game engine saving this position/flag for every transport line in game. We can do that in the mods save data, when we subscribe to the associated event. and we can set it in on_load.


motivation:
opening up access to the entities on a belt, extraction and insertion, would allow a lot of new things to be done in mods. Items shuffled around on belts, between belts, from belts to other modded entities and back to belts. item flow halted when conditions are met or not. with the speed setting readable, the modded entities can adapt to the belts connected to them. (they easily could be modded belt entities with non-stock belt speeds. what to do then, if the speed is unknown?) and - imo very important - the mods can set its calculations to be performed only every n-th tick (depending on the speed of the belt) to keep strain on the game engine as low as possible.

What do you think?

[lyravega]

a) Can be used to make "smart belts"; belts with controllable speed! I'm all in for this

b) There is a function to get the belt contents, isn't there? edit: "LuaTransportLine.get_contents()" but this do not return any position information directly. However, this can be combined with "can_insert_at(position)" (or "can_insert_at_back()") to achieve more or less the same effect, or calling position stuff on the items themselves.

c) I'm not sure what you mean by this. What do you mean by extract, exactly?

d) Again, there exists "LuaTransportLine.insert_at(position, items)" and "LuaTransportLine.insert_at_back(items)". Though items are SimpleItemStack, so any details will be lost in the process.

e) Not sure about this, even though you explained your motivation, it didn't click on my head. Probably because I'm more of an inserter guy

[Impatient]

hi,
thanks for your feedback on my suggestions. it showed me where i need to clarify my request and i hope for a lot more questions and feedback, which would help to mature this api-request.

a) Can be used to make "smart belts"; belts with controllable speed! I'm all in for this

currently i am just asking for a readable property. this would allow for modded entities to adapt to the speed of a belt. implementing a writeable property would open up even more possibilities as you say.

b) There is a function to get the belt contents, isn't there? edit: "LuaTransportLine.get_contents()" but this do not return any position information directly. However, this can be combined with "can_insert_at(position)" (or "can_insert_at_back()") to achieve more or less the same effect, or calling position stuff on the items themselves.

the current implementation allows just for seeing how much of what type is on a transport line. to effectively handle what is on a line the position, stack size and health status is missing. the position is necessary to work by the principles of FIFO. meaning, if i want to process the items on a belt in FIFO order i would have to know in what sequence the items are on the TL. this is currently not achievable.

... or calling position stuff on the items themselves.

exactly my point. the position of the stack can only be discovered if the programmatic entities of the stacks on the belt, namely the objects of type LuaItemStack can be accessed through the api. the functions in LuaSurface (find_entity, find_entities and find_entities_filtered) currently do not detect items on belts/TL. (if i look a t older mods which do not work anymore, i can see this functionality once also worked for items on belts, but it seems it was removed in recent versions of the modding api).

the stack size of items on the TL is necessary to handle them in the way they are stacked. eg, there is a stack of 100 items and another stack of 20 items of the same type on a TL. if i use the current function get_contents i just know there are 120 items on the TL. this could be 2x60, 4x30, or a lot of other combinations. via the current api it just can not be discovered what the stack sizes are.

the health value also can not be discovered through the current api. for that also access to LuaItemStack is necessary. it has the health property.

conclusio: access to the LuaItemStack objects on the TL is necessary to work with the items on the TL. any other way it is just a game of (mis)guessing and unsatisfying results.

c) I'm not sure what you mean by this. What do you mean by extract, exactly?

i did the following test: i built and placed a chest, shot it, so it was not at 100% health, picked it up and put it on a belt, which was 2 units long. as expected, when i picked it up at the end of the 2nd belt unit, the chest had still the same, lowered health value. this led me to the assumption, that internally the belt system uses LuaItemStack objects for handling items on TL and when passing them from TL of one belt to the TL of the next belt. sure, this is an assumption. but anyhow, all the values i want access to, are stored and used internally. health value, stack size, etc ... otherwise the belt transportation system would be an unreliable, buggy mess. now, if i want to take an item from the belt and put it say into a chest, by means of my modded entity, i want access to the programmatic object, that stores the information about type, stack size, health and position. again i assume it is a LuaItemStack object as it fits the necessities perfectly. then i have this object in my mods code and can do whatever i want with it. eg - put the items from this stack into a chest. the current function remove _item, removes them from the TL and they are gone from the game world. deleted, destroyed or whatever you want to call it. so i say "extract" to distinguish the functionality.

d) Again, there exists "LuaTransportLine.insert_at(position, items)" and "LuaTransportLine.insert_at_back(items)". Though items are SimpleItemStack, so any details will be lost in the process.

exactly, the details would be lost in the process. eg, i want to be able to take the LuaItemStack object (which i extracted from one TL) and insert it into another TL. with all its specific values of stack size, health and type. or another example: i want o be able to take the item with 50% health from the chest and put on the belt. as of now it can not be done.

e) Not sure about this, even though you explained your motivation, it didn't click on my head. Probably because I'm more of an inserter guy

this feature is, as the speed property feature not that closely related to the handling of items on a TL. i am just thinking it can be very handy for modded entities. think of this: i am creating a modded entity which is 3x3 in size and has a 1x3 belt running through it. and it does something with the items on the belt. maybe i want to pause (halt) item flow on the belt for some reason until some condition is met. currently it just is not possible. a more specific example can be a mod that introduces a piece of belt, that allows item flow, based on circuit network conditions.

Probably because I'm more of an inserter guy

did you mod something with inserters?

[lyravega]

e) Not sure about this, even though you explained your motivation, it didn't click on my head. Probably because I'm more of an inserter guy

this feature is, as the speed property feature not that closely related to the handling of items on a TL. i am just thinking it can be very handy for modded entities. think of this: i am creating a modded entity which is 3x3 in size and has a 1x3 belt running through it. and it does something with the items on the belt. maybe i want to pause (halt) item flow on the belt for some reason until some condition is met. currently it just is not possible. a more specific example can be a mod that introduces a piece of belt, that allows item flow, based on circuit network conditions.

Probably because I'm more of an inserter guy

did you mod something with inserters?

Hmm, I see your point now. From my personal experience, I use long belts and anything that stops them would stop my entire output. But thinking outside (my) box, I can see that it can be used to halt production on certain belts, and also allow less smart inserter usage by using these "smart belts". They won't exactly be smart, but halting them in right time/place would effectively allow you to use them like some sort of smart-belt system. And yep, I have an inserter mod

[Impatient]

moved

a) read access to belt speed.

to its own request thread: viewtopic.php?f=28&t=23187