The Other's ability problems

[zookeeper]

setting_adaptive_resistance[$i]resistance.blade

That's not the way to address member variables, setting_adaptive_resistance[$i].resistance.blade is.

[The_Other]

.....And still nothing...

I think I may have figured out where the problem lies, but I'm not sure how to fix it. I suspect one of two possibilities:

Code: Select all

[set_variable]
					name=setting_adaptive_resistance[$i].resistance.adaptive
					value=$setting_adaptive_resistance[$i].resistance.blade
				    [/set_variable]

The value key here doesn't look right to me, but I could well be wrong.
Or:

Code: Select all

 (Pseudo-code to clearly show nesting structure - see last code posted if this is not as clear as I intend it to be!)
		[if]
		    .....
				[then]
				    .....
				[/then]
		    [else]
			[if]
			    .....
				[then]
				    .....
			    	[/then]
			    [else]
			    	.....
			    [/else]
			[/if]
		    [/else]
		[/if]

Is there a problem with my use of logic gates? Clearly some of them nest within others, but have I arranged them properly?

[JaMiT]

greater_than=setting_adaptive_resistance[$i]resistance.pierce

This needs to be set to a variable value, not a variable name. (Use another dollar sign. Plus the period that was already pointed out.)

Your logic for calculating the maximum of three values is off. Think about what would happen if impact > blade > pierce.

[The_Other]

It works now, thank you everyone!

It still displays the damage type as UNTLB type_adaptive, but I can live with that (at least until I work out how to fix it without re-writing all the movement_types!)

It turns out that, as well as my missing '$'s and defective use of logic gates (and I studied logic in school! ), I was missing an id= key, which is apparently required for all events invoked from within [unit_type]. So even if my syntax and logic had been right, the event just wasn't firing (probably should have included a [message], then I would have picked up on this sooner!)

The code, for anybody who wants it:

Code: Select all

#define WEAPON_SPECIAL_ADAPTIVE
	[dummy]
	    id=adaptive
	    name= _ "adaptive"
	    description= _ "Adaptive:
This attack will identify and exploit the enemy's weaknesses.

Adaptive attacks are resolved using the enemy's weakest physical resistance (blade, impact or pierce)."
	[/dummy]
#enddef

#define ADAPTIVE_WEAPONRY
	[event]
	    name=start,attack,post_advance,side_turn_end
	    first_time_only=no
	    id=adaptive_weaponry
		[store_unit]
		    [filter]
			[filter_wml]
			    [not]
				[status]
				    adaptive_resistance_set=yes
			    	[/status]
			    [/not]
			[/filter_wml]
		    [/filter]
			variable=setting_adaptive_resistance
		[/store_unit]
	    {FOREACH setting_adaptive_resistance i}
		[if]
		    [variable]
			name=setting_adaptive_resistance[$i].resistance.blade
			greater_than=$setting_adaptive_resistance[$i].resistance.pierce
		    [/variable]
			[and]
			    [variable]
				name=setting_adaptive_resistance[$i].resistance.blade
				greater_than=$setting_adaptive_resistance[$i].resistance.impact
			    [/variable]
			[/and]
				[then]
				    [set_variable]
					name=setting_adaptive_resistance[$i].resistance.adaptive
					value=$setting_adaptive_resistance[$i].resistance.blade
				    [/set_variable]
				[/then]
		    [/if]
			[if]
			    [variable]
				name=setting_adaptive_resistance[$i].resistance.pierce
				greater_than=$setting_adaptive_resistance[$i].resistance.impact
			    [/variable]
				    [and]
					[variable]
					    name=setting_adaptive_resistance[$i].resistance.pierce
					    greater_than=$setting_adaptive_resistance[$i].resistance.blade
					[/variable]
				    [/and]
				[then]
				    [set_variable]
					name=setting_adaptive_resistance[$i].resistance.adaptive
					value=$setting_adaptive_resistance[$i].resistance.pierce
				    [/set_variable]
			    	[/then]
			    [else]
			    	[set_variable]
				    name=setting_adaptive_resistance[$i].resistance.adaptive
				    value=$setting_adaptive_resistance[$i].resistance.impact
			    	[/set_variable]
			    [/else]
			[/if]
				[set_variable]
				    name=setting_adaptive_resistance[$i].status.adaptive_resistance_set
				    value=yes
				[/set_variable]
				    [unstore_unit]
				    	variable=setting_adaptive_resistance[$i]
				    [/unstore_unit]
		{NEXT i}
		{CLEAR_VARIABLE setting_adaptive_resistance}
	[/event]
#enddef

Thanks again!

[The_Other]

Okay, another one:
Is there any sensible way to implement a 'Detection' ability, which would make hidden units visible within a fixed radius?
I know it can be done in a very simple sense, by setting uncovered=yes (I think that's the right name?) for all units within R hexes (R being, in this instance, equal to the detecting unit's normal vision range, ie. equal to its max_moves + 1).
The problem with this approach is that it will then make the detected units visible to all players, which doesn't seem to make much sense. I can think of a really clumsy method wherein all units get 'blinded' when it isn't their turn (set max_moves=0 at turn end, then restore to proper value at side_turn), but then they can't see non-hidden units either.
Is there any way of implementing this properly, such that detecting units only can see hidden units within their normal visibility range, without blinding other players or exposing units to people who shouldn't see them?

[Sapient]

You could use an unsynchronized event (e.g. "select") to display an overlay to one player.

[fabi]

The_Other, you have there a good point, I didn't thought about multiple sides being able to see the unit if uncovered this way.
I will think about adding an ability called detects or similar which takes the id of the [hides] ability its supposed to work against.

[The_Other]

@Sapient - I have no idea what that means or how to do it
I'll go look it up...

@Fabi - I think an ideal solution would be a [detect] function within [abilities], which would take all the same keys and filters as [hides], with the addition of a radius= key. If my logic is correct, you could then tailor [detect] abilities in the way you described, with the bonus that you wouldn't need to know specific IDs (so that detection abilities wouldn't need to be rewritten whenever new custom abilities were introduced).
For instance, you could effectively set it to reveal only units with Ambush, by including a terrain filter inside [detect] which causes it to only reveal units who are in forest hexes.

Reading that back to myself, there may be a problem if a unit has (for instance) both Ambush and Nightstalk, and is satisfying the conditions for both. Possibly this could be avoided by manipulating the order in which the game engine processes [hides] and [detect] abilities. Note that I don't know C++ or understand the game engine, but by purely logical analysis I think it can be solved by processing in the following sequence:

Suggestion made in ignorance by a non-programmer

1. All terrain-dependent [hides] abilities (units with Ambush are now flagged as being hidden)
2. All terrain-dependent [detect] abilities (thus revealing all units with Ambush only)
3. All time-of-day-dependent [hides] abilities (so that units with Nightstalk become flagged as hidden after they are checked by Detect_Ambush)
4. All t-o-d-dependent [detect] abilities (catching Nightstalk units, but not those whose [hides] abilities are filtered on other conditions)
5. Any other [hides] abilities (eg. I use 'Camouflage', which hides units who are eligible for rest-healing)
6. Other [detect] abilities (Detect_Camouflage now catches units who dodged other versions of [detect])
## Any other variations go between steps 6 and 7
7. Unfiltered [hides] abilities (constant invisibility)
8. Unfiltered [detect] abilities (the last thing to be processed, so it catches ALL hidden units)

I have no idea whether the game engine can do this, or whether it is possible or practical to make it do this, but as far as I can see this would be the ideal solution from a UMC-creator's perspective. If this isn't realistic, then I think Fabi's suggestion (state specific IDs of [hides] abilities to be detected) would be the second-best option - with the caveat that an empty or absent ID key in [detect] should function as an empty [filter], and thus work against ALL forms of [hides])

Um, should I repost this as a feature request?

[fabi]

Um, should I repost this as a feature request?

Yes, please.

[Sapient]

My post was not really a recommendation but just describing the possibility of a crude workaround.
Of course it would be better to have a real feature than to attempt a crude workaround.

[The_Other]

Feature Request

Okay, so I had a look at ReferenceWML (sometimes it feels like I live in that thing!), and I think I have a workaround. I'm not sure about it though, so I'm hoping that somebody can tell me if I'm on the right track before I start trying to code the thing.
My idea is to use side_turn and moveto events to store the locations of all the current player's units with the Detection ability (into detector_locations), and locations and types of all units that are currently hidden (into hidden_locations). Then, use a select event (which I believe is specific to the currently-active player?) to iterate over all hidden_locations and determine if they are within N hexes of any detector_location. Any hidden_locations that meet this criterion are then marked with an [item] which uses the same graphic as the baseframe of the unit hiding at that location. If I've understood correctly, since they are triggered by a (non-synched) select event, these [item]s should only appear to the player whose turn it is.

Is this a sensible way to proceed, or have I misunderstood something?

[zookeeper]

Unless you need it to work right for more than 2 teams, you could just modify each ambusher's hiding ability to only work if there are no detecters within x hexes.

[The_Other]

Unfortunately it's intended for a multiplayer faction, so there's a high possibility of more than two teams existing in at least some matches...
Also, if possible I'd like it to also work with abilities either from mainline or other people's UMC (who presumably will not have allowed for it when creating custom abilities). In an ideal world, it would be nice if it could work properly with all [hides] abilities, with no modification needed to those abilities (because all necessary code would be included in the Detection ability/event). That way, it also becomes available to other UMC-makers, without them needing to change anything.

[Sapient]

sounds good though I would make the overlays partially transparent

[The_Other]

Good to know I'm on the right track, I'll be back in about 15 years when I've figured out how to write the damn thing...
*Backflips joyfully, then dives back into the Great WML Ocean*