WML Problem

[gadget005]

I've got a problem with a scenario i've written for my campaign.

When I try to load up the campaign, I get an error message (image below).

I've looked through the WML a number of times and found some little things that would have caused problems, but the problem hasn't been fixed.

Can someone with better knowledge of WML look into it for me please? Thanks.

[zookeeper]

Don't expect much help if you give people 1000 lines to debug.

Anyway, here's one, there's probably more:

Code: Select all

	ifdef HARD

[gadget005]

Cheers zookeeper, that got rid of that problem.

However, another problem's arisen (see image).

This time, it's in the macros file (which is NOT 1000 lines, more like 150).

Don't expect much help if you give people 1000 lines to debug

Err....yeah, sorry about that.

[zookeeper]

However, another problem's arisen (see image).

macros.cfg, line 11.

Don't expect much help if you give people 1000 lines to debug

Err....yeah, sorry about that.

My point was basically that people are much more likely to help if they don't have to spend time wondering what part of your campaign they should be looking at (ok, error messages give hints, but they can be very obscure and misleading at times). I just happened to write a small sticky about debugging big amounts of WML, which you actually seemed to have noticed already.

[gadget005]

macros.cfg, line 11.

Done, still getting error though.[/quote]

[gadget005]

Ok, having done as zookeeper suggested in his sticky, I have narrowed the problem down to this code:

Code: Select all

#define RANDOM_X RANGE
	[set_variable]
		name=randomx
		random={RANGE}
	[/set_variable]
#enddef

#define RANDOM_Y RANGE
	[set_variable]
		name=randomy
		random={RANGE}
	[/set_variable]
#enddef

#define UNIT TYPE DESC SIDE
	{RANDOM_X 2-59}
	{RANDOM_Y 27-30}
	[unit]
		side={SIDE}
		type={TYPE}
		description={DESC}
		generate_description=yes
		upkeep=loyal
		x=$randomx
		y=$randomy
		[modifications]
			{TRAIT_LOYAL}
		[/modifications]
	[/unit]
	[store_unit]
		variable=newunit
		[filter]
			x=$randomx
			y=$randomy
		[/filter]
		kill=yes
	[/store_unit]
	[unstore_unit]
		variable=newunit
		find_vacant=yes
	[/unstore_unit]
#enddef

I thought it might have been the $randomx/$randomy bit, but I replaced it with proper numbers and it still wouldn't work.

[ILikeProgramming]

Code: Select all

   
[store_unit] 
      variable=newunit 
      [filter] 
         x=$randomx 
         y=$randomy 
      [/filter] 
      kill=yes 
   [/store_unit] 
   [unstore_unit] 
      variable=newunit 
      find_vacant=yes 
 [/unstore_unit]

Whats the point of storing a unit and then unstoring it???

[zookeeper]

Funny, I don't really see anything wrong with that. Are you sure the problem is with those macro definitions, and not in places where you actually use the macros? One of the most common (and annoying) WML bugs is when you use a macro but give it the wrong number of arguments.

Anyway, if you're sure the problem is with that bit, then I suppose I'd first try to check if {RANDOM_X 2-59} and {RANDOM_Y 27-30} confuse the WML parser somehow - enclosing arguments in parentheses or quotes usually works, which in this case would mean for example doing them like this: {RANDOM_X (2-59)}. I'd find it slightly odd if that helped nevertheless.

[gadget005]

Whats the point of storing a unit and then unstoring it???

The point was that if two units being created somehow got given the same coordinates, the store_unit/unstore_unit would mean that one didn't end up removing the first, and would go to a vacant spot instead.

first try to check if {RANDOM_X 2-59} and {RANDOM_Y 27-30} confuse the WML parser somehow

Did that, but didn't do anything.

Are you sure the problem is with those macro definitions, and not in places where you actually use the macros?

The following is where I call the UNIT definition in the scenario.

Code: Select all

[event]
        name=prestart
        ......
	{UNIT (TIoE_Human Swordsman) () 1}
	{UNIT (TIoE_Human Swordsman) () 1}
	{UNIT (TIoE_Human Swordsman) () 1}
	{UNIT (TIoE_Human Swordsman) () 1}
[/event]

[zookeeper]

Are you sure the problem is with those macro definitions, and not in places where you actually use the macros?

The following is where I call the UNIT definition in the scenario.

Code: Select all

[event]
        name=prestart
        ......
	{UNIT (TIoE_Human Swordsman) () 1}
	{UNIT (TIoE_Human Swordsman) () 1}
	{UNIT (TIoE_Human Swordsman) () 1}
	{UNIT (TIoE_Human Swordsman) () 1}
[/event]

A-ha. There's a macro called UNIT in the default data/utils.cfg, which of course clashes with yours - I suppose the engine tries to use the other one, for which the number of arguments is then of course wrong.

So, try either renaming your macro to something that doesn't clash with any other macro, or put an #undef UNIT line just before you define "your version" of the UNIT macro. #undef should clear any previous definition for the given macro.

[gadget005]

Problem sovled.

I realised that the core utils.cfg has a UNIT definition that was different to my UNIT definition, so I changed my definition to UNIT_R and it now works.

Thanks to those who looked into the code.



Edit: didn't see you're message zookeeper. Thanks for checking.