An almost all-out code idea

[toms]

The [side] tag currently includes the unit configurations of the leader, using the same keys as a [unit] tag does. (maybe I´m wrong for a few exceptions, I did not mind all now)
This might be confusing for newbies.
As this also would IMO offer more overview, I suggest:

Code: Select all

[side]
controller=human
canrecruit=1
recruit=Elvish Fighter,Elvish Archer,Elvish Scout,Elvish Shaman
gold=100
team_name=good
 #borrowed Konrad here
 [leader]
 type=Fighter
 description=Konrad
 user_description=_"Konrad"
 unrenameable=yes
 [/leader]
[/side]

And the leader tag is not required with no_leader=yes.

What do you think about?

[Darth Fool]

It seems to me that if no [leader] tag was specified it would be simpler if no_leader=yes is assumed.

[toms]

You mean no [leader] tag is automatically treated as no_leader=yes? That would be senseful, yes.

[scott]

I like it. I have seen lots of conventions for organizing the keys inside a [side] tag, and this makes sense. I wonder if you could have multiple [leader] tags.

[Sapient]

Hmm... I'm not sure this would be a good change for multiplayer wml, although it would be nice to optionally define the preferred (mp) era and (side) faction, leader.

[Kharn]

I saw that user_description=

is there a way to use that in a regular unit file?

[scott]

Hmm... I'm not sure this would be a good change for multiplayer wml, although it would be nice to optionally define the preferred (mp) era and (side) faction, leader.

The current WML for multiplayer sides isn't that great either:

Code: Select all

	[side]
	side=1
	canrecruit=1
	controller=human
	team_name=south
	[/side]

It wouldn't be good to have the above code automatically signify a no_leader side, but something could be done.

[turin]

I like it, although IMHO backwards compatibility is a good thing - if this could be implemented, while still allowing (for a limited time) the use of [side] only, that would be best.


BTW, canrecruit=1 should go inside the [leader], not outside. Canrecruit is a characteristic of the leader unit, not of the side it is on. You can even have multiple units on a side with canrecruit=1, although it can make the game... odd.

[MadMax]

What I'd like to see would be a way to define side numbers as allies and enemies rather than being constrained to team_names (like it used to be before the team_name system was implemented). This way, a side could be scripted to attack only certain enemies, which would come in handy if you want a side to not fight back.

[scott]

What I'd like to see would be a way to define side numbers as allies and enemies rather than being constrained to team_names (like it used to be before the team_name system was implemented). This way, a side could be scripted to attack only certain enemies, which would come in handy if you want a side to not fight back.

If this kind of behavior existed, it surely would be programmable inside [ai].

[deserter]

You can even have multiple units on a side with canrecruit=1, although it can make the game... odd.

Can you really? Of course you can, but it doesn't work AFAIK. Do you mean by 'odd' that it's odd to have multiple leaders, or that it doesn't work like you would expect?

[turin]

You can even have multiple units on a side with canrecruit=1, although it can make the game... odd.

Can you really? Of course you can, but it doesn't work AFAIK. Do you mean by 'odd' that it's odd to have multiple leaders, or that it doesn't work like you would expect?

Doesn't work like you would expect. IIRC, what happens is that you need both units that have canrecruit=1 in the castle to recruit, and if either dies, you lose.

But the point is, it IS a characteristic of the unit, not of the side, and should be treated as such by this suggestion.

[bruno]

What I'd like to see would be a way to define side numbers as allies and enemies rather than being constrained to team_names (like it used to be before the team_name system was implemented). This way, a side could be scripted to attack only certain enemies, which would come in handy if you want a side to not fight back.

The last time I looked at things I found that multiple leaders don't work sensibly and fixing that is not as easy as one might expect going in. Different places check for leaders in slightly different ways. And in some places, changing to iterate over multiple leaders wasn't a nobrainer change.
Ideally there should be a function that returns an iterator over all of the leaders on a side and all of the code that checks for leaders would use that function.