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.
Generic electric/fueled entity
Re: Generic electric/fueled entity
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?
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?
Re: Generic electric/fueled entity
Yes and non9103 wrote:TreeFarm Mk2 has a custom GUI on click... Or so I believed.
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?
Re: Generic electric/fueled entity
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.
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
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.
For example you want to make a 'treecutter' machine that cuts one tree (in radius of operation) every 2 seconds.And what exactly do you mean with 'action_period_ticks' property
and 'onentityaction' event that is called every action_period_ticks?
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
Re: Generic electric/fueled entity
The workaround should work on all (selectable) entity-types.
But like I said that wouldn't block the access to the default gui...
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.
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.
But like I said that wouldn't block the access to the default gui...
1) Imo not a big dealXecutor 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.
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.
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 stateXecutor 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
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.