Quite recently I renamed some script functions and added a wrapper function for backwards compatibilty. Are there any other functions that we do want to have renamed? I can think of the following:
- GBack_* functions, as there was some confusion about what they should and should not do. Suggesstions for a new name? Mine are: IsBackgroundMaterial*, where * = Solid, SemiSolid, Sky (or could we just create a new function "GetBackgroundMaterial" that reads the background just like GetMaterial does with the foreground?
- *Plr* functions. I'd spell out the "Player" part.
- GBack_* functions, as there was some confusion about what they should and should not do. Suggesstions for a new name? Mine are: IsBackgroundMaterial*, where * = Solid, SemiSolid, Sky (or could we just create a new function "GetBackgroundMaterial" that reads the background just like GetMaterial does with the foreground?
- *Plr* functions. I'd spell out the "Player" part.
The issue with the GBack* functions is that some of them (for example GBackSky) check the background material, while others (e.g., GBackSolid and GBackSemiSolid) check the foreground material.>or could we just create a new function "GetBackgroundMaterial" that reads the background just like GetMaterial does with the foreground
This function already exists.
![[de]](/mwf/flags/de.png "Germany")
I would not rename the constants though, just the function names.
Maybe rather than renaming the functions in arbitrary ways, we should design new interfaces around proplists. So for example, instead of GetPlayerTeam() you'd call player->GetTeam().
How are these player proplists created?player0->
player1->
...?
Or
Clonkonaut->
Luchs->
...?
I will immediately create a player named 'Global'.
Don't worry, it'll be
[Edit:] Hm, either that, or let Players be a proplist with unique/non-recurring string keys for each player.
Have we already gotten rid of that
Players[0]->[Edit:] Hm, either that, or let Players be a proplist with unique/non-recurring string keys for each player.
Have we already gotten rid of that
GetPlayerByIndex/GetPlayerByID mess? The option with the proplist would get rid of both…
> Have we already gotten rid of that GetPlayerByIndex
We have not. And it's probably a mess because you need to change a lot of owner stuff when a player is eliminated and another takes the player number.
Do we need global handles to the players like that? My thought was to keep the previous GetPlayerByName/Index functions and make them return proplists instead of integers.
What do with stuff like: Find_Hostile, DoWealth, GetKiller, InitializePlayer?
Find_Hostile, GetKiller: Leave as-is, they would just take a "proplist player" instead of "int player".DoWealth (also Set and Get): Change to player->DoWealth(int amount)
InitializePlayer: Change to InitializePlayer(proplist player, ..., proplist team) (we'd probably also want to use proplists for teams).
![[us]](/mwf/flags/us.png "United States")
That sounds nice, but then we never know whether a player parameter expects the player number of the player proplist.
You can't really do any sensible arithmetic with player numbers, can you? So if we just replace all "int player" parameters in functions the engine calls with a proplist and have the legacy functions take proplists as well, no code should break that wasn't invalid anyways. The issue with this approach is that it fails engine type checks, so we'd need a way around that (user-defined implicit conversions?).
Yeah, that's an issue. At least it's not very widely used. I'd redesign VIS_Select to take a proplist mapping a unique identifier to a bool.
Players would still need a player number. Otherwise, you couldn't have arrays with player data anymore. So it could stay the same, you would just use player->GetID() or something as the integer.
Would you need arrays then?
for (var player in team->GetPlayers())
{
player->DoScore(1);
}
for (var player in Scenario->GetPlayers())
{
if (player.some_property == some_value)
{
--player.another_property;
}
}
You don't need arrays. But existing scripts use arrays, and you don't want to break everything.
Indexing arrays by player number is common, e.g. to store relaunches. Of course after changing them to proplists, one would rather want to write player.relaunch_count.One solution would be to build a conversion from the player proplist to int, which returns the number. E.g. like in python, proplists could check for an __int__ function when used as an integer and converted as needed. It would still be a mess because you could never really be sure whether your player got converted to int somewhere.
![[at]](/mwf/flags/at.png "Austria")
As older scenarios probably have a lower version number, OC could switch between player proplists and player numbers on the fly. But yeah, there isn't really an unmessy solution (I like the __int__ one though).
By the way, as this sounds like a huge change in everything. What exactly would be the gain here?
I agree with this remark. This is massive in terms of the amoun of scripts that need to be changed.
The gain would be an easier to use interface for players and teams. Of course, I'd only do this if we can (mostly) keep backwards compatibility.I'm against just slightly changing some function names here as that would similarly require tons of changes with very little gain. The whole interface isn't great, and inconsistent naming is the least problem.
Most cases (those that use variables as "player" parameter) will be regex-able just fine with my proposal as well, with an expression like this (vim): :s/\vGetPlrExtraData\(\s*(\w+)\s*,\s*/\1->GetExtraData(/ that replaces calls like GetPlrExtraData(plr, GetScoreString()); to plr->GetExtraData(GetScoreString());
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
