Factorio Forums

I've been trying to make a drill that can be placed anywhere and outputs water, but it seems I have to use the logic of an existing building type and work around it rather than create one that combines several; I can't just take the fluid output logic of the off-shore pump and add it to a pumpjack or burner drill.
Looking at the many mods people have made, it's gotta be possible to work around, but it still seems like a surprisingly extreme limitation.

No it's not possible to create new types. Each "type" is a reference to a C++ class with the logic that it has associated with it.

Any plans to move more of this functionality from under the hood into the modding api?

Impatient wrote:Any plans to move more of this functionality from under the hood into the modding api?

No. The mod API is that - a mod API. We're not making a game engine for people to develop games with - we're making a game - with a mod API.

Additionally everything done through the API has all kinds of sanity checks that have to be done to ensure that things done incorrectly through the API don't corrupt/crash the game.

A few recent examples we've had to solve:

• We fire events for different actions as the game runs that mods can react to. One of those is the "entity died" event. However, there was nothing preventing a mod listening to the "entity died" event from calling entity.die() and starting the entire loop over again.
• During any event when we pass references to objects in-game a mod is free to do anything it likes with those objects. Often mods will destroy an entity in reaction to the "entity built" event because it was just using it as a flag of sorts. That's fine, however the event keeps firing for all other listening mods and the entity has since been invalidated partially by calling destroy() on it.
• Factorio has to run deterministic in order for our multiplayer system to function. Mods where doing things in the "on load" event that would modify the game state (making entities/destroying entities) and this broke multiplayer because the game would "load" for the connecting player but the player already running it would already have it loaded and so you end up with 2 different game states on the two machines.

All of these things have to be accounted for to prevent corrupting people's save games and prevent crashing-to-desktop if something goes wrong. This all adds *tons* of overhead to even the simplest things when done through the mod API. Moving expensive game logic into the mod API is not likely to ever happen.

Alright.

As for my specific attempt, should I look to using scripts in control.lua to get the desired effect? I suppose making it an assembling machine type and adding a recipe that just outputs water might work... though then it has to be manually selected each time.

Align wrote:Alright.

As for my specific attempt, should I look to using scripts in control.lua to get the desired effect? I suppose making it an assembling machine type and adding a recipe that just outputs water might work... though then it has to be manually selected each time.

You can use the assembling-machine prototype type property "fixed_recipe" to set a fixed recipe that it will use when created. Then simply don't give It any crafting category and it can't craft anything else.

Awesome, thanks! Took a bit of fiddling but I got it all to work.