Theron's wml questions
Moderator: Forum Moderators
Forum rules
- Please use [code] BBCode tags in your posts for embedding WML snippets.
- To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
Theron's wml questions
In a certain scenario there are 2 acquirable objects:
(1) sets all melee attacks to berserk.
(2) gives a new melee attack.
Objekt 1 + objekt 2 != object 2 + object 1
While I think its not a bug I wonder if its safe to assume that the object effects are always applied in this order (especially if the unit levels up).
What are my options if I want to make sure that really _all_ melee attacks will get berserk?
Drop and pick up the items in the "correct" order?
(1) sets all melee attacks to berserk.
(2) gives a new melee attack.
Objekt 1 + objekt 2 != object 2 + object 1
While I think its not a bug I wonder if its safe to assume that the object effects are always applied in this order (especially if the unit levels up).
What are my options if I want to make sure that really _all_ melee attacks will get berserk?
Drop and pick up the items in the "correct" order?
question about sighted events
While fixing sighted events I had a look at others code.
I have found a macro which checks for:
'A' sees 'B'
'B' sees 'A'
'A' attacks 'B'
'B' attacks 'A'
The seeing part is obvious but I wonder if its even possible to attack (maybe involving ambush?) without not triggering the seeing part?
I have found a macro which checks for:
'A' sees 'B'
'B' sees 'A'
'A' attacks 'B'
'B' attacks 'A'
The seeing part is obvious but I wonder if its even possible to attack (maybe involving ambush?) without not triggering the seeing part?
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: question about sighted events
Depends on how they define "see" and such.
name=sighted events are inherently buggy since long (ever) ?. Avoid them whenever possible, especially if you set variables in them or do other stuff which would break your scenario if it's not executed. Use other events types instead, movetos are often a good replacement.
name=sighted events are inherently buggy since long (ever) ?. Avoid them whenever possible, especially if you set variables in them or do other stuff which would break your scenario if it's not executed. Use other events types instead, movetos are often a good replacement.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
- Pentarctagon
- Project Manager
- Posts: 5565
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: non-commutative object effects
Object effects are always applied to current attacks, not any that are added, so to get the special(s) onto added attacks you will need to check if that unit has the berserk item and if it does then give berserk to the new attack as well.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
question about unit variants
In a certain campaign there are drake foes.
In a few scenarios they are normal drakes (now 1.9.x core units).
In other scenarios they are invisible drakes (copies of 1.6 (or 1.4?) core units with image="" and so on).
Invisibility is granted by the big bad boss.
Otherwise I think they should be ordinary drakes.
The problem is: ATM some stats differ between core drakes and invisible drakes.
Which is preferable?
a) Change the existing copies (e.g. introduce reef terrain).
b) Redo them with fresh copies from core.
c) Is WML capable of inheriting the invisible drakes from core and just applying modifications to images, animations, … (so its easier to stay in sync)?
In a few scenarios they are normal drakes (now 1.9.x core units).
In other scenarios they are invisible drakes (copies of 1.6 (or 1.4?) core units with image="" and so on).
Invisibility is granted by the big bad boss.
Otherwise I think they should be ordinary drakes.
The problem is: ATM some stats differ between core drakes and invisible drakes.
Which is preferable?
a) Change the existing copies (e.g. introduce reef terrain).
b) Redo them with fresh copies from core.
c) Is WML capable of inheriting the invisible drakes from core and just applying modifications to images, animations, … (so its easier to stay in sync)?
- Alarantalara
- Art Contributor
- Posts: 787
- Joined: April 23rd, 2010, 8:17 pm
- Location: Canada
Re: question about unit variants
Check out [base_unit] in the unit type definition. It does exactly c).
- Pentarctagon
- Project Manager
- Posts: 5565
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: question about unit variants
Also, you already have an active thread in this forum, so could you post these questions in that thread instead of making a bunch of smaller ones?
Merged Theron's threads - Anonymissimus
Merged Theron's threads - Anonymissimus
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code