Irdya - Wesmere Reference Implementation
Moderator: Forum Moderators
Re: Irdya - Wesmere Reference Implementation
The current codebase comes with new READMEs in some folders to help people making use of it.
New features and content:
Unit Test Scenario Suite
Autogenerated API Reference (only for the core, WSLAction Reference comes soon)
Ported a whole campaign: AOI
Refactored the codebase into a Wesmere Package.(Not quite finished yet.)
Added most of Wesnoth's Units (plus some more) and all Terrains.
New features and content:
Unit Test Scenario Suite
Autogenerated API Reference (only for the core, WSLAction Reference comes soon)
Ported a whole campaign: AOI
Refactored the codebase into a Wesmere Package.(Not quite finished yet.)
Added most of Wesnoth's Units (plus some more) and all Terrains.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
- Pentarctagon
- Project Manager
- Posts: 5567
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Irdya - Wesmere Reference Implementation
So if I'm reading this correctly, there's the Wesmere server (Irdya) > the user/client > the display/UI. Currently Irdya is under heavy development but mostly finished, while the client and the UI are not yet started (beyond neat the ascii art)?
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
Re: Irdya - Wesmere Reference Implementation
Yes, you read that correctly.
I wouldn't call Irdya to be mostly finished yet.
Although, it already passes some of Wesnoth's unit test scenarios.
Alone the framework to start a unit test scenario is already a big bunch of the work.
Let's say it is half done.
Big tasks on the ToDo are:
* Implementing the gameplay.
- healing
- income
- combat system
- effect system
- movement
* A script that transforms WML into WSL
* API reference generation (mostly ActionWSL is still missing)
* Some ActionWSL functions are not implemented yet.
* Implement all the client interaction.
A big part of that work is done using the ActionWSL api, which is very similar to Wesnoth's ActionWML one.
So I hope some WML developers want to join the project.
Another big part of the work is done by using the Wesmere api, which is very similar to Wesnoth's lua api. Another part of the project allowing Wesnoth community members to assist without the need to learn a new api.
Regarding client/display/UI iceiceice's experiments seem to be the only attempt in progress.
Anyway, if all attempts fail there is still the option to transform the old Wesnoth codebase into a Wesmere client.
I wouldn't call Irdya to be mostly finished yet.
Although, it already passes some of Wesnoth's unit test scenarios.
Alone the framework to start a unit test scenario is already a big bunch of the work.
Let's say it is half done.
Big tasks on the ToDo are:
* Implementing the gameplay.
- healing
- income
- combat system
- effect system
- movement
* A script that transforms WML into WSL
* API reference generation (mostly ActionWSL is still missing)
* Some ActionWSL functions are not implemented yet.
* Implement all the client interaction.
A big part of that work is done using the ActionWSL api, which is very similar to Wesnoth's ActionWML one.
So I hope some WML developers want to join the project.
Another big part of the work is done by using the Wesmere api, which is very similar to Wesnoth's lua api. Another part of the project allowing Wesnoth community members to assist without the need to learn a new api.
Regarding client/display/UI iceiceice's experiments seem to be the only attempt in progress.
Anyway, if all attempts fail there is still the option to transform the old Wesnoth codebase into a Wesmere client.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
- Pentarctagon
- Project Manager
- Posts: 5567
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Irdya - Wesmere Reference Implementation
If it's WSL, why would WML coders in particular be needed?fabi wrote:A big part of that work is done using the ActionWSL api, which is very similar to Wesnoth's ActionWML one.
So I hope some WML developers want to join the project.
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
Re: Irdya - Wesmere Reference Implementation
I meant that WSL and WML or better ActionWSL and ActionWML are so similar to each other that every UMC Designer should be able to contribute.Pentarctagon wrote:If it's WSL, why would WML coders in particular be needed?fabi wrote:A big part of that work is done using the ActionWSL api, which is very similar to Wesnoth's ActionWML one.
So I hope some WML developers want to join the project.
Especially when it comes to coding the game mechanics.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
"The thing a project in the true spirit of open source has to fear is not forking, but clean-room re-implementation. When that happens, you know something is wrong."
"The thing a project in the true spirit of open source has to fear is not forking, but clean-room re-implementation. When that happens, you know something is wrong."
Re: Irdya - Wesmere Reference Implementation
All tests:
110 successes / 32 failures / 12 errors / 0 pending : 17.678611 seconds
Wesmere api related ones:
77 successes / 0 failures / 2 errors / 0 pending : 1.611187 seconds
Unit test scenario suite:
33 successes / 32 failures / 10 errors / 0 pending : 13.657035 seconds
Implemented GameMap Class which works pretty similar to Wesnoth's counterpart.
This also enables proper unit creation at scenario setup and during scenario execution.
The Location Class got an overhaul.
It now throws errors only when coordinate related keys (x,y,loc) were supplied to make its usage easier.
Earlier one needed to surround it with heavy error handling all the time.
Introduced a 'loc' key that allows to supply coordinates in a single step.
can be used like:
Still thinking about the support of ranges and location sets.
Errors now produce a trace-back for better debugging.
And the try/catch/finally function has been enhanced to produce prettier code.
Unit filtering is working to a certain degree now.
I have started to think how the support for effects should work.
Planned is to code most stuff with the help of that system, for example are alignments in Wesnoth hard-coded in c++.
A unit test checks if placing units with off-map coordinates results in them ending on a recall list.
I am not sure if that is a good idea.
UMC designers can deliberately put them on the recall list with x,y=recall,recall (or loc: "recall" in wesmere), delivering offmap coordinates should better error and fail in my opinion.
What do you think?
While implementing the new "UnitPlace" (Wesnoth: unit_placed) event I considered to also introduce a "UnitRemoved" or "UnitExtracted" one.
Any thoughts?
110 successes / 32 failures / 12 errors / 0 pending : 17.678611 seconds
Wesmere api related ones:
77 successes / 0 failures / 2 errors / 0 pending : 1.611187 seconds
Unit test scenario suite:
33 successes / 32 failures / 10 errors / 0 pending : 13.657035 seconds
Implemented GameMap Class which works pretty similar to Wesnoth's counterpart.
This also enables proper unit creation at scenario setup and during scenario execution.
The Location Class got an overhaul.
It now throws errors only when coordinate related keys (x,y,loc) were supplied to make its usage easier.
Earlier one needed to surround it with heavy error handling all the time.
Introduced a 'loc' key that allows to supply coordinates in a single step.
can be used like:
Code: Select all
unit:
loc: {3,4}
loc: {x:3, y:4}
loc: {y:4, x:3}
Errors now produce a trace-back for better debugging.
And the try/catch/finally function has been enhanced to produce prettier code.
Unit filtering is working to a certain degree now.
I have started to think how the support for effects should work.
Planned is to code most stuff with the help of that system, for example are alignments in Wesnoth hard-coded in c++.
A unit test checks if placing units with off-map coordinates results in them ending on a recall list.
I am not sure if that is a good idea.
UMC designers can deliberately put them on the recall list with x,y=recall,recall (or loc: "recall" in wesmere), delivering offmap coordinates should better error and fail in my opinion.
What do you think?
While implementing the new "UnitPlace" (Wesnoth: unit_placed) event I considered to also introduce a "UnitRemoved" or "UnitExtracted" one.
Any thoughts?
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
- Pentarctagon
- Project Manager
- Posts: 5567
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Irdya - Wesmere Reference Implementation
I think placing a unit off the map should result in some sort of warning. There is another, much clearer, way to put units on the recall list, and in cases where the coordinate to place a unit is calculated it could result in unexpected behavior. For example, somebody posting to a feedback thread saying that a unit didn't appear, and the author/maintainer would have to look for the unit in the recall list rather than an error in the log file.
As for UnitRemoved/UnitExtracted, would there be any case where this would required rather than a die/exit_hex event?
As for UnitRemoved/UnitExtracted, would there be any case where this would required rather than a die/exit_hex event?
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
Re: Irdya - Wesmere Reference Implementation
Exactly my thoughts.Pentarctagon wrote:I think placing a unit off the map should result in some sort of warning. There is another, much clearer, way to put units on the recall list, and in cases where the coordinate to place a unit is calculated it could result in unexpected behavior. For example, somebody posting to a feedback thread saying that a unit didn't appear, and the author/maintainer would have to look for the unit in the recall list rather than an error in the log file.
So the 'unit' WSLAction will differ from WML's counterpart.
The obvious answer is that you can extract a unit from the map without causing the die event to be triggered.As for UnitRemoved/UnitExtracted, would there be any case where this would required rather than a die/exit_hex event?
Currently a UMC coder needs to workaround that.
Strictly required? Most likely not.
Good to have? I think so.
Wesnoth's development team asks "is it required?" a lot.
For me this consideration is not that important.
My goal is more to make the WSL coder happy.
Wesmere drops enough complexity (by not supporting "undo/redo" for example) to make room for some fresh air.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Irdya - Wesmere Reference Implementation
Delayed variable substitution is on my mind since the beginning of the project.
I would like to drop the concept completely and just rely on Lua language features.
Meaning that WML variables just turn into "normal" Lua ones.
On the other hand might the WML way of doing things be easier to understand to the none coder.
This is not easy for me to judge.
And complexity issues regarding the WML2WSL script.
Another issue that I am believing to have solved properly already are unit filtering with variable usage:
Lua allows a provided object to be of any type.
So the code that evaluates the SUF assumes the filter to use the WML like syntax we are used to in the case the object is a table.
In case it is a function it's called with the unit as first argument.
Its return is evaluated in a boolean context and expected to specify iff the unit passed the filter.
This allows complete freedom when it comes to unit filter coding but also enables the usage of the SUF syntax with the current unit being filtered on in scope.
The following example makes use of the fact that "have_unit" is already doing what we need, it takes a SUF as argument and returns a bool:
I would like to drop the concept completely and just rely on Lua language features.
Meaning that WML variables just turn into "normal" Lua ones.
On the other hand might the WML way of doing things be easier to understand to the none coder.
This is not easy for me to judge.
And complexity issues regarding the WML2WSL script.
Another issue that I am believing to have solved properly already are unit filtering with variable usage:
Lua allows a provided object to be of any type.
So the code that evaluates the SUF assumes the filter to use the WML like syntax we are used to in the case the object is a table.
In case it is a function it's called with the unit as first argument.
Its return is evaluated in a boolean context and expected to specify iff the unit passed the filter.
This allows complete freedom when it comes to unit filter coding but also enables the usage of the SUF syntax with the current unit being filtered on in scope.
The following example makes use of the fact that "have_unit" is already doing what we need, it takes a SUF as argument and returns a bool:
Code: Select all
[filter]
side=1
[filter_wml]
hitpoints=$this_unit.max_hitpoints
[/filter_wml]
[/filter]
Code: Select all
filter: (this_unit) -> have_unit
side: 1
filter_wsl:
hitpoints: this_unit.max_hitpoints
Code: Select all
filter: (this_unit) ->
return false unless this_unit.side == 1
return false unless this_unit.hitpoints == this_unit.max_hitpoints
return true
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
- Pentarctagon
- Project Manager
- Posts: 5567
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Irdya - Wesmere Reference Implementation
For the delayed variable substitution, having it enabled is the default for nested events, so if nested events are used then it is likely that there would be problems changing that over to WSL. I would imagine that not having delayed variable substitution would require a logic rewrite more than a syntax change to get it to work as expected in WSL.
That said, I've rarely ever used this feature partly because I didn't like variables having two different behaviors and partly because I almost never needed it anyways. I do remember needing it to get the value for the Regeneration ability correct for the Colosseum add-on though.
edit: yup
though admittedly the syntax is different from the wiki example ($<var>|| rather than $||<var>), so maybe it was never doing what I thought it was doing in the first place.
edit2: actually I'm a bit worried now, after seeing that. I've been using the | character as a way to separate variables followed directly by a period in a string, such as:
Which works, though now I'm not quite sure what it's actually doing
That said, I've rarely ever used this feature partly because I didn't like variables having two different behaviors and partly because I almost never needed it anyways. I do remember needing it to get the value for the Regeneration ability correct for the Colosseum add-on though.
edit: yup
Code: Select all
[regenerate]
value=$custom_regen$side_number||
id=regenerates
name= _ "regenerates +$custom_regen$side_number||"
description= _ "The unit will heal itself $custom_regen$side_number|| HP per turn. If it is poisoned, it will remove the poison instead of healing."
affect_self=yes
poison=cured
[/regenerate]
edit2: actually I'm a bit worried now, after seeing that. I've been using the | character as a way to separate variables followed directly by a period in a string, such as:
Code: Select all
"$MusicTemp.entered_text|.ogg"
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
Re: Irdya - Wesmere Reference Implementation
Nested event(-handlers) are defined by calls to the event() (the former [event] tag) function.
In the argument table of event() the 'command' function is only defined but not called at the host event(-handler)'s execution.
Later, during the execution of the nested event(-handler)'s function the environment already holds the updated values for the nested event(-handler)'s context.
And at that time the Lua interpreter also does the variable lookup.
So primary/secondary units, turn_number, side_number, etc are those of the nested event.
What I want to explain, delayed variable substitution is already Lua's default.
This means that the following code calls the (unit at 8/3)'s location and the assert holds:
Let's have a look at another example:
So whenever you need undelayed variable substitution just make a local copy.
Another, but related issue:
Global variables.
The created_at variable from the example above is local.
(MoonScript is different to Lua in that case.)
The only reason why the command function of the nested event is able to read from it, is the shared scope at the definition time of the command.
The next example will show us when we need a global variable:
In the argument table of event() the 'command' function is only defined but not called at the host event(-handler)'s execution.
Later, during the execution of the nested event(-handler)'s function the environment already holds the updated values for the nested event(-handler)'s context.
And at that time the Lua interpreter also does the variable lookup.
So primary/secondary units, turn_number, side_number, etc are those of the nested event.
What I want to explain, delayed variable substitution is already Lua's default.
This means that the following code calls the (unit at 8/3)'s location and the assert holds:
Code: Select all
MoveTo: ->
filter:
x:5
y:5
command: ->
event
name: "MoveTo"
filter:
x:8
y:3
command: ->
assert(Unit.x == 8)
assert(Unit.y == 3)
Code: Select all
Turn3: ->
created_at = turn_number
event
name: "Turn5"
command: ->
assert(turn_number == 5)
assert(created_at == 3)
Another, but related issue:
Global variables.
The created_at variable from the example above is local.
(MoonScript is different to Lua in that case.)
The only reason why the command function of the nested event is able to read from it, is the shared scope at the definition time of the command.
The next example will show us when we need a global variable:
Code: Select all
Start: ->
foo = "Hi"
variable_name = "foobar"
export bar = "hello"
VARIABLE variable_name, foo -- this syntax can be used for dynamic variable names,
-- it is just the {VARIABLE ...} macro from data/core/macros/
-- and thus syntactic sugar around set_variable()
Turn1: ->
assert(foo == nil)
assert(bar == "hello")
assert(foobar == "Hi")
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
- Pentarctagon
- Project Manager
- Posts: 5567
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Irdya - Wesmere Reference Implementation
Are global variables truly global? Or are they "global" only to the add-on that created them?
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
Re: Irdya - Wesmere Reference Implementation
They are globals in the event context environment of the running campaign.Pentarctagon wrote:Are global variables truly global? Or are they "global" only to the add-on that created them?
(Assuming that a single scenario is also a campaign.)
So if your event coding is from several different add-ons you have variables from different add-ons populating the event context.
Your question sounds like the add-ons create variables at the time the engine reads them from disc.
But the WSLVariables we talk about are created at the moment the event who declares them is executed.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
- Pentarctagon
- Project Manager
- Posts: 5567
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Irdya - Wesmere Reference Implementation
I was thinking about it more from an add-on conflict perspective, in terms of variable names. Wesnoth currently allows add-ons are arbitrarily read each others variables since, to Wesnoth, it's all just a bunch of WML. I've resolved this in my own add-on by prefixing "namespaces" onto my variables, so MusicPersist.var, MusicTemp.var, etc, but it would be nice to not have to worry about weird behavior from inter-add-on conflicts like that.
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
Re: Irdya - Wesmere Reference Implementation
But what happens if an add-on is depending and extending on a parent one?
Those are most likely to want reading/writing the parent's variables.
Those are most likely to want reading/writing the parent's variables.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus