Factorio Forums

It would be nice to have subj.
And 'onentityclick' event to open custom gui.

And for things to be supernice it's good to have something like 'action_period_ticks' property
and 'onentityaction' event that is called every action_period_ticks.
In case of energy shartage it should be called with bigger period.

The definitions are there in the base data, and customized easily enough.
TreeFarm Mk2 has a custom GUI on click... Or so I believed.

This all really needs better explanation, and I'm sure most of what you're looking for already exists in a form you're not recognizing.
Maybe try again after getting some sleep?

n9103 wrote:TreeFarm Mk2 has a custom GUI on click... Or so I believed.

Yes and no
I use a workaround for this, so there is no built-in "onentityclick"-event
(I use the "onput"-event and check if it was raised over a specific-entity, so it only works if an item is attached to the cursor)

For the treefarm example it's an advantage doing it like that, because you can access the custom-gui and the default (inventory)-gui, but there are cases in which you might don't want to allow access to the normal gui and display the custom one instead of it.

And what exactly do you mean with 'action_period_ticks' property
and 'onentityaction' event that is called every action_period_ticks?

There is 'type' of entity. And it must be one of existing types. And your entity will derive behaviour of that type.
And treefarm's custom gui doesn't open 'onclick'. When you click you open standard chest gui, which is 'type' of treefarm field entities.
To open custom gui you have to click with item in hand, which is only possible to handle for chests.
Treefarm doesn't consume energy. Because chest doesn't consume energy. And you can't add energy.
If there is a way to make an entity that consumes electricity and can have custom gui simply on click, then tell me pls.
ATM there are only two types I'm aware of that do not have standard gui - lamp and pump. But energy consumption of lamp depends on time of day.
So the only one that remains is pump with no pipe connectors.
But you can't handle clicks on it.
For entities that consume fuel everything is even worse. You can't have fuel slots AND custom gui in one piece.

And what exactly do you mean with 'action_period_ticks' property
and 'onentityaction' event that is called every action_period_ticks?

For example you want to make a 'treecutter' machine that cuts one tree (in radius of operation) every 2 seconds.
Right now you have to:
1) handle creation and destruction of treecutters to maintain list of existing enitities just for the sake of 2.
2) in ongametick you need to iterate over all treecutters, check their operation time and subtract energy for treecutters that are actually working.

What would make this much easier - define:
action_period_ticks=120,
in definition of treecutter.
Than install onentityaction handler that is called for every active treecutter one every 2 seconds.
Or every 4 seconds if energy satisfaction is 50%.
Probably for this to work properly there should be some kind of operation mode.
operating - onentityaction is called and entity consumes energy
idle - onentityaction is called, but entity doesn't consume energy (except for drain).
nonoperating - neither onentityaction is called nor energy is consumed

The workaround should work on all (selectable) entity-types.
But like I said that wouldn't block the access to the default gui...

Xecutor wrote: For example you want to make a 'treecutter' machine that cuts one tree (in radius of operation) every 2 seconds.
Right now you have to:
1) handle creation and destruction of treecutters to maintain list of existing enitities just for the sake of 2.
2) in ongametick you need to iterate over all treecutters, check their operation time and subtract energy for treecutters that are actually working.

1) Imo not a big deal
2) Or you use a queue and only check the first element. But yes, that only makes sense if the period is fixed and doesn't depend on other factors that might change inbetween (e.g. energy satisfaction)

I'm still believe that doing it like that is a good thing, because it's a good universal solution. But like all universal things it has some drawbacks in special cases.

Xecutor wrote:Probably for this to work properly there should be some kind of operation mode.
operating - onentityaction is called and entity consumes energy
idle - onentityaction is called, but entity doesn't consume energy (except for drain).
nonoperating - neither onentityaction is called nor energy is consumed

But once you set the entity state to nooperation you're back at 1) maintaining a list of entities, because the actionHandler isn't called anymore for this entity and so cannot be used to change the state

Also you suggested that the period between 2 events should depend (linearly) on the energy-satisfaction, but what if someone else want a exponetial dependency or no energy-dependency at all?

Which leads back to my opinion about 2):
A good universal solution should be preferred over a perfect solution just for one specific case.