Airships (alpha) - feedback requested

[Deadlock989]

I'm currently working on two add-ons for Industrial Revolution 3. One is still very early in development and will remain under wraps for now; I can say that it's an expansion of IR3's early game (pre-electricity). The other is almost finished and adds airships: flying vehicles which can be piloted by players or set up as automated logistics carriers using airship stations. I'll post more info about the stations and airship automation later.

Unlike the main IR3 mod, these add-ons include no commercially-restricted assets and no commercially-restricted tools were used to make them, so you can buy me a coffee if you feel like supporting their development. This is of course entirely at your discretion and the add-ons will be made available for free in any event (assuming they are actually finished).

[mussii]

Holy shit they look amazing.

[Deadlock989]

This is the current draft of the Manifesto page for airships:

This is an example of the current draft of airship station GUIs (loading instructions are toggled off in this screenshot but they look exactly the same as unloading instructions, just with slightly different tooltips):

This system might seem quirky or fiddly at first glance but it's pretty powerful once you know your way around it. It has some QOL features which trains lack (such as fuel level detection). It is also very performant: the add-on currently has no on-nth-tick scripting at all, working entirely from GUI interaction and waypoint-reached events. I have not yet tested performance with large numbers of airships but I don't have any reason to suspect it will be any worse than the same number of trains - airships have extremely simple pathfinding compared to rail networks since they're not confined to rails and don't collide with anything. Since airships are spider vehicles internally, they can also have individual names: I considered using names instead of colours as the instruction filtering mechanism but there are difficult GUI issues around that.

The remaining issues are mostly balance ones. There is a risk that airships make trains obsolete, although there are some factors that work against that: they are relatively expensive compared to trains (the lower tier of airship is late blue science and requires hydrogen to craft, the higher tier requires helium which takes time to obtain); their cargo capacity is smaller than a single cargo wagon; they are much slower than trains in most situations; they can't transport fluids unless they are barrelled; installing the add-on is completely optional if you think trains should remain the bulk cargo transfer mechanism of choice. One major advantage to airships is loading/unloading speed: they use a similar mechanism to inventory transfers, which means they can fill or empty their entire cargo hold instantaneously (but the station containers still have to be filled/emptied by conventional means). They work well for medium-distance, medium-throughput situations that are big enough for mid-game logistics bots to struggle with, but for long-distance and/or high-throughput situations (e.g. a busy iron ore mine) trains are supposed to remain superior.

[Deadlock989]

This add-on was released today:

https://mods.factorio.com/mod/IndustrialRevolution3Airships

[Deadlock989]

I would like to take Airships out of alpha soon, now that the worst bugs have come to light and been dealt with. I am OK with how it turned out although I do wonder if the colour-filtering scheme is overcomplex and whether it would have been better to have the conditions bolted straight on to the forwarding instructions.

If you have feedback or suggestions for the balance and functionality of Airships, add it here soon before the mod is marked as "done".

[ZaChr0me]

I've played with it a bit (mostly lab test to see how to make it work) and i think the color system is not as complicated as it initially appears but can make things not as clean as they could be with more "proper/unique" airships identifier (well, i've played my fair share of space exploration & aai automated vehicle, so that helps)

On the other hand, i think there are a few limitations either due to design or due to technical limits (haven't yet looked at the code to customize it and push it further) Those limitations are :

• 8 maximum commands/order per category (unloading, loading, destination)
• the color limit
• no efficient way to make a generic/hub refuelling station

Combined they cause a bit of pain when setting up separate refuelling from the loading/unloading stations. This is due to the current limitations of stations not allowing for a destination such as "go back to previous station" or something similar. It wouldn't be as bad if there wasn't a limit on commands & colors. With more colors and commands, you could at least have many many different unique color based stations that the refuelling serves specifically, or at least associate individual colors with specific destinations commands. This would be annoying to add to, as every new loader/unloader/station would require to be plugged in the system, but it would work. Right now, you're limited to 8 stations per refuelling, and in my experience/opinion, more like 4 if you want to optimize refuelling.

That said, my use case is trying to use the airships as the main transportation. It currently serves very nicely the theme of "mid game transportation of goods". I've actually been trying without success to modify another drone/air transport mod to make it similar in some aspects to this one for a few weeks. I think it's a really good addition and really fun to play around with as it's not as space hungry as trains, not as ups/"cheaty" as robots and can be scaled up nicely.

I'll try to edit the mod to check the effects of adding as many colors as I can and removing the limit of commands

[Deadlock989]

A "back to previous" destination would be pretty easy to implement - airships already remember the last station they came from.

Some of the things you mention are easily adjusted in code/data/globals.lua - fair warning, the number of instructions constant wasn't intended to be changed, it is probably safe to decrease it, but increasing it will likely lead to errors in existing saves (fixable if you remove and replace all stations). Adding more colours is easy but it will disrupt existing saves if the current colours' order changes.

[Deadlock989]

I've added "Previous station" to the forwarding instructions for the next version (0.1.5). Have not exhaustively tested it but indications are that it's working well. It does make refuelling depots a lot easier to set up.

[ZaChr0me]

Can confirm, it's just easier, and allows the color system to be more focused on logic than identifying. Thanks for the addition !

[Deadlock989]

For the next version (0.1.7) manually editing defines.maximum_filters in globals to increase the maximum number of loading/unloading/destination instructions no longer results in script errors, although it may still create minor GUI issues.

[ZaChr0me]

I am interested to know how you fixed the issue

[Deadlock989]

Currently (0.1.6) when you create a station it sets up 8 "blank" instructions for each of the three sections, but if the maximum_filters constant is then edited and a saved game is reloaded, clicking on the + button below the 8th instruction will try to index nil because the 9th instruction does not exist. The code in 0.1.7 now properly checks for a valid instruction at the new index and appends new "blank" instructions if necessary. This required small edits in three different places, two of them in the GUI creation code. It'll be released towards the end of this week.

[mybuddymichael]

Finally got these researched and I love them! Some initial thoughts:

• Creating a refueling-only station with the "Go To Previous Station" seems to work really well!
• The 25% threshold for "low fuel" seems pretty high given that these things have three slots for fuel.
• It'd be great, if possible, to be able to put item icons in the station names.
• It feels like creating multi-item stations ramps up complexity pretty hard, especially (or only?) when using a separate refueling station. Getting the color logic right feels like it has a lot of surface area for errors.

[mybuddymichael]

Oh, and it'd also be neat if the stations were configurable using Remote Configuration.

[Deadlock989]

• The 25% threshold for "low fuel" seems pretty high given that these things have three slots for fuel.

Yes, it's a tricky one. On my current playthrough it does feel a bit too high. On the other hand I have been sending them on some pretty long journeys. So the main thing is not to send them off on a multiple-kilometre round trip when they happened to have X+0.001% fuel remaining and have them run out on the way back. I might do some tests to measure fuel consumption to see if I can justify, e.g. 10%, by showing that it's enough for X kilometres of travel.

• It'd be great, if possible, to be able to put item icons in the station names.

Technically you already can but the problem with rich text tags is that they eat up characters. There needs to be a character limit to prevent station data eating up memory and people assigning names with silly lengths in multiplayer, but a single item icon like [img=item/copper-plate] eats 23 of them. I suppose it would be possible to script an upper max length for everything including rich text but then also have a lower limit on characters outside of rich text tags, but that would mean a lot more validation which means more UPS used by the validation every time you type into the edit box.

• It feels like creating multi-item stations ramps up complexity pretty hard, especially (or only?) when using a separate refueling station. Getting the color logic right feels like it has a lot of surface area for errors.

I agree. So far I've only had a couple of ships running multi-item loops to supply small crafting areas that would have required unreasonable spaghetti otherwise. It felt a little awkward to set up.

Oh, and it'd also be neat if the stations were configurable using Remote Configuration.

Can you elaborate here? I don't know RC very well. At the moment you can open any station GUI by clicking on the station at any distance, including in map view (as long as you have line of sight e.g. from radar), even though the station highlight is red (can't do anything about that).

[mybuddymichael]

So the main thing is not to send them off on a multiple-kilometre round trip when they happened to have X+0.001% fuel remaining and have them run out on the way back.

That makes sense. All my routes have been really short so far. Probably better to be a bit careful with fuel reserves. But I could also see just building multiple and closer refuel stations in a several locations.

Technically you already can but the problem with rich text tags is that they eat up characters.

Oh wow, I somehow didn't know about rich text tags! And that validation sounds like a lot of effort for such a little feature!

At the moment you can open any station GUI by clicking on the station at any distance, including in map view (as long as you have line of sight e.g. from radar)

This is an interesting one! Remote Configuration lets you do what you can do here with airship stations via the map but with anything configurable (like combinators or building rotation). But Remote Configuration seems to interfere with this mod's map-based click-and-configure for airship stations! That's why it wasn't working for me. I disabled RC and I can indeed configure my airship stations from the anywhere on the map. So that's now an interesting conundrum. Do I keep everything else configurable from the map (via Remote Configuration)? Or disabled RC and just have my airship stations map-configurable?

[Deadlock989]

I can reproduce that behaviour with RC installed. I would report it to Xorimuth, the author - seems like an oversight that it would prevent other mods from opening their GUIs remotely. Edited to add: I'll report it myself, I can see where the problem is.

With rich text in station names / long station names, I took a look at what vanilla does for rail station names and also map chart tags (airship station names on the map have to use a regular map chart tag as that is the only way the API provides for getting any text or symbols on the map). I was surprised to find out that they are allowing very long names/tags, up to 1024 characters - they are usually truncated with an ellipsis in the game (although chart tags pretty much cover the width of the screen). I'll increase the limit in Airships so that you can have at least a couple of rich text tags and a decent length text name. Edited to add: had to row back on this considerably. Played with it for an hour and there's just so many ways it can break things if station names are allowed to be long, because they are shown in a lot of places (text fields, headers, dropdowns) and the GUI font is variable-width. I'm going to leave this alone until the API has proper rich text support for text input fields. I could only safely increase the limit from 32 to 40.

Regarding native support for the little "picture" helper button you get in vanilla GUI name edit fields that pops open a "Select icon" menu for you, access to this isn't currently provided by the API, so manually entering rich text tags is the only way for the time being.

[Deadlock989]

Regarding the 25% threshold for "fuel low". I just did some tests with airships undertaking a scripted 10km journey, which is a very substantial distance for typical games:

There were some wrinkles around fuel value density for full stacks of different fuel types (barrels are currently a very poor choice which is something I hadn't fully appreciated) but the TL;DR is that I think it's only safe to reduce the threshold to 20%, which would just about support routine 20km round trips (10km there, 10km back) with all of the worst options (hydrogen airships with petroleum barrels). For bigger trips, better to unconditionally stock with fuel.

An alternative would be to not use item counts over stack size as the measure but to calculate the actual fuel value carried. But that opens up new dilemmas. The test suggest that hydrogen airships with the lowest speed bonus from fuel need just under 144 MJ for a 20km round trip (i.e. equivalent to the 20% threshold above, but only for barrels). However for high octane fuel that would be literally 1 canister, which is obviously too low a threshold.

[mybuddymichael]

Quite a trip! I'm curious now, in your own playthrough are you finding airships a replacement for trains? I'm still trying to get a feel for where they fit in the logistical toolbox.

[mybuddymichael]

And, as a side note, the "return to previous station" destination is such a great addition! I'm finding it very useful with single, rich providing stations that multiple requesting stations source from. I just set the provider to "return to previous station," and then I can set up an arbitrary amount of request stations without any extra work at the provider.

[Deadlock989]

Quite a trip! I'm curious now, in your own playthrough are you finding airships a replacement for trains? I'm still trying to get a feel for where they fit in the logistical toolbox.

No, not entirely, but they are definitely proving useful. I'm currently in late purple science in a 10x technology cost playthrough with very low ore frequency, which is starting to get quite painful (Electronics 3 will cost 9000 science). The base can run 150 science/minute most of the time. The only thing I'm supplying entirely with airships is tin ore. They are also supplementing iron ore from an island about 1km away that I didn't want to landfill rails to, but it wouldn't currently keep up if that was the only source of iron (it might if I doubled the number of airships doing the route). Within the base they are running a few spaghetti-avoiding supply jobs that you'd usually use bots for in the late game, but hydrogen is available way way earlier than requester chests in this scenario.

[mybuddymichael]

Ah, yeah, those cross-ocean flights would be useful! I'm finding them wonderfully helpful for dealing with my spaghetti, pre-requester chests, in places where the value-to-effort ratio just doesn't make sense for trains or belts.

[mybuddymichael]

If I'm seeing things right, it looks like "Circle and return" overwrites the "Previous station" destination so that the previous station becomes the station the airship is circling. That was surprising! I expected the previous station would continue to be the station that the airship came from, even after circling for a bit.

[Deadlock989]

If I'm seeing things right, it looks like "Circle and return" overwrites the "Previous station" destination so that the previous station becomes the station the airship is circling. That was surprising! I expected the previous station would continue to be the station that the airship came from, even after circling for a bit.

This was hopefully fixed in 0.1.8, let me know if there are any other unexpected behaviours.

I'm planning on taking the mod out of alpha next week (Friday 26 January).

[slaymaker1907]

They are really fun, though a couple of things I noticed:

• Both airships are convenient, though I'd like it if there was either an airship that is a bit faster yet still just a little than Spidertron with exoskeletons.
• A hot air balloon that unlocks even earlier than the base ship would be cool and silly. I just really like not needing to deal with collisions.
• I'd love to have this vanilla. Dealing with a dense base is such a PITA and these seem way more balanced than the more popular aircraft mod. Anything better than or equal to Spidertron should cost the same or more in terms of research.

[Deadlock989]

A hot air balloon that unlocks even earlier than the base ship would be cool and silly. I just really like not needing to deal with collisions.

The very first design of the model was actually a bronze steam-powered airship, this was an early render:

I did want to have 3 tiers of ship, but a few things made me abandon it. Firstly, vehicles with colour masks look really bad for about 75% of the colour wheel if the main structure of the vehicle isn't monochrome - this is why monowheels and the heavy roller never got a colour mask, but airships need to be colourable because that is what the routing is based on. Then, vehicles need sprites for at least 64 directions so they are one of the largest hogs of the sprite atlas / VRAM (trains consume a huge amount). But the real killer was that I just couldn't make it work with the tech tree.

[Cadams111]

If only the color was the only problem… I’m just imagining it trailing a brightly colored banner behind it. That would look pretty sweet.

[Deadlock989]

Airships is now out of alpha as it seems pretty stable.