Wesnoth for Löve

Discussion of all aspects of the game engine, including development of new and existing features.

Moderator: Forum Moderators

fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

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.
True, although the differences between both versions are marginal regarding the typical usecase.
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
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

gfgtdf wrote: September 14th, 2020, 8:53 pm
fabi wrote: September 14th, 2020, 8:26 pm
I need to trust that Löve secures the lua code execution well enough.
I would not assume that this is the case in particular since i have seen no place so far where they claim that they do this. running 'untrusted' code is still a somewhat rare requirement for games
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.
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.
This sounds like a discussion that needs to be made with Löve's c++ developers.
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
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

gnombat 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
I've added it to the issue tracker, thank you
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
gfgtdf
General Code Maintainer
Posts: 1343
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth for Löve

Post by gfgtdf »

I took a short look at your code and i was wondering how moonscript works exactly. I oftem see codes like

Code: Select all


    side: {
        side: 1
...
    }
    side: {
        side: 2
...
    }
does this mean that "side" is automaticially a (lua) array of sides if you use the 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.
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

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 like

Code: Select all


    side: {
        side: 1
...
    }
    side: {
        side: 2
...
    }
does this mean that "side" is automaticially a (lua) array of sides if you use the 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.
Yeah, you spotet the "slightly modified", repeated table entries are put into a list thus the following code snippets are equivalent:

Code: Select all

side: {
    id: 'whatever'
}
side: {
    id: 'someOther'
}
and

Code: Select all

side: {
    { id: 'whatever }
    { id: 'someOther' }
}
Lua's and vanilla Moonscript's behavior is that the later just replaces the former value.
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
gfgtdf
General Code Maintainer
Posts: 1343
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth for Löve

Post by gfgtdf »

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.
gfgtdf
General Code Maintainer
Posts: 1343
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth for Löve

Post by gfgtdf »

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.
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

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.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

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.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
gfgtdf
General Code Maintainer
Posts: 1343
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth for Löve

Post by gfgtdf »

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.
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.
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

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.
Indeed, I do not want to support that.
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
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

gfgtdf wrote: September 16th, 2020, 6:16 pm 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.
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
User avatar
Pentarctagon
Project Manager
Posts: 4537
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Wesnoth for Löve

Post by Pentarctagon »

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
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

noted
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Wesnoth for Löve

Post by fabi »

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.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
Post Reply