Friday Facts #388 - Smaller things for 2.0

Regular reports on Factorio development.
Post Reply
User avatar
Dev-iL
Filter Inserter
Filter Inserter
Posts: 300
Joined: Thu Jul 02, 2015 2:48 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Dev-iL »

Qon wrote: ↑
Sat Dec 09, 2023 8:42 pm
Even if it's multiplayer, the game is written in C++, a compiled language. They can't do unsafe eval() even if they wanted to, unless they add a non-sandboxed Lua with full computer access or include a compiler to run the input, both things are hardcore attempts at engineering a vulnerability. Can't accidentally happen.
If it happens accidentally then it would be something like a buffer overflow, but then it doesn't really matter that much if it's a text field, number field or a calculator field. And as you said, they know how to sandbox mods, why would they not be able to handle something orders of magnitude simpler?
Just a reminder - https://www.cvedetails.com/cve/CVE-2017-11615/:
A sandbox escape in the Lua interface in Wube Factorio before 0.15.31 allows remote game servers or user-assisted attackers to execute arbitrary C code by including and loading a C library.
Leading Hebrew translator of Factorio.

Adam_v_R
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sat Apr 20, 2019 1:07 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Adam_v_R »

Hi, Great to see that the Factorio Dev Team's heart and mind will never cease to be where it is ought to be:)
One tiny thing falling under the "manual task" curse word, that I've just encountered and thought this would be the perfect thread to bring it up:
upgrading Level 2 Assembling Machines with 2 green cards in them might want to also add a third by default...
In case such a thing already exists but I may have missed on it, please do not hesitate enlightening me!!

mrvn
Smart Inserter
Smart Inserter
Posts: 5709
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by mrvn »

Dev-iL wrote: ↑
Sat Dec 09, 2023 7:15 pm
Regarding the number parsing... I'm surprised nobody mentioned this before, but the most interesting activity about this for me would be trying to break the game via code injection. Who knows, naybe there's a CVE lurking around the corner ;)
You know there are such tings as parser generators that take a grammar and output code that doesn't have vulnerabilities. There are even c++ templates for such things as parsing a simple math expression. I'm not scared of a text field having a code injection bug. Compare them to all the rest of a savegames data and mods.

DodoBello
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sun Jan 23, 2022 2:32 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by DodoBello »

Thank you for improving the sorting of savegames. I've always wanted some kind of folder structure or tree structure for the save games. In other words, a fold-out list element aka [+] of all save games that result from the same game start, so that the entire list is significantly shorter and more organized. Roughly comparable to the conversation view on email clients.

User avatar
raiguard
Factorio Staff
Factorio Staff
Posts: 452
Joined: Wed Dec 13, 2017 8:29 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by raiguard »

pancreas wrote: ↑
Fri Dec 08, 2023 6:48 pm
Love the FFF and this one does not disappoint. Read through the suggestions that this one sparked and I love most of those too!

As a fan of Factorio and of Lua, I was very slightly sad to see that they aren't upgrading to 5.4. I'm pretty sure there isn't much in 5.4 that would have a direct impact on users, but I would venture to make a strong guess that many of the features between 5.3 and 5.4 would benefit Factorio overall, and therefore users and moders indirectly (probably directly for moders):
  • Performance Boost with Integer Type (Lua 5.3): The introduction of an integer type can optimize calculations, particularly beneficial for math-heavy operations in game mechanics. I'm sure team Factorio is doing their own optimizations here, but it's better to use the heavily optimize code already in 5.3, IMHO.
  • Efficient Data Manipulation with Bitwise Operators (Lua 5.3): Native support for bitwise operations can enhance performance in handling game state, map data, and binary data operations.
  • Enhanced Internationalization (Lua 5.3): Basic UTF-8 support allows for better global player engagement and accessibility.
  • Intuitive Integer Division (Lua 5.3): The // operator simplifies integer divisions, often used in game logic, reducing potential errors.
  • Improved Memory Management (Lua 5.4): A generational garbage collector offers more efficient memory usage, crucial for long gaming sessions and complex simulations.
  • Advanced Debugging and Maintenance (Lua 5.4): The new warning system and improved debugging API facilitate easier troubleshooting and code stability, enhancing overall game reliability.
  • Optimized String and Table Handling (Lua 5.4): Enhanced functions for processing strings and tables can lead to faster script execution.
  • Automatic Resource Management (Lua 5.4): The introduction of close variables and the __close metamethod helps in preventing resource leaks or resources that don't get released efficiently, ensuring efficient resource usage during gameplay.
I'm also curious about what bugs they found in 5.2 and if those bugs were reported to PUC Lua team.

Of course, you have to decide what's worth doing and what's worth saving for later, and what doesn't matter enough to do at all. I can't argue with the quality of Factorio, so this isn't a complaint or wish as much as just me spouting an opinion.

Very much looking forward to 2.0 and, in between, to the next FFF!
Sorry for overlooking this. A lot of those things do sound appealing, but when you consider the time cost of upgrading to Lua 5.4, porting over our customizations, and testing for desyncs, in comparison to the benefits that we would receive, it isn't worth it right now. I'm not saying it's completely out of the question - perhaps in a future update we will still do the upgrade - but it's almost definitely not happening for 2.0. Upgrading now would likely delay the expansion release date.
Don't forget, you're here forever.

mrvn
Smart Inserter
Smart Inserter
Posts: 5709
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by mrvn »

Speaking of 2.0 is there any chance of getting a alpha/beta version of the game engine without any of the new space content? I'm just dying to try all those QoL changes and maybe the new rails.

Splitframe
Long Handed Inserter
Long Handed Inserter
Posts: 54
Joined: Thu Aug 28, 2014 4:44 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Splitframe »

raiguard wrote: ↑
Mon Dec 11, 2023 4:10 pm
Upgrading now would likely delay the expansion release date.
Haha, yeah we wouldn't want that to happen now, would we? Bythewaywhatisthereleasedate?

Tooster
Long Handed Inserter
Long Handed Inserter
Posts: 61
Joined: Wed Mar 24, 2021 6:42 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Tooster »

PatrickBlack wrote: ↑
Sat Dec 09, 2023 3:22 am
[...]
Image
[...]
Perfect visualization! This is exactly what I had in mind, thank you!
Stormcaller wrote: ↑
Sat Dec 09, 2023 3:41 am
i would note, putting the max draw distance in each time will cause complications your pic with one belt doesnt show...

ie what happens when it runs into an existing underground segment running in the same direction, does it stop before it regardless of what it is? or only if its the same type? or what? and if it it running under existing belts its going to be hard(er) to see...
I don't think there would be any ambiguity. It wouldn't be "max range of the belt" but "max range of THIS belt" which would use the exact same logic the game does - if the belt would match to already existing undeground, then that's the max range, we don't go over, aka "sensible range visualized".
Last edited by Tooster on Tue Dec 12, 2023 4:19 pm, edited 1 time in total.
Look mom, I made a mod ^^ Barrel Stages

Tooster
Long Handed Inserter
Long Handed Inserter
Posts: 61
Joined: Wed Mar 24, 2021 6:42 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Tooster »

H_Sage wrote: ↑
Sat Dec 09, 2023 1:48 pm
Nice! Now it remains to improve the most important part of the Factorio gameplay (Quality of Life): convenient and fast construction of conveyors using automatic rotation of the conveyor towards the cursor, as is implemented in Mindustry. Or assign a key to change the operating mode (improving R). No mods, vanilla.
I did a simple demo and discussed about it in viewtopic.php?f=6&t=104721. You can even play on an interactive site with the concept of new "belt bending" mechanic, if that's what you mean. I didn't have the time or will to make a mod yet though.
Look mom, I made a mod ^^ Barrel Stages

mrvn
Smart Inserter
Smart Inserter
Posts: 5709
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by mrvn »

Tooster wrote: ↑
Tue Dec 12, 2023 3:50 pm
PatrickBlack wrote: ↑
Sat Dec 09, 2023 3:22 am
[...]
Image
[...]
Perfect visualization! This is exactly what I had in mind, thank you!
Stormcaller wrote: ↑
Sat Dec 09, 2023 3:41 am
i would note, putting the max draw distance in each time will cause complications your pic with one belt doesnt show...

ie what happens when it runs into an existing underground segment running in the same direction, does it stop before it regardless of what it is? or only if its the same type? or what? and if it it running under existing belts its going to be hard(er) to see...
I don't think there would be any ambiguity. It wouldn't be "max range of the belt" but "max range of THIS belt" which would use the exact same logic the game does - if the belt would match to already existing undeground, then that's the max range, we don't go over, aka "sensible range visualized".
I think if an endpoint already exists it should still show the yellow maximum range. Just the green range should go up to min(existing underground, new underground) showing where the tunnel would actually end. The ending of the green section would be clear enough indicator that you went past the endpoint of the underground.

akane.k
Burner Inserter
Burner Inserter
Posts: 6
Joined: Wed Feb 27, 2019 10:31 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by akane.k »

Thanks for the great suggestions.

Maybe it's already been mentioned?
My thought is about when the tracks intersect the belt.
Please consider English is not my native language.

mrvn
Smart Inserter
Smart Inserter
Posts: 5709
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by mrvn »

One more enhancement wish for dragging underground belts/pipes:

When you drag the endpoint is placed at the furthest reach and then the next tile starts the process again. But sometimes there is something in the way on the next tile, an entity, a tree/stone or a cliff. Entities should probably not be removed at all. Tree/Stone should be removed with shift. Cliffs should be removed with the new ctrl+shift keybinding for building harder.

Anyway, when dragging an underground belt / pipe and the tile following the endpoint is obstructed and won't be removed then the endpoint and new start should be placed on the last pair of tiles where it was placeable.

FasterJump
Fast Inserter
Fast Inserter
Posts: 194
Joined: Sat Jul 09, 2016 11:43 am
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by FasterJump »

H_Sage wrote: ↑
Sat Dec 09, 2023 1:48 pm
Nice! Now it remains to improve the most important part of the Factorio gameplay (Quality of Life): convenient and fast construction of conveyors using automatic rotation of the conveyor towards the cursor, as is implemented in Mindustry. Or assign a key to change the operating mode (improving R). No mods, vanilla.
I thought this is already implemented as an optional parameter (checkbox), could anyone confirm?

Cerberus
Inserter
Inserter
Posts: 42
Joined: Sat Sep 17, 2022 8:12 am
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Cerberus »

It probably has been proposed already in this topic, but one thing I would really like on the subject of underground belt and pipes:

Suppose you have a belt, and you would like to convert part of it to an underground belt. For example, make the last part of a straight belt underground, right before a turn. Now you have to manually count where to put down the underground belt tile, so you exit right before the turn, in order to maximize the distance of the underground. Why not, when having selected the underground belt, have a visual cue for where the exit would be if maximum distance is utilized? So BEFORE you even place down the "underground belt entrance" tile. Would be even more user friendly than simply make the preview turn green when it is at max distance like in the example of the FFF. Because you still need to count before placing the "underground belt entrance" tile, and if you counted wrong you need to undo and bots might have dragged stuff from the belt away already etc...
But with a visual cue before placing down the first tile for going underground, you don't need to count anymore, you can just see...

Sorry for confusing explanation, I don't really know how to explain it well in English.

mrvn
Smart Inserter
Smart Inserter
Posts: 5709
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by mrvn »

Cerberus wrote: ↑
Thu Dec 14, 2023 11:47 pm
It probably has been proposed already in this topic, but one thing I would really like on the subject of underground belt and pipes:

Suppose you have a belt, and you would like to convert part of it to an underground belt. For example, make the last part of a straight belt underground, right before a turn. Now you have to manually count where to put down the underground belt tile, so you exit right before the turn, in order to maximize the distance of the underground. Why not, when having selected the underground belt, have a visual cue for where the exit would be if maximum distance is utilized? So BEFORE you even place down the "underground belt entrance" tile. Would be even more user friendly than simply make the preview turn green when it is at max distance like in the example of the FFF. Because you still need to count before placing the "underground belt entrance" tile, and if you counted wrong you need to undo and bots might have dragged stuff from the belt away already etc...
But with a visual cue before placing down the first tile for going underground, you don't need to count anymore, you can just see...

Sorry for confusing explanation, I don't really know how to explain it well in English.
Already covered with mockup screenshots.

But this gives me a new idea.

When you place an underground belt on an existing belt but going in the wrong direction then why not have that mean you construct the unsderground belt from the end to the start. So you would just click at the last belt before the turn and then you can move the mouse and see how far the underground can stretch and place the start anywhere you like.

For me it makes little sense that you can fast upgrade a belt with an undergound belt going the opposite way.

User avatar
Unknow0059
Long Handed Inserter
Long Handed Inserter
Posts: 96
Joined: Tue Aug 08, 2017 7:37 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Unknow0059 »

"your personal requests are disabled" I assume the body recovery process itself is unchanged.

"Max range indicator" since you bothered doing this, did you also make underground pipes automatically place themselves like underground belts when you hold LMB?

"Chart tags improvements" it seems that the tag icon size is finally not gigantic. Thank. God. And whoever fixed it.

"Color of robots on the map"
I didn't even know personal robots could be left behind due to distance then stay there.
So now there's a visualizer for this, but this is something that's still allowed to happen.
Is this an obstacle to cheating, or meaningful challenge? I don't think so.

More on the personal robots, it would be cool if they were tinted, and their color matched that of the player.

It's incredible you fixed everything in this FF, but it worsens all the other annoying that's still in the game.

User avatar
Hares
Fast Inserter
Fast Inserter
Posts: 127
Joined: Sat Oct 22, 2022 8:05 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Hares »

Dear Factorio Team.
Is it possible to keep formulas in the text format for some complex inputs? I.e., if a formula contains more than 2 actions, or has multiplication where both members have prime factors other than 2 and 5... It would help to keep the readability of "4*12*48 - 1" (# of stacks in 4 groups of 12 steel chests, minus one) instead of "2303" (what is 2303? Why not 2300? Why odd? So many questions, so few answers...). And yes, that's the real value I used.

In terms of API, I would add a text property next to the existing integer property. When either is changed, the second is changed too.

Cobaltur
Inserter
Inserter
Posts: 47
Joined: Sat Sep 24, 2016 1:33 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by Cobaltur »

Smart number format
Often times you want to set some constant number, like "I want 7.5 stacks here",
As already a lot of people said: All the given samples are not responding to the question.
And a postfix "S" for stack is hard to guess.

A slider indicating a "stack" mode would be more intuitive
factorio stacks2.jpg
factorio stacks2.jpg (2.6 KiB) Viewed 1277 times
Of if you prefer icons you have already an indicator for it ingame.
factorio stacks.jpg
factorio stacks.jpg (2.68 KiB) Viewed 1285 times
For personal logistics this would be really helpful to say e.g. 3 stacks of yellow belts

mrvn
Smart Inserter
Smart Inserter
Posts: 5709
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by mrvn »

Cobaltur wrote: ↑
Mon Dec 18, 2023 9:53 pm
Smart number format
Often times you want to set some constant number, like "I want 7.5 stacks here",
As already a lot of people said: All the given samples are not responding to the question.
And a postfix "S" for stack is hard to guess.

A slider indicating a "stack" mode would be more intuitive
factorio stacks2.jpg

Of if you prefer icons you have already an indicator for it ingame.

factorio stacks.jpg

For personal logistics this would be really helpful to say e.g. 3 stacks of yellow belts
A slider would be limiting. I want to be able to say 4 * iron chest. or 2 * fluid tank. I like having suffixes for in formulas but an overall unit multiplier would be nice to. It's not uncommon to need "4 stacks - 12" and "12 chests" both. The former needs suffixes and the later is better with a unit box. Then again, if the item picker for formulas is good choosing an suffix might be just as easy as picking a unit (which has a much smaller selection than all items).

FuryoftheStars
Smart Inserter
Smart Inserter
Posts: 2554
Joined: Tue Apr 25, 2017 2:01 pm
Contact:

Re: Friday Facts #388 - Smaller things for 2.0

Post by FuryoftheStars »

Cobaltur wrote: ↑
Mon Dec 18, 2023 9:53 pm
And a postfix "S" for stack is hard to guess.
Technically speaking, knowing that you can type k, m, etc into the formulas isn't "easy" to guess, either. But all of it can be solved with a (tooltip) legend of what is accepted.
My Mods: Classic Factorio Basic Oil Processing | Sulfur Production from Oils | Wood to Oil Processing | Infinite Resources - Normal Yield | Tree Saplings (Redux) | Alien Biomes Tweaked | Restrictions on Artificial Tiles

Post Reply

Return to β€œNews”