Ok, I've thought over things abit and have come to a thought. (this is coming from java knowledge but should still be applicable)
the entities that use "energy_source" can have a just variable for it, all that info is passed to an abstract object which will build one of the two types: "electric" or "burner".
The two objects will handle most everything inside themselves in relation to energy, some stuff can be in the abstract higher object. They will both have a GUI element for the electrical info, the electric can have just a bar showing its buffer, the burner will have the buffer in addition to the fuel slots. The electric object will also handle all the connections to the power networks and can set the placing GUI effect to show the power network ranges (blue boxes from the poles).
With that refactor, it becomes increasingly simple to have a more dynamic power solution. a mod could then do something surprisingly crazy and go through all of the data.raw during the data-final-updates.lua and switch all electric to burners and all burners to electric, and the game should be able to handle that just fine.
I could also see a split for producing and consuming. consuming takes power from the power buffer, refilled from network if no producer on entity, and producing gives power to the buffer/network. which would allow for "burner-producer" which allows you to make power directly from coal. "electric-producer" pretty much all power gen right now, and accumulators. "burner-consumer" pretty much all the burners. "electric-consumer" everything that runs off the power network, and accumulators.
I think this part is actually half done, "energy_source" is producer, "energy_usage" is consumer. only thing is that the accumulator needs both but right now forces source to steal input_flow_limit from usage. I could see usage being extended with a default true for a "can take from accumulators" variable... source maybe having one for can give...
Make the API less rigid.
Re: Make the API less rigid.
Will code for Food. I also have 11+ mods!
Re: Make the API less rigid.
That's almost verbatim how the energy system works right nowvzybilly wrote:Ok, I've thought over things abit and have come to a thought. (this is coming from java knowledge but should still be applicable)
the entities that use "energy_source" can have a just variable for it, all that info is passed to an abstract object which will build one of the two types: "electric" or "burner".
The two objects will handle most everything inside themselves in relation to energy, some stuff can be in the abstract higher object. They will both have a GUI element for the electrical info, the electric can have just a bar showing its buffer, the burner will have the buffer in addition to the fuel slots. The electric object will also handle all the connections to the power networks and can set the placing GUI effect to show the power network ranges (blue boxes from the poles).
With that refactor, it becomes increasingly simple to have a more dynamic power solution. a mod could then do something surprisingly crazy and go through all of the data.raw during the data-final-updates.lua and switch all electric to burners and all burners to electric, and the game should be able to handle that just fine.
I could also see a split for producing and consuming. consuming takes power from the power buffer, refilled from network if no producer on entity, and producing gives power to the buffer/network. which would allow for "burner-producer" which allows you to make power directly from coal. "electric-producer" pretty much all power gen right now, and accumulators. "burner-consumer" pretty much all the burners. "electric-consumer" everything that runs off the power network, and accumulators.
I think this part is actually half done, "energy_source" is producer, "energy_usage" is consumer. only thing is that the accumulator needs both but right now forces source to steal input_flow_limit from usage. I could see usage being extended with a default true for a "can take from accumulators" variable... source maybe having one for can give...
If I was to open the source code and read to you how it operated you'd get what you just wrote.If you want to get ahold of me I'm almost always on Discord.
-
ratchetfreak
- Filter Inserter
- Posts: 952
- Joined: Sat May 23, 2015 12:10 pm
- Contact:
Re: Make the API less rigid.
There is just 1 thing missing. Mod access to some of the internals.Rseding91 wrote:That's almost verbatim how the energy system works right nowvzybilly wrote:Ok, I've thought over things abit and have come to a thought. (this is coming from java knowledge but should still be applicable)
the entities that use "energy_source" can have a just variable for it, all that info is passed to an abstract object which will build one of the two types: "electric" or "burner".
The two objects will handle most everything inside themselves in relation to energy, some stuff can be in the abstract higher object. They will both have a GUI element for the electrical info, the electric can have just a bar showing its buffer, the burner will have the buffer in addition to the fuel slots. The electric object will also handle all the connections to the power networks and can set the placing GUI effect to show the power network ranges (blue boxes from the poles).
With that refactor, it becomes increasingly simple to have a more dynamic power solution. a mod could then do something surprisingly crazy and go through all of the data.raw during the data-final-updates.lua and switch all electric to burners and all burners to electric, and the game should be able to handle that just fine.
I could also see a split for producing and consuming. consuming takes power from the power buffer, refilled from network if no producer on entity, and producing gives power to the buffer/network. which would allow for "burner-producer" which allows you to make power directly from coal. "electric-producer" pretty much all power gen right now, and accumulators. "burner-consumer" pretty much all the burners. "electric-consumer" everything that runs off the power network, and accumulators.
I think this part is actually half done, "energy_source" is producer, "energy_usage" is consumer. only thing is that the accumulator needs both but right now forces source to steal input_flow_limit from usage. I could see usage being extended with a default true for a "can take from accumulators" variable... source maybe having one for can give...
Like let an entity have just a consumer which connects to the electricity grid and fills its buffer. The mod can then magically grab the energy out of it to do some work.
Or a producer that sends the energy in its buffer to the grid and a mod can arbitrarily fill the buffer. Based on "reasons"
Re: Make the API less rigid.
entity.energy does exactly that. The issue is: setting entity.energy does not change the buffer size.ratchetfreak wrote:There is just 1 thing missing. Mod access to some of the internals.
Like let an entity have just a consumer which connects to the electricity grid and fills its buffer. The mod can then magically grab the energy out of it to do some work.
Or a producer that sends the energy in its buffer to the grid and a mod can arbitrarily fill the buffer. Based on "reasons"
For electric using entities the buffer size is enough to run the entity for 1-2 ticks.
For burner using entities the buffer size is the size of the item's fuel value being burnt - or 0 if none is being burnt.
If you want to get ahold of me I'm almost always on Discord.
Re: Make the API less rigid.
Rseding91 wrote:entity.energy does exactly that. The issue is: setting entity.energy does not change the buffer size.ratchetfreak wrote:There is just 1 thing missing. Mod access to some of the internals.
Like let an entity have just a consumer which connects to the electricity grid and fills its buffer. The mod can then magically grab the energy out of it to do some work.
Or a producer that sends the energy in its buffer to the grid and a mod can arbitrarily fill the buffer. Based on "reasons"
For electric using entities the buffer size is enough to run the entity for 1-2 ticks.
For burner using entities the buffer size is the size of the item's fuel value being burnt - or 0 if none is being burnt.
I recently changed one of my mod power providers from an accumulator to a lamp so it can be charged by an accumulator. the things using the power had none with the same energy source (buffer_capacity set, input_flow_limit set. 2 times the input and storage of the current use.). had to change energy_usage_per_tick to the desired amount to power my items but now they draw 2 to 4 times the power from the electrical network. it was using 550kw when per thing active, now it's something like 1mw per (don't remember fully, might have been when one consumer was active all started fully drawing power which would have been about 7mw). I think I also remember the game crashing when looking at a train inventory GUI (to see it's power buffer) while it was using electric (tested afew weeks ago, don't remember fully, was at least 0.12). also, just setting it to electric doesn't connect it to power networks...wiki wrote:Electric energy source:
- buffer_capacity
- usage_priority
- input_flow_limit
- output_flow_limit
from actual testing, pretty much everything in energy source was disregarded except that it was electric. even then, it might have been hard coded (didn't try a burner).
An entities buffer size is set in the entity prototype, but in game, entity.energy is still a 1 tick buffer +0.1% (value might be off but I found a percentage increase in my testing). The only entity that fully works is an accumulator but it has a good deal of extra baggage (Not being able to charge from/give-to other accumulators and animations needed).
A simple hack fix for the electrical issues could even be to make two entities in the game that have a GUI option (or even able to call a specified function in control.lua)
The two entities would be:
- data["raw"]["generator"]["mod-Generator"] = the providing half of an accumulator.
- data["raw"]["consumer"]["mod-Consumer"] = the consuming half of an accumulator.
If what I said before was fully correct in C++, then in modding we don't have access to it. I have seen a good deal of stuff inside the black box (C++) that I can't use via modding. I'd even be willing to learn C++ just to work on the Modding API (Scala/Java, 7 years), if given the hiring opportunity, very slowly otherwise.
side note
Will code for Food. I also have 11+ mods!
-
ratchetfreak
- Filter Inserter
- Posts: 952
- Joined: Sat May 23, 2015 12:10 pm
- Contact:
Re: Make the API less rigid.
My point exactly.vzybilly wrote:If what I said before was fully correct in C++, then in modding we don't have access to it. I have seen a good deal of stuff inside the black box (C++) that I can't use via modding. I'd even be willing to learn C++ just to work on the Modding API (Scala/Java, 7 years), if given the hiring opportunity, very slowly otherwise.
There is so much functionality in the engine that mods just cannot use because the API simply doesn't allow it.
One of them is the electricity grid. The most annoying currently is the circuit network.
I expected a get_circuit_connector(id) method that returns a connector with a method to set the output and get the connected LUAcircuit entity per color where you can query the (other) entities connected to that circuit and read the state of it.
More over I didn't expect to have to request it explicitly.
Re: Make the API less rigid.
Have you tried to make a GUI?ratchetfreak wrote:My point exactly.vzybilly wrote:If what I said before was fully correct in C++, then in modding we don't have access to it. I have seen a good deal of stuff inside the black box (C++) that I can't use via modding. I'd even be willing to learn C++ just to work on the Modding API (Scala/Java, 7 years), if given the hiring opportunity, very slowly otherwise.
There is so much functionality in the engine that mods just cannot use because the API simply doesn't allow it.
One of them is the electricity grid. The most annoying currently is the circuit network.
I expected a get_circuit_connector(id) method that returns a connector with a method to set the output and get the connected LUAcircuit entity per color where you can query the (other) entities connected to that circuit and read the state of it.
More over I didn't expect to have to request it explicitly.
the only thing stopping an amazing mod is that I need a train-stop GUI under the logistic-request area of a logistic requester chest, but the style for the train-stop uses a list-box, which is an invalid GUI element.
I also don't see anywhere to attach a GUI to an entity, nor any way to see if a player has opened a chest, nor a way to see what things are open, nor a way to destroy the frame with the window close key.
The mod GUI just feels like it hasn't been updated at all, I would love to see them remove all the GUIs (in a world) and put them in the mod scripts and see how many of the GUI things get updates and how much their GUIs change.
In their mod folder (data folder, contents: base, changelog.txt, core, scenario-pack,), besides from the locale and none useful stuff (prints and such), they only use "gui" 72 times! 23 of which are from the base/campaigns section, only 8 of these are beta (not demo)
found by
http://pastebin.com/eGJZc7pb Raw output
useful
non-scenario
Will code for Food. I also have 11+ mods!
Re: Make the API less rigid.
Hi
Gmod modder here. Just skimmed this thread and I want to give my input.
I love Factorio. It's my new favourite game and I bought it immediately after watching the intro video. The only thing I dislike is the modding. Like you say, it's way too rigid. Everything you do feels like (and most often, is) a massive hack. And here I was thinking Gmod modding involved a lot of hacking (compared to factorio, it doesn't).
Basically, what you are describing in this thread is the way Gmod does modding. Gmod might have done some things wrong, but its modding is one thing it got very right in my opinion. It's easy to use, and you can do literally anything with it. I could remake factorio in it
I've attempted to mod factorio several times (never successfully), and what I've gathered so far is this: The way custom entities work in factorio is: you define a prototype (base class to inherit properties from, correct?). Then you can modify the properties of this object by defining a table (using data:extend( ... whatever ... )). Then you can define the custom lua code using events.
Gmod modding is slightly different. You can create a new entity and choose a base class for it. Most often, when people make a new mod, they will choose to start out with the entity called base_gmodentity, which does literally nothing. It just sits there. Then, instead of having a table of properties like factorio, you have the ability to place FUNCTIONS on the entity object (you can of course also create any other value on the entity). Then, these functions (assuming they have the proper name) are called by the engine itself. For example, an entity might have a function called "Initialize" (called when a new instance of the entity is created), or "StartTouch" (called when the entity collides with another entity), or "Think" (called every 0.5 seconds, but you can adjust the rate).
After you've defined the functions you require (you can also change these functions at any time), you are given nearly direct access to every possible function in the whole engine. Which means you can do whatever the fuck you want.
In Factorio's terms, this would be like giving access to a function called "SetInventory", which you could use to give any entity an inventory of your choice, such as that of a chest, or a crafting machine, instead of defining which inventory the machine has in a fixed predetermined table.
Of course, it might not even be possible to do this. I don't know how Factorio works internally. Also, Gmod doesn't have things like inventories. It's up to the modders to implement them by creating custom gui elements and storing the items in tables.
So, the main point here is this: Gmod has much the same way of handing events as Factorio does. However, Gmod also has the ability to add events to entities, which Factorio doesn't. Factorio also lacks the required functions to act on these events, and instead relies on predetermined constants which can't be changed once the game has loaded. If these two things are implemented, Factorio will be much easier to mod.
ALSO - PLEASE NOTE: If you do export every single engine function (or at least the useful ones), there is another solution. You could give users access to 1 completely empty base entity, which does nothing, and then handle all the inheritance and such in Lua. It's entirely possible, and I know how to do it.
See Gmod the wiki here
http://wiki.garrysmod.com/page/Main_Page
In any case, I will continue to play Factorio for a long time yet, with or without spending the time to learn how to hack together mods
Gmod modder here. Just skimmed this thread and I want to give my input.
I love Factorio. It's my new favourite game and I bought it immediately after watching the intro video. The only thing I dislike is the modding. Like you say, it's way too rigid. Everything you do feels like (and most often, is) a massive hack. And here I was thinking Gmod modding involved a lot of hacking (compared to factorio, it doesn't).
Basically, what you are describing in this thread is the way Gmod does modding. Gmod might have done some things wrong, but its modding is one thing it got very right in my opinion. It's easy to use, and you can do literally anything with it. I could remake factorio in it
I've attempted to mod factorio several times (never successfully), and what I've gathered so far is this: The way custom entities work in factorio is: you define a prototype (base class to inherit properties from, correct?). Then you can modify the properties of this object by defining a table (using data:extend( ... whatever ... )). Then you can define the custom lua code using events.
Gmod modding is slightly different. You can create a new entity and choose a base class for it. Most often, when people make a new mod, they will choose to start out with the entity called base_gmodentity, which does literally nothing. It just sits there. Then, instead of having a table of properties like factorio, you have the ability to place FUNCTIONS on the entity object (you can of course also create any other value on the entity). Then, these functions (assuming they have the proper name) are called by the engine itself. For example, an entity might have a function called "Initialize" (called when a new instance of the entity is created), or "StartTouch" (called when the entity collides with another entity), or "Think" (called every 0.5 seconds, but you can adjust the rate).
After you've defined the functions you require (you can also change these functions at any time), you are given nearly direct access to every possible function in the whole engine. Which means you can do whatever the fuck you want.
In Factorio's terms, this would be like giving access to a function called "SetInventory", which you could use to give any entity an inventory of your choice, such as that of a chest, or a crafting machine, instead of defining which inventory the machine has in a fixed predetermined table.
Of course, it might not even be possible to do this. I don't know how Factorio works internally. Also, Gmod doesn't have things like inventories. It's up to the modders to implement them by creating custom gui elements and storing the items in tables.
So, the main point here is this: Gmod has much the same way of handing events as Factorio does. However, Gmod also has the ability to add events to entities, which Factorio doesn't. Factorio also lacks the required functions to act on these events, and instead relies on predetermined constants which can't be changed once the game has loaded. If these two things are implemented, Factorio will be much easier to mod.
ALSO - PLEASE NOTE: If you do export every single engine function (or at least the useful ones), there is another solution. You could give users access to 1 completely empty base entity, which does nothing, and then handle all the inheritance and such in Lua. It's entirely possible, and I know how to do it.
See Gmod the wiki here
http://wiki.garrysmod.com/page/Main_Page
In any case, I will continue to play Factorio for a long time yet, with or without spending the time to learn how to hack together mods