[MOD 0.12.30] Automatic Belt Planner (old version archive)

[prg]

Would be an improvement. But not exactly what I would like. I imagined something more like how the v0.13 rail laying is shown to work in the one of the FFF's.
GIF in the bottom of the post: http://www.factorio.com/blog/post/fff-114
The path that will be used is shown in green just like a blueprint, and updates automatically when you move the mouse to new tiles when you are choosing where to place the end marker. No confirmation dialogue would be necessary then.

Having a live preview of the path would certainly be great, but that won't be possible for now I'm afraid. There is no on_mouse_moved event and no way of querying which tile the cursor is currently over I'm aware of so that this could be done in on_tick. Also it would most probably be way too slow to be usable with the current Lua implementation for any kind of reasonably useful path lengths anyway.

Instead of choosing which belt is placed with the confirmation dialogue you would then have the option in a toolbar at the top of your screen like many other similar tools.
Examples: Filtered deconstruction planner: viewtopic.php?f=97&t=19548&
If you are going to place a lot of belts one ofter another with this tool you don't want to press ok after every single belt segment construction.

Yeah I wanted to simply re-use the "Belt planner running" box in that corner as a "The belt planner has found you a path!" notification thing so it wouldn't interrupt gameplay when it popped up. You'd still need to click an accept button or there could be no preview.

Another idea: The lowest underground belt avoidance level still prefers belts over underground belts. Maybe add a level that uses underground belts for all straight paths where the underground distance is >0. Sometimes I prefer to use normal belts only for trivially short straight paths (<=2) because I don't get moved around by the belts as much then. Also I've heard that underground belts are better for performance reasons so megafactory builders would also prefer a "normal belt avoidance"-level.

That sounds useful. Now the configuration dialog is starting to get cluttered, hmm...

[prg]

Okay, this took a while, but I think v0.5.0 should improve usability regarding these issues as much as currently possible.

No more "oh no, not like *that*" moments anymore thanks to the new preview with undo feature that lets you decide if you like a path or not before placing ghosts.

Only a single belt planner item that shouldn't have trouble any longer finding its way back to its proper quickbar position.

Less clicks required to manually build a path in multiple steps with the continuous build mode. You still need to accept the suggested path by clicking a button in the GUI or there could not be a preview. After that you can place the next end marker right away to continue building from the previous end position.

Also, since there's an attachment limit of 10/post and I want to keep the old versions in the first post around, I'm going to use this post as an image dump.

image dump

beltplanner-start.jpg (114.05 KiB) Viewed 4695 times

beltplanner-running.jpg (107.55 KiB) Viewed 4695 times

beltplanner-finished.jpg (125.58 KiB) Viewed 4695 times

beltplanner-cont.jpg (118.52 KiB) Viewed 4695 times

config-gui-050.jpg (27.99 KiB) Viewed 4695 times

avoidance-050.png (370.98 KiB) Viewed 4695 times

length.jpg (94.19 KiB) Viewed 4695 times

accept-underground.jpg (27.49 KiB) Viewed 4695 times

prefer-straight.jpg (117.94 KiB) Viewed 4695 times

[prg]

Minor bug fix release. Just hope I didn't break five other things with this. Wish I had a proper test suite when doing these kinds of changes.

[Afforess]

Minor bug fix release. Just hope I didn't break five other things with this. Wish I had a proper test suite when doing these kinds of changes.

I've used luacheck and lua busted with some success in testing factorio code. It involves a fair amount of mock objects though, which is annoying. See the Factorio Standard Library project if you are curious.

[prg]

I've used luacheck and lua busted with some success in testing factorio code. It involves a fair amount of mock objects though, which is annoying. See the Factorio Standard Library project if you are curious.

Huh, thanks, that's interesting. But creating all those objects for a reasonably sized fake factory in a known-problematic configuration in a text editor does sound like quite a bit of work indeed...

[Zeblote]

Also, you're not following the mod posting rules.

Good. That standardised topic is ugly and useless.

[Qon]

Also, you're not following the mod posting rules.

Good. That standardised topic is ugly and useless.

In your opinion. Some would disagree.

[GameCharmer]

Just gave this a shot and it works great! Would it be possible to add custom belts in the future? I'm still learning LUA, but there should be a way to iterate belts and potentially build an array of speeds / underground lengths. I'll help where I can.

[prg]

Just gave this a shot and it works great!

Glad to hear that!

Would it be possible to add custom belts in the future? I'm still learning LUA, but there should be a way to iterate belts and potentially build an array of speeds / underground lengths. I'll help where I can.

This should be possible somehow, yes. But I don't see an easy way of getting at the max_distance of the underground belt prototype from control.lua, so would need to create a fake technology or some kludge like that per belt type which could be read at runtime (or maybe make a modding interface request.)

Also there doesn't seem to be any connection between above- and underground belt types so it could be automatically figured out which types to place together. The base game just appends "-to-ground" for the underground types, but mods could name them whatever they wanted. So just looking for that string at the end won't be enough, some mod might decide to add something like "-mk2" to the name and this approach would already break. To make it work generically, the user would need to select above- and underground belt types separately. This would already need to happen before path finding starts, since the path finder would need to know how long it can make the underground sections.

So yeah, this seems possible, just a bit awkward to implement right now.

[GameCharmer]

This should be possible somehow, yes. But I don't see an easy way of getting at the max_distance of the underground belt prototype from control.lua, so would need to create a fake technology or some kludge like that per belt type which could be read at runtime (or maybe make a modding interface request.)

Also there doesn't seem to be any connection between above- and underground belt types so it could be automatically figured out which types to place together. The base game just appends "-to-ground" for the underground types, but mods could name them whatever they wanted. So just looking for that string at the end won't be enough, some mod might decide to add something like "-mk2" to the name and this approach would already break. To make it work generically, the user would need to select above- and underground belt types separately. This would already need to happen before path finding starts, since the path finder would need to know how long it can make the underground sections.

So yeah, this seems possible, just a bit awkward to implement right now.

Just thinking out loud, since I don't know much about LUA, nor how the control script operates, but I may have an idea. What if you could use a data-fixes / final-fixes script to read the belts and attach an array of name/length as a new property to the belt placement item? When using it, would it be possible to read that extra property to generate the display? It's a very hacky way of doing it and I have no idea if it's even possible. I'm a PHP programmer and do something similar to this to get around a rigid form construction class.

[prg]

Just thinking out loud, since I don't know much about LUA, nor how the control script operates, but I may have an idea. What if you could use a data-fixes / final-fixes script to read the belts and attach an array of name/length as a new property to the belt placement item? When using it, would it be possible to read that extra property to generate the display? It's a very hacky way of doing it and I have no idea if it's even possible. I'm a PHP programmer and do something similar to this to get around a rigid form construction class.

If it was possible to read random prototype attributes from control.lua I could just read max_distance directly. But only values made available through LuaEntityPrototype/LuaItemPrototype can be accessed at runtime, user-defined attributes from the data loading stage are simply lost. Hence the even more hacky idea with the fake technology, this way user-defined strings and integers could be passed to control.lua via the effects array of LuaTechnology.

[triggerman602]

I don't know if this has come up yet but the pathfinder really needs to avoid belt ends to avoid items spilling onto the new belt.

[prg]

I don't know if this has come up yet but the pathfinder really needs to avoid belt ends to avoid items spilling onto the new belt.

No, this hasn't been mentioned yet, but it would be a useful addition. Now how to implement this without totally ruining performance with four find_entities_filtered calls per open set element... (won't happen soon, am a bit busy at the moment)

[prg]

New version got its own thread since I've hit the attachment limit again.

image dump

config-gui-060.jpg (45.83 KiB) Viewed 4403 times

avoid-belt-endings.jpg (53.48 KiB) Viewed 4403 times

avoid-resources.jpg (45.56 KiB) Viewed 4403 times