Dugi's lua questions

[8680]

Should look like this:

Code: Select all

-- If the variables are WML variables, load them into Lua.
local path, r, g, b = wesnoth.get_variable "path", wesnoth.get_variable "r", ...
-- wesnoth.fire is deprecated, call the tag directly.
wesnoth.wml_actions.item {
    -- Commas and semicolons are interchangeable as table element separators.
    x = ?, y = ?; -- Or any SLF.
    image = ("%s~CS(%d,%d,%d)"): format(path, r, g, b);
    halo = ...;
}

[Dugi]

The path to that image was a lua variable. I have used almost the same code to do it, though with wesnoth.fire, but that should not be the problem. I will post the code when I will be able to.

[Anonymissimus]

wesnoth.fire

As a side note, you should normally better call wml tags using wesnoth.wml_actions.tag(...) instead of using wesnoth.fire("tag", ...). In the case of tag being a lua tag, this spares the cost of converting to a vonfig object and back. However, if you have variables to substitute in the wml table you pass, you need to use wesnoth.fire or wesnoth.tovconfig (you can see wesnoth.fire's code in data/lua/backwards-compatibility.lua).

[Dugi]

Thanks for that tip with wml_actions.

I have figured out the problem with the missing item image, I defined it as a local variable within an if, it was created correctly, but it was cleared before it came to the place where it was used. It works now.
I knew that local variables were cleared if used within a function, but not that they were cleared also if used within an if.

Thanks for trying to help.

[Elvish_Hunter]

I knew that local variables were cleared if used within a function, but not that they were cleared also if used within an if.

Yes, they exist only inside their own function or cycle. This means that also for .. do, while .. do and repeat .. until cycles clear local variables.

[Dugi]

Sorry for necroing, but I did not want to create new threads for the same things. This topic is like a folder for questions anyway.

So...
I was trying many things with lua, learned a lot, wrote more than 100 kilobytes of lua code, and I think the time has come to ask some more questions.

1. What exactly does wesnoth.synchronize_choice? Will it prevent OoS errors even if I pack into it a function that changes the game (with some heavy changes on a unit and placing it with wesnoth.put_unit) and is based on users' choices in listboxes in GUIs, that change global variables (or just variables outside that function), related with wml's global variables?
It is not quite easy to test it without needing other people's help (as all people in the project are on MP rarely).

2. What's the matter with GUIs? They are somewhat bugged, if I try to put plain text in blocks in a listbox, it crashes with possibly wrong wml... blablabla... image don't fit on cavas, if number them 31, 32, 33 instead of 1,2,3, it does not instantly crash, but when I select on of them (even without a callback function), it crashes anyway with the same message. Only inserting a picture with large dimensions (72x72 worked, 16x16 did not) into these blocks fixed it. Unfortunately, I don't have a code to show you to let you replicate it, I'll post it when I'll have, but maybe even the one in examples stopped working if I removed the picture (replacing it with misc/blank-hex.png worked, but it looks awful).
Is there somebody accessible who knows well how to manipulate with these GUIs? Or are these GUIs from another open source project?

[Anonymissimus]

1. What exactly does wesnoth.synchronize_choice?

It causes the function passed to it to be executed only on the currently active client. If this function returns a *wml* table, that table is returned at the spot where synch_choice was called and, in the same process, sent to all the other clients as well. Thus, you can have some action within that function which would normally cause OOS, such as a player choosing an option.

[Dugi]

Does that mean that it will not prevent OoS if the function inside it is doing some changes in the game that are not returned by the function?

[Anonymissimus]

Does that mean that it will not prevent OoS if the function inside it is doing some changes in the game that are not returned by the function?

It does only what I wrote above. It does not attempt to magically prevent OOS or something. You need to understand what OOS is and how to use this function to manually resolve problems which would otherwise cause OOS.
You could even use synch_choice to specifically cause OOS, should you want to do that. You could let the function passed to synch_choice set a variable for instance (changes to the game, alter the gamestate). Since this happens only on the currently active client, this would then be OOS.
So, normally, you should not do "changes to the game" inside the function passed to synch_choice. Instead, you gather what you need, let the function return it in the form of a wml table, and then change the gamestate in the code from where the function was called.
You should check this out yourself with trial & error. You can test networked multiplayer yourself by opening 2 or more clients and connecting to the official server or a local wesnothd (I was assuming you knew that, but something you said above suggests otherwise.).

[Dugi]

Seems I will have to experiment with it. I will post something if I come into problems.
I thought somehow that wesnoth server does not allow to join two clients with the same IP to prevent abuse. And for some reasons I haven't remembered that I can run the server myself.

[Crendgrim]

Off-topic:

Sorry for necroing, but I did not want to create new threads for the same things. This topic is like a folder for questions anyway.

For your own working threads, this is exactly the desired behavior.