Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Renamed functions
- - By Marky Date 2018-04-05 19:35
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.
Parent - - By Luchs Date 2018-04-05 19:54
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.
Parent - By Marky [de] Date 2018-04-05 20:44
Oh, good to know. Yes, the docu for each of the GBack functions just says "at this position in the landscape".
Parent - - By Maikel Date 2018-04-05 21:12
Then also close this bug
Parent - By Marky Date 2018-04-05 21:30
I would not rename the constants though, just the function names.
Parent - - By Luchs Date 2018-04-05 22:04
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().
Parent - - By Clonkonaut Date 2018-04-05 23:37
How are these player proplists created?
player0->
player1->
...?

Or
Clonkonaut->
Luchs->
...?

I will immediately create a player named 'Global'.
Reply
Parent - - By Caesar Date 2018-04-06 00:03 Edited 2018-04-06 00:11
Don't worry, it'll be 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…
Parent - - By Clonkonaut Date 2018-04-06 00:36

> 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.
Reply
Parent - By Caesar Date 2018-04-06 04:33
Well, at least reassigning numbers should be an easy thing to stop doing.
Parent - - By Luchs Date 2018-04-06 10:30
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.
Parent - - By Maikel Date 2018-04-06 10:46
What do with stuff like: Find_Hostile, DoWealth, GetKiller, InitializePlayer?
Parent - By Luchs Date 2018-04-06 11:03
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).
Parent - - By Sven2 [us] Date 2018-04-06 02:03
That sounds nice, but then we never know whether a player parameter expects the player number of the player proplist.
Parent - By Marky Date 2018-04-06 04:40
What do you mean?
Parent - - By Luchs Date 2018-04-06 10:27
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?).
Parent - - By Maikel Date 2018-04-06 10:47
Parent - - By Luchs Date 2018-04-06 11:41
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.
Parent - - By Zapper Date 2018-04-06 13:23
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.
Parent - - By Marky Date 2018-04-06 19:08
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;
   }
}
Parent - By Sven2 [us] Date 2018-04-07 00:52
You don't need arrays. But existing scripts use arrays, and you don't want to break everything.
Parent - By Zapper [de] Date 2018-04-07 08:42
I hope that rules/objects would not pollute the global "player" instances, but user their own local variables for saving. So, clearly yes
Parent - - By Sven2 [us] Date 2018-04-06 15:55
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.
Parent - - By Fulgen [at] Date 2018-04-07 08:35
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).
Parent - By Zapper [de] Date 2018-04-07 08:42

>As older scenarios probably have a lower version number, OC could switch between player proplists and player numbers on the fly


No, please no. That's a nightmare to maintain
Parent - - By Clonkonaut Date 2018-04-06 11:44
By the way, as this sounds like a huge change in everything. What exactly would be the gain here?
Reply
Parent - By Maikel Date 2018-04-06 11:57
I agree with this remark. This is massive in terms of the amoun of scripts that need to be changed.
Parent - - By Luchs Date 2018-04-06 15:52
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.
Parent - - By Marky Date 2018-04-06 16:55
Tons of regex-able changes :D
Parent - - By Luchs Date 2018-04-06 18:08
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());
Parent - By Marky Date 2018-04-06 19:01
Yes, anyway, I'd really like team and player proplists.
Parent - By Marky [de] Date 2018-04-06 21:34
What is the final decision on this? Rename only *Obj* functions to *Object*?
Up Topic Development / Developer's Corner / Renamed functions

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill