[engine]: New [event] battle names (DONE, available here)
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
[engine]: New [event] battle names (DONE, available here)
Hi,
The idea has been made available for UMC authors. Scroll to the bottom of the post.
I think it could prove useful to append the list of predefined event names with a new way to describe fights.
We currently have: attack,attack end,attacker hits,defender hits,attacker misses,defender misses.
These can describe all attack events an author needs, but they all share a common feature: the attacker and defender roles define the primary and secondary filters. This is a very good thing to have, but in some but not rare cases it overcomplicates things in my opinion.
For instance: Let's say I want to do something (labeled <...>) every time an ambusher unit hits someone. Regardless of being attacker, or being attacked. (One could say: regardless of which side's turn it is).
Currently the code to do this is:
This is obviously long, and not pretty way to do it. My problem is, we need TWO [event]s to carry out ONE action. Sure it can be done by including <...> into a custom event and with the attacker/defender hits events we could fire it. I'm not saying it can't be done/solved/worked around. But it is still more complex than it should be, and it could discourage beginner coders.
What I'm proposing is not essential, it could only come in handy a couple of times.
The name=combat attribute should act the same way the name=attack does, except that the attacker and defender roles should not be cast. Example:
This code will make any skeleton say the message, regardless of being attacked or being the attacker.
The secondary filter is completely optional at any time.
If a secondary filter is provided, then the behaviour should be that the event only fires at the fight of two units described in the filters. In this sense, [filter] and [filter_second] should be absolutely commutable, since attacker and defender roles have no meaning on them.
The combat event could be extended to describe any part of the fight, just like attack does:
This fires every times a Spearman kills someone, regardless of it being done in offense or defense.
So why not have events with this same behaviour, but not for a kill, simply just for a fight?
EDIT 1:
If you are an UMC author and would like to use the combating events, download this file: Include it into your work as a util. If you want to use combating events in a scenario, include {ENABLE_COMBAT_EVENTS} into the scenario toplevel tag. Then you're free to go. Enjoy
The idea has been made available for UMC authors. Scroll to the bottom of the post.
I think it could prove useful to append the list of predefined event names with a new way to describe fights.
We currently have: attack,attack end,attacker hits,defender hits,attacker misses,defender misses.
These can describe all attack events an author needs, but they all share a common feature: the attacker and defender roles define the primary and secondary filters. This is a very good thing to have, but in some but not rare cases it overcomplicates things in my opinion.
For instance: Let's say I want to do something (labeled <...>) every time an ambusher unit hits someone. Regardless of being attacker, or being attacked. (One could say: regardless of which side's turn it is).
Currently the code to do this is:
Current way:
What I'm proposing is not essential, it could only come in handy a couple of times.
The name=combat attribute should act the same way the name=attack does, except that the attacker and defender roles should not be cast. Example:
Code: Select all
[event]
name=combat
first_time_only=no
[filter]
type=Skeleton
[/filter]
[message]
speaker=unit
message= _ "I've just engaged the enemy!"
[/message]
[/event]
The secondary filter is completely optional at any time.
If a secondary filter is provided, then the behaviour should be that the event only fires at the fight of two units described in the filters. In this sense, [filter] and [filter_second] should be absolutely commutable, since attacker and defender roles have no meaning on them.
Example with given secondary filter:
- combat: Triggers when the units described in the filters engage each other.
- combat end: Similar to combat, but triggers after the fight, not before. Triggers before die events.
- combatant hits: Triggers when the unit described in the primary filter delivers a hit onto its enemy. (If the enemy is specified with [filter_second], the event only fires if the primary unit engages AND hits the unit in the secondary filter). Note that this fires regardless of who's attacking who, only the hit is what matters.
- combatant misses: Triggers when the unit described in the primary filter misses.
Code: Select all
[event]
name=die
first_time_only=no
[filter_second]
type=Spearman
[/filter_second]
[/event]
So why not have events with this same behaviour, but not for a kill, simply just for a fight?
EDIT 1:
If you are an UMC author and would like to use the combating events, download this file: Include it into your work as a util. If you want to use combating events in a scenario, include {ENABLE_COMBAT_EVENTS} into the scenario toplevel tag. Then you're free to go. Enjoy
Example:
Note on behaviour:
Last edited by WhiteWolf on September 6th, 2016, 8:50 pm, edited 2 times in total.
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
-
- Inactive Developer
- Posts: 503
- Joined: April 24th, 2016, 4:18 pm
Re: Idea: New [event] names connected to fights
Combine the event names in a comma-separated list, and use an [if] instead of filtering when [filter_condition] won't fit the bill. I think everything you're asking can be done in a single filter.
Also, even if you choose to use separate filters to begin the event, using a custom filter for the bulk of the processing should eliminate duplicated code.
Also, even if you choose to use separate filters to begin the event, using a custom filter for the bulk of the processing should eliminate duplicated code.
I forked real life and now I'm getting merge conflicts.
Re: Idea: New [event] names connected to fights
I stated somewhere that I'm aware that every aspect I mentioned as examples can be carried out in several different ways.
I plainly proposed that it may come in handy for some to have a very explicit and short way to write the events in question.
I plainly proposed that it may come in handy for some to have a very explicit and short way to write the events in question.
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
-
- Inactive Developer
- Posts: 503
- Joined: April 24th, 2016, 4:18 pm
Re: Idea: New [event] names connected to fights
That's fine but the question is: is there anything new?
Simply proposing a name which does what two names do if you combine them in a list is just adding complexity for no real gain. Is there anything which you cannot do currently?
Simply proposing a name which does what two names do if you combine them in a list is just adding complexity for no real gain. Is there anything which you cannot do currently?
I forked real life and now I'm getting merge conflicts.
Re: Idea: New [event] names connected to fights
I don't recall ever desiring the "combat" event, but the current attacker/defender hits/misses events are really awkward because of the way the primary and secondary units switch places. I'd definitely welcome two general-purpose hits/miss events which simply trigger when the primary unit hits/misses the secondary unit.
Re: Idea: New [event] names connected to fights
I agree that the attacker/defender hits/misses events are really awkward.
If yo want sucha sutom even in 1.12 you can just add code like
If yo want sucha sutom even in 1.12 you can just add code like
Code: Select all
[event]
name="attacker hits"
[fire_event]
name=hits
[fist_unit]
x,y =x1,y1
[/fist_unit]
[second_unit]
x,y =x2,y2
[/second_unit]
[/fire_event]
[/event]
[event]
name="defender hits"
[fire_event]
name=hits
[fist_unit]
x,y =x2,y2
[/fist_unit]
[second_unit]
x,y =x1,y1
[/second_unit]
[/fire_event]
[/event]
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
Re: Idea: New [event] names connected to fights
In my experience, there can be well-placed arguments both for and against the current behaviour of the defender hits/misses. Sometimes it comes in handy and keeps things consistent. Sometimes, it is really awkward.
Maybe just debate the creation of "name=combatant hits"? I just thought maybe the others could prove useful as well in some cases.
You could really build up something general by setting primary and secondary units inside the fire_event, I had not thought of that. A macro could be made... something like ALLOW_COMBATANT_EVENTS, this could work for UMC authors. But it is still not anything core-defined
I'll try what I can do to define these and I'll upload, see if it does the trick.
EDIT:
This can be done
Here is the code:
Copy the whole thing into an event-utils.cfg, enable with {ENABLE_COMBAT_EVENTS}, and there you have it all. I'll also edit this into the top post.
Still, it could be nice to have this as a core function.
Maybe just debate the creation of "name=combatant hits"? I just thought maybe the others could prove useful as well in some cases.
You could really build up something general by setting primary and secondary units inside the fire_event, I had not thought of that. A macro could be made... something like ALLOW_COMBATANT_EVENTS, this could work for UMC authors. But it is still not anything core-defined
I'll try what I can do to define these and I'll upload, see if it does the trick.
EDIT:
This can be done
Here is the code:
New events codes:
Still, it could be nice to have this as a core function.
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny