Dixie's Thread

[Dixie]

I struggled, but I managed my way around creating new terrains. Thanks guys!

[Dixie]

Ok, so I decided it would be nice if I had a message of some sort at the end of my paintball games before eliminated teams lost their leaders and the thing was aborted in an eye blink. I'm using a FOREACH macro to filter losers from winners, and I decided it would be simpler if I went with a [print] and a [sound] than a message. I also thought that the FOREACH would rush everything at the same time, so I decided a [delay] was probably required. However, and I'm not sure if did something wrong or just misunderstood some functionnality in the code, instead of each iteration of the FOREACH printing the message, waiting two seconds and moving on to the next iteration, it's like if my app played all the [sound]s at once, lagged a bit (waited all the delays at once?) then printed all the messages at once (which is to say: only printed the last message). Print which is barely visible at all, since at that very moment all eliminated leaders are killed, the victory/defeat message is shown a few seconds and the game auto-quits (and that's when the whole thing doesn't crash). I tried moving the [delay] to some other places in the code, even removing it altogether, but it didn't get better. Here's the sensible part of the code:

Spoiler:

Code: Select all

{FOREACH paintball_team i}
 {IF_VAR paintball_team[$i].ignore boolean_not_equals yes (
 [then]

    [sound]
	name="thunderstick.ogg"
    [/sound]
  {IF_VAR paintball_team[$i].score not_equals $final_score (
  [then]
    {VARIABLE paintball_team[$i].eliminate yes}
    [print]
	text="$paintball_team[$i].name is eliminated with $paintball_team[$i].score points at turn $turn_number!"
	size=24
	red,green,blue=$paintball_side[$i].recovery_label_color_r,$paintball_side[$i].recovery_label_color_g,$paintball_side[$i].recovery_label_color_b
    [/print]
  [/then]
  [else]
    {VARIABLE_OP winning_teams add 1}
    [print]
	text="$paintball_team[$i].name is victorious with $paintball_team[$i].score points at turn $turn_number!"
	r,g,b=$paintball_side[$i].recovery_label_color_r,$paintball_side[$i].recovery_label_color_g,$paintball_side[$i].recovery_label_color_b
    [/print]
  [/else] )}
    [delay]
	time=2000
    [/delay]

 [/then] )}
{NEXT i}

By the way, I thought that something like "linger_mode" was defaulted to yes (even if I use leader elimination rather than a [endlevel]), but it obviously isn't since paintball games, for some reason, aren't greyed out when completed: they just auto-quit. Did I miss something? [scenario] says nothing about this...

[Dixie]

Well, while the previous issue still stands (if any of you has any idea of what's up with it), there's another thing I'm currently working on atm and with which I'm having difficulty.

Basically, I'm trying to use some sort of substitution in macro symbols, so as to considerably shorten my code by removing a bunch of [if]s. I'm fairly certain it is possible, as it is a method I've seen used in Era of High Sorcery. Here's an example of what he does:

Code: Select all

#define realm_skill_EXTRA_OPTIONS_BY_TYPE PICK

# and then later he calls it like this:

{{{PICK}_PICK_TYPE}_EXTRA_OPTIONS_BY_TYPE {PICK}}

I've tried mostly the same thing, but I can't get it to work. I've tried both capital ad lowercase letters (in the #define part), at the beginning or at the end of the macro symbol, and nothing has worked so far. I have some clues about debugging, but I'm not sure what to do with them. For instance, one such macro is a text one supposed to appear in a [message]. Whereas other macros with no such substitution work fine, this one returns me "dummy=THE_MACRO'S_SYMBOL" if the substitution was at the end of the symbol, or just plainly "dummy=" if at the beginning.

So I wondered if this required some special care with Lua, or some consideration I might have omitted by accident? I've looked at the PreprocessorRef page of the wiki, but it as been unhelpful. Anyone has any ideas about this?

[Pentarctagon]

The code is not the problem, the [delay] tag just doesn't affect sounds.

[silene]

For instance, one such macro is a text one supposed to appear in a [message]. Whereas other macros with no such substitution work fine, this one returns me "dummy=THE_MACRO'S_SYMBOL" if the substitution was at the end of the symbol, or just plainly "dummy=" if at the beginning.

Open the console (or the stderr.txt file). There you will find proper error messages about what goes wrong with your code.

The code is not the problem, the [delay] tag just doesn't affect sounds.

Why shouldn't it? The [delay] tag is quite simple: it completely stops the engine for the desired amount of time. (If you are using colored cursors, they won't even move during the pause.) If a sound was already started, it won't be stopped. But if it wasn't, there is absolutely no reason for it to start before the end of the pause.

[Pentarctagon]

hm, must have gotten fixed since 1.7 then

[Dixie]

For instance, one such macro is a text one supposed to appear in a [message]. Whereas other macros with no such substitution work fine, this one returns me "dummy=THE_MACRO'S_SYMBOL" if the substitution was at the end of the symbol, or just plainly "dummy=" if at the beginning.

Open the console (or the stderr.txt file). There you will find proper error messages about what goes wrong with your code.

So you're telling me it -should- work without any additionnal care and is legal witin the syntax? Okay, I'll try to look into it and debug some more. Although I already used the console (I'm getting used to debugging my codes by now ) and it didn't say anything special, it mostly just didn't call the macro...

Anyway, thanks for your answers, I'll do some more research on it.

I haven't rally figured out the delay think yet either, btw, but I have a few ideas for workarounds, so maybe I'll manage Don't hesitate if you have suggestions, though.

[Dixie]

I fully retract the following statement:

Although I already used the console (I'm getting used to debugging my codes by now ) and it didn't say anything special, it mostly just didn't call the macro...

The terminal indeed gives me some error messages: it would appear that I have been a little adventurous in my usage of macros, as I was trying for variable substitution in the macro's symbol. I've learned some more stuff about how macros work, but it still doesn't solve my problem. For instance, I had {PAINTBALL_README_{GAMEMODE}}, where GAMEMODE as defined as $game_type where the macro was called. I thought that the variable would be substitued, but it wasn't! It would really shorten my code, as "game_type" can be assigned any one of five values at game start, and it'd be much shorter like that than having five "{IF_VAR game_type equals blah blah blah" calling five similarly named macro but still different in essence. I've tried using parenthesises and quotes, but so far my attempts at substituting the variable are unsuccessful. Do you think it is possible at all? Am I missing on something crucial?

[silene]

Am I missing on something crucial?

Yes, preprocessing and variable substitution are two completely separate process. Preprocessing happens only once, the first time the add-on is launched. Variable substitution happens much later, dynamically. So, in your case, you have written {PAINTBALL_README_$game_type}, but you have never written #define PAINTBALL_README_$game_type, so preprocessing fails.

[Dixie]

Hmm, yeah I guess I can understand that, as it's named PREprocessing... So that means there's absolutely no way for me to eventually hope to achieve this, huh? Too bad then, I'll just go back to the tons of {IF_VAR

[silene]

So that means there's absolutely no way for me to eventually hope to achieve this, huh?

At least not with macros. You should post what you are trying to achieve (or the original code you are trying to shorten), just in case it is possible to do in Lua. (It is possible in Lua anyway, the question is rather: is it worth it?)

[Dixie]

Hmm, I'm not sure it is worth it, overall. Unless you consider reducing the code for a total of about... 100-200 lines or so worth it. Not right now, anyway, since I'd have you do my dirty work. I've been thinking of trying to study and self-teach Lua lately, so I'll look into this. I was strugling with it because I started from the wesnoth wiki, which is probably pretty clear when you have a prior understanding of the language, but since I haven't got such a prior understanding, the wiki really overwhelmed me. I'm gonna look for some tutorials that start from the basics and stuff. Lua really seems like a powerful tool, one that could save me lots of trouble in the future.

Thanks anyway!

[Dixie]

Ok, so I had that really annoying problem about delays not working as they should in FOREACH macros, remember? How all the sounds would play at once, than all the delay would wait, and then all the prints would appear at the same time? Well, I thought I had a good idea for a work around, but of course it didn't work. This time, the sounds played one after the other correctly but the prints didn't appear. I'm beginning to suspect there's some kind of special rule with delays and prints!... Here's what I have (and yes, the variables are stored alright, I've verified):

Code: Select all

{IF_VAR end_message[1].ignore equals no (
[then]
      [sound]
	name="thunderstick.ogg"
      [/sound]
      [print]
	text="$end_message[1].text"
	size=24
	red,green,blue="$end_message[1].color"
      [/print]
      [delay]
	time=2000
      [/delay]
[/then] )}

I'm also struggling with terrains. While I was able to define my new village terrains and work just fine if applied with the editor, I had the idea of the century of creating One game mode to rule them all, One game mode to find them, in Paintball Era where WML lies, and this required that I be able to switch terrains around in game rather then having them pre-set in the editor. It's less trouble for people who'd like to design maps for PE, anyway, since that way they could just use the default villages and my code will switch them around as needed. So I store all villages locations (*^V*) in a container variable (which is stored ok, I've checked), and I iterate over it with a FOREACH, which contains about 30 variations on that code, and I cannot see what its flaws might be (but of course, since I'm talking about it here, he terrains are not changed):

Code: Select all

  [if]
    [have_location]
	find_in=villages[$i]
	terrain=Uu^Vu
    [/have_location]
  [then]
    [terrain]
	x,y=$villages[$i].x,$villages[$i].y
	terrains=Uu^Vuy
    [/terrain]
  [/then]

By the way, I'd like to say that there's some crazy stuff going on with location WML in the wiki. Not only are the codes not always working as the wiki says, but it doesn't work in the same fashion unit WML does, it's really confusing! For instance, [store_locations] does not need a [location_filter] and sometimes [location_filter]s need to be in a [filter] (when filtering terrains, for example). I think it should follow the same model [filter] and [store_unit] does, it would ake much more sense. Anyway...

Thanks for your advices and patience

[silene]

This time, the sounds played one after the other correctly but the prints didn't appear.

Have you tried putting a [redraw] between [print] and [delay]?

[Dixie]

I haven't replied right away, but I thought I ought you a quick follow-up at least: the redraw has fixed the problem. I haven't tried it in a FOREACH, mind you, but it works as it is so I'm probably gonna leave it be. I also managed to fix a bunch of other stuff I was struggling with, including the terrain thing (turns out that after like an hour of debugging, I found out it was a simple syntax error, I had written "terrains=" instead of "terrain=". Arg)

Anyway, thanks again for all your help!