lots and lots and lots of things

[Xandaros]

Hey there,
I really enjoy this game and thought to extend it a little with some mods. Things might actually get implemented "for real" at some point, since the game is at such an early stage, but until then we can already have some fun with them.
However, I found that the API is seriously lacking(or very confusing, one of those). For almost all of my ideas, I pretty much immediately hit a brick wall.

For example, I want to make an inserter, that changes its power consumtion depending on user input, but that is not possible. Most values of the prototype should be reflected as read/write and some as read-only properties on the entity.
A way to turn them off might be nice, too. (An extension of the circuit network, maybe. Just "on" and "off" methods will probably find their uses soon enough)

To be honest, I think the whole prototype approach is a bit weird. In the end, Lua is a dynamic scripting language. While you can provide default behaviour with metatables, you are always able to add or remove keys from a table and I think this aspect can be put to good use. (It can be confusing at times, granted, but the gain in flexibility can help greatly)

Another thing is, with all the prototypes and stuff, the API is basically following OOP principles(which is a good thing), yet the logic is crammed into a single control.lua file. I'd prefer it if you were to separate them out. (Yes, you can require them in the main control file, but that should really be part of the loader and not some intermediate control file.)

I'd also like to see a lot more events, like using an item (like the fish), trying to craft something but not having enough resources, etc.

Also object-specific events, like an inserter moving an item, etc.

As I said before, I realise this game is in a very early stage and you probably haven't put too much thought into the modding API, but I'd like to see a complete overhaul of it. At the moment it is just too limited for anything just slightly out-of-the-box and uses some weird concepts.
The thing is, if a game can be expanded by mods, it is often not that big of a problem if the core game itself doesn't have too much content. Factorio definitely has enough to be an enjoyable game without mods, just imagine it with the additional possibility of game-changing mods.

(Reading it again, this sounds like a rant, but that's not what it is supposed to be. No idea about better wording, though :/)

[robhol]

Oh yes. The claim that "the entire game" is a mod is a bit ridiculous, as modding hardly lets you do anything (or so it seems).
My own suggestions that I haven't bothered making a separate topic for:

- belt modifications, entities that can accept and place items to/from belts, also with access to different lanes
- user input (binding keys and commands)
- more GUI controls (multiline textbox would be nice for largish "reports" etc)

Basically, anything you see in-game should be exposed in one way or another. Having a modding API that only allows you to access minute details that apparently need to be added manually... is just painful.

[FreeER]

Oh yes. The claim that "the entire game" is a mod is a bit ridiculous, as modding hardly lets you do anything (or so it seems).

Everything that is in the base game can be done in mods...you just can't customize nearly as much as would be preferable. The idea of the "entire" game being 'a mod' is utterly ridiculous (Factorio isn't a total conversion of half life or anything!), it's ALL backed by the C++ that the devs have made.

entities that can accept and place items to/from belts

This can kind of be done with game.createentity{name="entity-on-ground", stack={name="iron-ore", count=1}}, but accepting requires findentitiesfiltered{name="entity-on-ground", area=boundingbox}, and that's 'slow' and no where close to as easy as it could/should be.
more user input and output (gui stuff and binding keys/commands) would be great as would custom guis for entities

As for the original post, I don't find the prototypes weird, but I find not being able to change them dynamically in game is (I think that's planned at least...)
More events could/would also be nice, especially using items and adding robot generated events to the regular player generated events (or having them separate but at least access to knowing about them). As for having the loader take care of loading multiple script files...eh I don't feel that it's really necessary, most mods aren't that large and of the ones that are the creators usually understand lua well enough to do it theirselves (besides it makes it just like using the data.lua file).
And as for it sounding like a rant, it is a valid rant (excluding the fact that Factorio is in an alpha/beta state).

[Xandaros]

It just feels like you can hardly do anything. Most things are hardcoded in C++ and even the things you define yourself end up being read-only (prototypes).
Well, next up is multiplayer, so I doubt they'll do much about this for now. Which is a good thing, actually. I'd like multiplayer

But I sincerely hope the Interfaces get changed a bit and won't keep being this limited. (That they are going to be expanded is obvious, but currently all you can make is very similar to what is already in the game...)

[Rointep]

Slightly old topic, but I think a bump is fine.

I agree with OP, the API at the moment is lacking in many ways. I started on a mod and I went to the wiki to look for the methods and events that would suit my needs, but found pretty much nothing of use. From my quick look around the place, the only real "modding" is in the addition of new items and recipes along with some minor options for programming them in control.lua.

Now, given that multiplayer is in development I expect the API to drastically change after it's released, because we'll have a "server-side" and a "client-side" of each mod... right? And, singleplayer will essentially be a locally hosted server... right? Just my expectations, please move along, nothing to see here

Anyway, the API is really lacking, and we need methods to modify the built-in elements of the game (I wanted to mess around with the inventory window's look). The interfaces are weird and don't offer enough customisation, there is not enough events, methods, etc. This might sound like a rant (and it maybe kind of is ), but I come in peace, humans! I am confident that the API will get an overhaul at some point, and I'd rather see it done after multiplayer is finished.

Also, please use CamelCase notation for the API methods and events, all lowercase is difficult to read and, in my opinion, unaesthetic.

[FreeER]

because we'll have a "server-side" and a "client-side"

Um, I suggest reading FF 43 and the comments as well.

Also, please use CamelCase notation for the API methods and events, all lowercase is difficult to read and, in my opinion, unaesthetic.

Hm, I rather prefer CamelCase (or camelCase) myself but have kind of gotten used to the api being lowercase, more importantly though is that changing it would break every mod in existence (except maybe the few that only use the prototypes)... Maybe for 1.0? (If and) Until then you should be able to make api functions (and other constants) CamelCase by simply making a variable with the new name and assigning the api function to it (thanks Lua).

[kovarex]

Hello, I agree that there is a huge amount of space for improvements of the modding api.

The hard thing is, that there are two concepts that are often in contradiction. The game needs to be optimised a lot in some aspects, to allow huge factories running smoothly. If we introduce event for every little thing, like inserter putting something somewhere, or transport belt moving some item etc. It would make a huge drag and slow the game down. Generally whenever we have to go to lua and let it run, it is quite expensive compared to optimised C++ code.

The example is, that we have some plans for some kind of "generalised lua entity" type. It should be able to implement different combinations of interfaces and to change in the runtime etc. This kind of entity could have lua-based drawing method, lua-based upate method etc. It would allow a lot of possibilities. But once the modder wants to use it for some entity that you are supposed to use thousands times in your factory, the game will inevitably slow down a lot.

[SHiRKiT]

The whole issue with creating such a thing is that all mods will derive from something like that. Once that's in place, when hundreds or maybe thousands of those machines are in place, lag will happen. I have some thoughts about this:
- No actual factory have thousands of assembling machines. Maybe a couple thousand, but not more.
- To fight against having thousands of those machines, one can create a variation of that machine that is equal to 100x machines. For example, a furnace that takes 100 iron ore to smelt into 100 iron plate and but takes 90x more time to smelt (encouraging to upgrade). Now one can easily replace his contraptions with such a nice furnace (of course, the concept of furnace/assembling machine here is just to illustrate, not literal)

Also I can think of some event driven systems that only have really minimal impactal if there is no listener, even if there's like hundreds of possible events that can be fired but have no listeners. Just need to optmize the event system to achieve that. But if that's worth the time invested, it's another history. One can turn the game more modular, but at the cost of performance. It would be down to the modders to not make stupid stuff and the users to filter/judge how much different mods they would end up using.

[ssilk]

The only solution I know - saw it often - is to have something like an own "Factorio-language", which can be translated into something like fast interpretable code - same as with java (too slow), better: like regular expressions.

A similar comparison is like with loading some Digital sound processor-program-code into a DSP , which does the whole computing in hardware, but the DSP-program is developed on simulated software-DSPs, not hardware. The analogy is like so: The software-DSP-emulators are the current Lua-interpreter. Everything works fine but having many of them are a problem. Factorio can load that program (or better only the critical parts), precompiles it in some special way and executes that directly, without using the Lua interface.

With that I think, the speed could be "only" about half of compiled code. This is very limited of course, and doesn't mean an abuse from Lua, but a way to move things from Lua into the game and to make that fast.

[cube]

We have been eyeing LuaJit for some time now.... Using it has a _very_ low priority, though :-)