Wesnoth for Löve
Moderator: Forum Moderators
Re: Wesnoth for Löve
True, although the differences between both versions are marginal regarding the typical usecase.Pentarctagon wrote: ↑September 14th, 2020, 9:01 pm I agree that it'd be best to not modify love2d. Another issue with luajit though is it supports an older version of lua than Wesnoth currently does, so that would be another point of potential incompatibility for current add-ons/mainline.
The biggest difference is with the handling of the environments (same topic as in my earlier post) and I guess the typical add-on is not using such a sophisticated feature.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
Yes, I don't assume that I am save just because the backend code is not under my control.
But I can't do anything about it without modifying Löve itself.
So every attempt in making the addon execution save must be done on the lua level.
This sounds like a discussion that needs to be made with Löve's c++ developers.EDIT: furthermore if you want to implement server in a server-client model where the actual code is run on the server (unliek currentl wesnoth where umc code is only executed on the client), you need some operating system specific code to limits a games resourses usage. Once you have that, implementing full os-level sandbooxing via functions like seccomp-bpf (on Linux, din't look up the equivalents on other OS) might be a rather small step.
I will start a discussion on their forums and drop a link to it here.
edit: https://love2d.org/forums/viewtopic.php?f=4&t=89456
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
I've added it to the issue tracker, thank yougnombat wrote: ↑September 14th, 2020, 10:46 am There is an interesting discussion about the advantages and disadvantages of each layout here:
https://gamedev.stackexchange.com/quest ... s-and-cons
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
I took a short look at your code and i was wondering how moonscript works exactly. I oftem see codes like
does this mean that "side" is automaticially a (lua) array of sides if you use the
Code: Select all
side: {
side: 1
...
}
side: {
side: 2
...
}
side : { key }
syntax and how is it different form the usual attribute syntax? is then somethign like name : "name "
than also automatically a 1-element table that contaisn just name = { "name" }
(lua notation)? I couldnt find anything about 'defining an attriute twice' in the moonscript documentation.Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
Re: Wesnoth for Löve
Yeah, you spotet the "slightly modified", repeated table entries are put into a list thus the following code snippets are equivalent:gfgtdf wrote: ↑September 16th, 2020, 12:53 pm I took a short look at your code and i was wondering how moonscript works exactly. I oftem see codes likedoes this mean that "side" is automaticially a (lua) array of sides if you use theCode: Select all
side: { side: 1 ... } side: { side: 2 ... }
side : { key }
syntax and how is it different form the usual attribute syntax? is then somethign likename : "name "
than also automatically a 1-element table that contaisn justname = { "name" }
(lua notation)? I couldnt find anything about 'defining an attriute twice' in the moonscript documentation.
Code: Select all
side: {
id: 'whatever'
}
side: {
id: 'someOther'
}
Code: Select all
side: {
{ id: 'whatever }
{ id: 'someOther' }
}
I don't use that feature in the codebase, its a data (wsl) only thing for now.
edit : non repeated values are not lists with single elements but just values.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
I'm not really a fan of this idea, tbh since there are quite a few wml keys that can be present once or or multiple times, and then you have to wrote your lua/moonscript code in a way that can handle both.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
Re: Wesnoth for Löve
I'm wondering to you think you will eventuall need to run umc code on the client aswell? I mean wesnoth currently has certain functions like wensoth.show_dialog and the theme ui callbacks that in their current implementation require instant reaction from the code. Implementing these without running umc code on the server might be tricky task.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
Re: Wesnoth for Löve
The select event is also annoying, forcing client/server communication quite often.
I will certainly not implement gui2 stuff.
Luigi is a pure lua gui lib, more or less dead since 2018, but it is working fine enough for my needs so far.
It is very lightwight, and compared to the gui2 wml, its layout definitions are more easy to use.
Of course that might be a matter of taste.
It is just my personal experience, It took me about a week to implement all current W4L dialogs.
In the same time I finished half a gui2 wml layout back in my c++ days.
Maybe it is easier to use nowadays.
Since it does not only work with the Löve backend, but also on top of libSDL it might even find its way back to attic Wesnoth, replacing the gui1 game screen? That way the old engine could benefit from W4L a bit and bridge the time until a replacement is ready.
I really like the Godot engine, have worked with it before and each hex field being an world object is interesting.
Maybe edit: GodotHaldric can also work as a client for the W4L server in the future?
Just some thoughts.
So I like to expose luigi to the content creator, maybe with a transcompiler from gui2 to its layout format, but that has low priority.
It will work without client side scripting. Tables are sent from server to client, defining the dialogs. The client will inform what action the user took, but that won't support or require any user made code on the client side.
I will certainly not implement gui2 stuff.
Luigi is a pure lua gui lib, more or less dead since 2018, but it is working fine enough for my needs so far.
It is very lightwight, and compared to the gui2 wml, its layout definitions are more easy to use.
Of course that might be a matter of taste.
It is just my personal experience, It took me about a week to implement all current W4L dialogs.
In the same time I finished half a gui2 wml layout back in my c++ days.
Maybe it is easier to use nowadays.
Since it does not only work with the Löve backend, but also on top of libSDL it might even find its way back to attic Wesnoth, replacing the gui1 game screen? That way the old engine could benefit from W4L a bit and bridge the time until a replacement is ready.
I really like the Godot engine, have worked with it before and each hex field being an world object is interesting.
Maybe edit: GodotHaldric can also work as a client for the W4L server in the future?
Just some thoughts.
So I like to expose luigi to the content creator, maybe with a transcompiler from gui2 to its layout format, but that has low priority.
It will work without client side scripting. Tables are sent from server to client, defining the dialogs. The client will inform what action the user took, but that won't support or require any user made code on the client side.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
Let's call the old engine Attic for now in this thread.
I don't want to be disrespectful towards the old lady, it just annoys me to write old wesnoth or c++ wesnoth all the time.
Another thought regarding the server.
I thought about a matchmaking multiplayer lobby/server similar to Attics.
The game server (the one computing the game and most likely the ai players) should then be run by the matchmaking host, not the centralized server.
I did not thought about resource management yet, just that the Wesnoth project (or any other project using the engine) should not have extra hardware needs compared to Attic.
Of course that is giving all control to the matchmaker, allowing for cheating.
Ladder games might not be played that way, depending on a 'trusted' server.
Or some other kind of anti cheat protection, maybe checksum based.
I am not an expert on that field, any input is appreciated.
edit: the matchmaking server could deliver the random numbers, I guess that is a good idea anyway.
I don't want to be disrespectful towards the old lady, it just annoys me to write old wesnoth or c++ wesnoth all the time.
Another thought regarding the server.
I thought about a matchmaking multiplayer lobby/server similar to Attics.
The game server (the one computing the game and most likely the ai players) should then be run by the matchmaking host, not the centralized server.
I did not thought about resource management yet, just that the Wesnoth project (or any other project using the engine) should not have extra hardware needs compared to Attic.
Of course that is giving all control to the matchmaker, allowing for cheating.
Ladder games might not be played that way, depending on a 'trusted' server.
Or some other kind of anti cheat protection, maybe checksum based.
I am not an expert on that field, any input is appreciated.
edit: the matchmaking server could deliver the random numbers, I guess that is a good idea anyway.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
I think you misunderstood me, i wasn't expecting you to support the gui2 syntax in your new engine.
My point was that wesnoth currently at some places allows direct callbacks of certain types of ui events ( in particular the 'mouse move' type of event) where a possible delay ( caused by networking) is really undesirable.
My point was that wesnoth currently at some places allows direct callbacks of certain types of ui events ( in particular the 'mouse move' type of event) where a possible delay ( caused by networking) is really undesirable.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
Re: Wesnoth for Löve
Indeed, I do not want to support that.gfgtdf wrote: ↑September 16th, 2020, 10:41 pm I think you misunderstood me, i wasn't expecting you to support the gui2 syntax in your new engine.
My point was that wesnoth currently at some places allows direct callbacks of certain types of ui events ( in particular the 'mouse move' type of event) where a possible delay ( caused by networking) is really undesirable.
Also I think it is not really needed.
Maybe such a thing should have never made it into the api, I remember shadowm complaining against it (edit it == the way gui2 is exposed to the content creator), having some similar thoughts?
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
The WSL code is planned to go through a syntax checker, it also handles the list vs single value properly.
The table that defines the syntax is also used to generate the api documentation.
So far the modification did the trick well, I am happy with it, but open to suggestions.
Not having to modify Moonscript is the preferred way, for sure.
Although, this single change to the language allows for line by line translation of WML into WSL, even keeping the comments on the right place.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
- Pentarctagon
- Project Manager
- Posts: 5581
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Wesnoth for Löve
Also, currently the forum database is used by wesnothd mainly to enforce the forum registration requirement for 1.14 as well as to make some of the information collected in the MP Activity Reports more reliable. So support for connecting to a mariadb database is something else to keep in mind for an MP server implementation.
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: Wesnoth for Löve
noted
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Re: Wesnoth for Löve
Added a section to the first post about features in Attic I don't like to port to W4L.
I guess this leads to intensive discussions.
I guess this leads to intensive discussions.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus