tip for graphics

[Lutra]

Ever get tired of adding 20 items, having to type out "icon = "__mymod__/graphics/icons/item.png" 20 times, and then again for the entities, and then again for technologies? I did.

When starting a prototype file, before entering data:extend, simply add

iconpath = "__mymod__/graphics/icons/"

then, when you need to specify an icon, use

icon = iconpath.."item-png"

then you win

[Sean Mirrsen]

That is actually very helpful!

Thank ye kindly for this bit of wisdom.

[Zeblote]

Why are you typing that 20 times? Copy-paste and autocomplete are your friends

[prg]

If you're creating lots of similar prototypes you can even go a step further and do something like

Code: Select all

function beltplanner_item(type)
    return {
        type = "item",
        name = "beltplanner-"..type,
        icon = "__beltplanner__/graphics/beltplanner-"..type..".png",
        flags = {"goes-to-quickbar"},
        place_result = "beltplanner-"..type,
        stack_size = 50,
    }
end

data:extend({
    beltplanner_item("basic"),
    beltplanner_item("fast"),
    beltplanner_item("express"),
    beltplanner_item("end"),
})

to save even more typing. Lua is amazing.

[ArderBlackard]

Lua is amazing.

I'd say "programming is amazing". The same approach is possible for almost all programming languages.

[Sean Mirrsen]

Lua is amazing.

I'd say "programming is amazing". The same approach is possible for almost all programming languages.

That is true. However, Lua being a scripting language (or, the proper term I suppose being, "interpreted language", more specifically a multi-paradigm, dynamically typed, interpreted language), it allows for this sort of thing to be typed up in Notepad and just plugged into the main program without any recompilation. It doesn't need includes for basic functions, doesn't need you to cast data types into one another, and generally simple to use. I know there are a lot of programming languages offering similar functions, but I'd say Lua is still, in itself, amazing.

[prg]

Damn, I wasn't even being serious. Of course calling a function is a fundamental programming concept and does not make Lua special. I actually hate duck typing and that everything that does not exist is implicitly nil. Causes way too many unnecessary errors which could easily be avoided with a proper type system that checks if a function is called with the right number of arguments etc. Refactoring Lua code is a nightmare, if you missed something somewhere it'll only blow up at run time even if such an error could be easily detected with static type checking.

[ArderBlackard]

Lua being a scripting language (or, the proper term I suppose being, "interpreted language", more specifically a multi-paradigm, dynamically typed, interpreted language)

BTW I guess that Factorio uses LuaJIT which allows compiling Lua code for a great performance boost. Run-time interpretation usually is slow

I actually hate duck typing and that everything that does not exist is implicitly nil

Can't say I 'hate' it, but I also prefer using statically typed languages. In my opininon the main (dis)advantage of Lua is that it is extremely simple in it's syntax (while not in power).

Refactoring Lua code is a nightmare, if you missed something somewhere it'll only blow up at run time even if such an error could be easily detected with static type checking.

If this would be of any help, you may try a JetBrains IntelliJ IDEA with Lua plugin. It does not provide as good refactoring/control possibilities as for other languages in IDEA (or like a ReSharper for respective languages ), but at least allows simple refactorings (like local names renaming, variables extraction etc.), and even to some extent an on-the-fly code analysis and errors detecion.
I have tried a number of other editors/IDEs (notepad++, ZeroBrain Studio, VSCode) and for now it seems to be the best option.
P.S. It seems I'm being Captain Obvious -_-

[Zeblote]

BTW I guess that Factorio uses LuaJIT which allows compiling Lua code for a great performance boost. Run-time interpretation usually is slow

Factorio doesn't use luajit, at some point the devs actually said it would be unnecessary (wtf?) but seems to be planned for 0.13 now

[ArderBlackard]

Nice to hear it! Seems like the devs themselves didn't realize a complexity of the mods the community would try to implement

[Sean Mirrsen]

Nice to hear it! Seems like the devs themselves didn't realize a complexity of the mods the community would try to implement

I'd dare to say that there's quite a lot of complexity the devs did not realize the mod community would want to make.

You can't have a fuel-fed power generator unless it extracts energy from fluid, you can't rotate an assembly machine before or after placement unless it has an assigned fluidbox, you can't make a lamp that burns fuel (aka brazier, or sconce) even if you can set the energy source to "burner" (it won't accept fuel), you can't make anything that doesn't explicitly allow it not require power (lamps, inserters, etc), the list goes on and on. We're saved only by the tremendous capacity for kludge solutions that the Lua scripting provides.
(even then, I needed to make a large subroutine that creates copies of some transport belts and their contents, in order to rotate them along with the building they're attached to, because it's impossible to move transport belts via code. Limits, limits everywhere.)

[Lutra]

the devs have also removed the file system included with Lua. i guess it means security, but makes a lot of problems...

[Sean Mirrsen]

the devs have also removed the file system included with Lua. i guess it means security, but makes a lot of problems...

There's problems, and there's problems. Modders not having quite the same power as they could does not quite measure up to the magnitude of "problem" that a keylogger or trojan hidden in 5000 lines of elaborate filesystem-accessing code can create. Especially if you consider the devs as being a company with a public image.

[Lutra]

hehehe. should probably change this topic to 'language discussions'.

[Zeblote]

There's problems, and there's problems. Modders not having quite the same power as they could does not quite measure up to the magnitude of "problem" that a keylogger or trojan hidden in 5000 lines of elaborate filesystem-accessing code can create. Especially if you consider the devs as being a company with a public image.

How do you get from basic file access to a trojan or keylogger? The lua api wouldn't have any way to run an executable, obviously.

[Sean Mirrsen]

There's problems, and there's problems. Modders not having quite the same power as they could does not quite measure up to the magnitude of "problem" that a keylogger or trojan hidden in 5000 lines of elaborate filesystem-accessing code can create. Especially if you consider the devs as being a company with a public image.

How do you get from basic file access to a trojan or keylogger? The lua api wouldn't have any way to run an executable, obviously.

Lua is a programming language. Any programming language with filesystem access can be used to create malicious code, in one way or another. The OS is often all too happy to automatically run plain-text scripts placed in certain strategic locations, for instance.

[ArderBlackard]

Currently there is a game.write_file(path, content) function that can write files to disk, but only to a specific folder "script-output" (subfolders can be created too). I guess that ability to read files from this sandboxed folder would be enough for the majority of IO-related tasks,

UPD: At least it can solve the long-term problem of "Pass some info from data.lua to control.lua"

[Zeblote]

There's problems, and there's problems. Modders not having quite the same power as they could does not quite measure up to the magnitude of "problem" that a keylogger or trojan hidden in 5000 lines of elaborate filesystem-accessing code can create. Especially if you consider the devs as being a company with a public image.

How do you get from basic file access to a trojan or keylogger? The lua api wouldn't have any way to run an executable, obviously.

Lua is a programming language. Any programming language with filesystem access can be used to create malicious code, in one way or another. The OS is often all too happy to automatically run plain-text scripts placed in certain strategic locations, for instance.

You could limit file access to subfolders inside the game folder, then. No harm done creating malicious files if you can't run them.

[Adil]

I actually hate duck typing and that everything that does not exist is implicitly nil. Causes way too many unnecessary errors which could easily be avoided with a proper type system that checks if a function is called with the right number of arguments etc. Refactoring Lua code is a nightmare, if you missed something somewhere it'll only blow up at run time even if such an error could be easily detected with static type checking.

But hey that's what makes lua fun to code! Just type whatever comes to your head , not think about formal stuff.
Also, certain tricks actually work due to language defined this way.
Surely, once code gets over certain limit, it collapses on itself like a supernova, but for sufficiently separated small bits of scripts that works.
Also, it's sufficiently fluid for the coder to implement those checks without much effort. [1][2]

[Sean Mirrsen]

UPD: At least it can solve the long-term problem of "Pass some info from data.lua to control.lua"

I wasn't aware there was even a need to pass info from data to control. Isn't data just a hub for all the things you've got spread around the mod's folders, with some final fixes thrown in? Could you describe a use case, I'm actually curious.

You could limit file access to subfolders inside the game folder, then. No harm done creating malicious files if you can't run them.

And yeah, I suppose that could work. Still probably wise to not even have a hint of a possibility of a security hole, but with sufficient control it could be "safe enough" at least.