Opening the source?

[kovarex]

I'v sent you PM.

[tux_mark_5]

I would love to see the source of Factorio one day.

In my opinion, the current modding model is not sufficient to develop really powerful mods simply because:
1. Lua is not quite fast enough to implement something more interesting (such as a new logistic model, different type of trains, ships or planes).
2. It will always be limited by the functionality provided by the API.

Recently a game called Space Engineers announced that they are opening the source to the people who own their game (sort of like Unreal Engine 4 did things before they opened their source to everyone). This does not mean that suddenly the game becomes free, but rather that in addition to getting the game, when you buy it, you get the source as well.

Also, if the is somewhere a button to apply for source, please show me

[SHiRKiT]

Here's my opinion on this.

[tux_mark_5]

Yup. It's trying so summon the source is serious business. Some powerful necromancy is required.

[daniel34]

I own a copy of Space Engineers and have used the programmable block ingame, which lets you code some small functions, or even complete mods, directly in the game (in C# with the provided library).

I also read the blog post they made when making the source code of their game public, here's what I think about it:

Pros:
Total conversions are now possible
More and better content created by modders
Allowing people to have more fun with our game by letting them modify it while we keep adding core features and updates just like we did for the last 2 years
Modders can make server-side mods easily
Modders can contribute to Space Engineer’s core development if they want
Modders can extend the official ModAPI interface and we will merge their changes with the core game

I don't think that modding based on the source (C++ in Factorio, I think) is a good idea because it requires the base game files to be changed and the incorporation of several mods that way would be very difficult, if not impossible. You'd have to combine all the mods you want to use manually and compile the executables yourself.

I see how it can lead to a better understanding of game mechanics by modders and computer programmers.
But the only improvement I see are the following two cases:
(1) Someone who has found/identified a bug and can fix it or has some performance improvement can forward it to the developers for inclusion in the next release, complete with finished code --> easing workload on the devs
(2) Extensions to the Mod API (in Factorio, Lua) by modders, like this post on the blog of SE mentions:

Modders will be able to contribute to ModAPI in vanilla game.
It often happens that modders want to create a mod, but they are unable to do it because ModAPI has a limited interface. In this case, they will simply add support for it (usually it means creating a small public interface for an existing feature).
We will review their changes and when it meets quality and security requirements, we’ll merge it with the core game.

[DaveMcW]

(2) Extensions to the Mod API (in Factorio, Lua) by modders, like this post on the blog of SE mentions:

Modders will be able to contribute to ModAPI in vanilla game.
It often happens that modders want to create a mod, but they are unable to do it because ModAPI has a limited interface. In this case, they will simply add support for it (usually it means creating a small public interface for an existing feature).
We will review their changes and when it meets quality and security requirements, we’ll merge it with the core game.

One of the best modders (Rseding91) already has access to the source code. Post your ModAPI requests here.

[daniel34]

One of the best modders (Rseding91) already has access to the source code. Post your ModAPI requests here.

I did know that, what I meant was that global access to the source would mean that every modder requesting some addition to the ModAPI could code it themselves the way they needed it - given proper code guidelines - and the devs would just need to approve of the changes and integrate them, thus reducing the workload for them.

I'm actually a computer programmer myself career-wise (mostly C#, some PHP and database work) and haven't had an idea for a new mod for Factorio, but maybe one day I'll write my own mod.

[tux_mark_5]

In my opinion, the current modding API is quite limited (and yes, I get it that neither the game, nor the modding api is "completed" yet).

It works well for content mods that add similar things to the game compared to the ones we already have (Bob's mods, DyTech, etc). However, the moment you step out of these bounds you often end up having to code hacks. Adding new transportation system with Lua would be difficult and inefficient at best, impossible at worst.

I'd love to see pipes that can carry items similar to the ones found in Minecraft's mod IndustralCraft. There at each intersection you could place a sorter that would send incoming items to different directions based on some filter rules. Right now I don't think this can be done in Lua, but I'd love to implement something like this in C++.

Touching day/night cycle or adding weather to the game is yet again something that can't be currently done. Adding seasons, rain or snow to the game would mean that you couldn't as easily depend on batteries & solar cells, so you would need to have some alternative form of energy generation as a backup in case of a longer period of no sunlight.

Ships, planes are too impossible to implement right now. Same goes for bridges/tunnels for trains.

Adding new methods to handle fluids seem to be impossible as well. For example, a 1x1 item that acts both as two pipe-to-grounds and a valve that can be used to connect pipes above ground. Or a 1x1 "window" into an underground belt that can be used to insert/remove items from/to the belt.

And these are just some things that come from top of my head that would definitely improve the game. These things don't need to be included in the base game, but should be possible to implement at least through mods. This is the very essence of mods for me. And C++ mods are the only way this could be done, IMO. I really think that sooner or later Factorio at very least should get a native mod API because Lua, for some entities, is simply not fast enough. The 0.11 version of transport belts that is written using C++ was already deemed to slow by the devs. Now imagine if the belts were written in Lua and used 10x times more performance.

I do apologize if my thoughts somehow offend anyone, but this is only because it's been quite a while when I felt so passionately about a game. And I would love to improve the game even further, especially because C++ is my main programming language.

[sillyfly]

I don't know that Lua is inherently slower than C++. Looking up a bit of benchmarking online, it seems that at least some implementations (namely luajit) are about as fast as C/C++, and may be even faster in some cases.
But I do agree that having a more extensive modding API is very much needed.

[ssilk]

I don't know that Lua is inherently slower than C++. Looking up a bit of benchmarking online, it seems that at least some implementations (namely luajit) are about as fast as C/C++, and may be even faster in some cases.

Do you know, that Lua is - when it is about creating big numbers of hash values - about 3 times slower, than PHP? I tested that, when writing the Factorio Loader Lib. When it is about processing strings, Lua is as fast as PHP, maybe faster. (But PHP has more string functions and is here faster again, when really using them clever )
I won't discuss, that PHP is faster than LUA or that Lua is not thought to process strings and big numbers of hashes, it is just a fact: Doing things in C++ is 5-50 times faster than Lua.

[sillyfly]

The speed is highly dependent on the implementation of the Lua engine: as I said, luajit seems to do very well, in comparison to other Lua engines and in comparison to C and C++.

Take a look at this: http://luajit.org/performance_x86.html
Seems like luajit does up to 100+ times faster than normal Lua 5.1.5. I don't know which one is used in factorio, but that's a BIG difference!

Edit: Here's another page I found - https://attractivechaos.wordpress.com/2 ... by-luajit/ . For his test - the luajit performance was only 10% slower than C, which is very much comparable in speed.

[quinor]

Lua scripts usually have little impact on game performance, I talked with one of the devs about that quite recently. I also asked them if they'll move to luajit at some point, but according to what he said there is no need for that. Maybye in the future they'll do that, when mods/game will use much more Lua scripting.

[tux_mark_5]

Lua scripts usually have little impact on game performance, I talked with one of the devs about that quite recently. I also asked them if they'll move to luajit at some point, but according to what he said there is no need for that. Maybye in the future they'll do that, when mods/game will use much more Lua scripting.

There are 2 reasons for that:
1. You can't do that many exciting things with current Lua API. As I mentioned before, the best you can do is to augment current entities to do something a bit different.
2. Most people who have written more than a few lines of code in their life probably can estimate, that the moment you start updating every instance of an entity in your mod every tick, the performance of such mods will go down so hard, so fast that people will eventually avoid your mod like a plague. While some minor entity updates might not cause such things to happen, but something more intensive, such as a complete belt replacement written in Lua would do exactly that. And that is why most major mods (again, in my personal opinion) just expand on the things we already have in the game (more assembler types, more roboport types, more ores, etc).

[orzelek]

Lua scripts usually have little impact on game performance, I talked with one of the devs about that quite recently. I also asked them if they'll move to luajit at some point, but according to what he said there is no need for that. Maybye in the future they'll do that, when mods/game will use much more Lua scripting.

I'd tend to agree with some exceptions.
Currently when running shadows mod pack there is a heavy lag when bots build a lot of things in succession. I'm pretty sure it's caused by one of mods processing - I'm not sure which one exactly. So it's a lot of lua processing that causes this.
Same would also apply to treefarm mod easily - it's because it implements mechanic (tree growth) thats not present in base game.

[quinor]

Orzelek: I'm quite sure that I could implement this particular treefarm feature - growing trees - in such way that it wouldn't lag at all. But still, implementing some features (like replacing entire belt system) is currently impossible to do with Lua using existing mod API.

Tux: Updating every entity every tick is always time-consuming, and no programming language will change that. The key is such optimalisation that you don't need to do it, and in most cases it can be done. I've been dealing with this class of problems for last 6 years and only rarely you are forced to use excessive amounts of raw computer power

[tux_mark_5]

Small request to developers: would it be possible to link the next version of factorio on linux with -rdynamic flag? This would export all symbols in such a way that they can be accessed by the dynamic linker and so native factorio plugins could make use of factorio's internals. This way one could build a factorio plugin as a shared library and just add it to LD_PRELOAD list. This could also be mixed with source hotpatching to redirect native factorio method calls to some custom version of that function. I've been thinking of a way to provide native modding support for factorio and (at least for linux platforms) this appears to be the most straightforward way.

This method works even without -rdynamic flag, but it requires manual fiddling with factorio's binary (entries from .symtab need to be moved to .dynsym so plugins could dynamically link against factorio executable).

Also, after analyzing the debugging symbols in factorio I've found out that most interfaces (class names, members, member formal parameters, fields; for templates, their specializations, etc) can be "reassembled" purely out of DWARF debugging data that is stored within ELF binary. Combined with LD_PRELOAD method this allows to build fully functional native plugins for factorio.

Theoretically, similar approach should work on windows as well: all PE binaries (both exes and dlls) can have an export table that acts the same way as a .dynsym table in ELF binaries. Dlls into factorio executable can be injected by using a custom launcher/debugger or using remote thread creation (CreateRemoteThread). When a plugin/mod is loaded, entries marked with __declspec(dllimport) should be imported from factorio binary and thus made accessible to the plugin. Though at this point I am not 100% sure how new entries can be added to a regular executable's export table (it is possible that a simple declspec would work).

A cleaner way to handle this on both platforms would be to make factorio as a shared library on all platforms with extremely thin launcher executable, but this would require more severe changes in the way factorio is currently being built.

[rmusk]

I know that this is an old thread, but isn't the freeplay part already "open-source"? It looks like only the engine is closed-source C++ code, and all the 'game' is written in Lua using the mod APIs.

But if I change the base mod, can I make the game completely different from vanilla?