Weirdness of the API?

[Xandaros]

Am I the only one who finds it weird that you use game.player.methodname(args) instead of game.player:methodname(args) or game.player.methodname(game.player, args)?
Sure, currently it only supports one player, but the same is true for inventories, etc. Is there any reason these things haven't been modeled as objects? It took me quite a while to figure out.

I also wonder why you use game.player.print(s) instead of print(s) to put text into the console. It would probably make sense in a multiplayer environment, but you should be able to simply use print on the "clientside". It makes testing a whole lot easier, since you use print quite a lot when entering lua commands into console.
(Doing a print=game.player.print and then using it crashes the game, does anyone know why?)

Lastly, I've noticed a lot of functions taking a table as single argument instead of arguments.

I realise the API is an early draft and will change in the future, but I wonder how much will be kept and if there are any reasons to define it like this.

[FreeER]

Sure, currently it only supports one player, but the same is true for inventories, etc.

Well for most everything else there can be more than one (right now you can only control one character, as for your inventories example the player actually has six different inventories + the extra quickbar(s))...there is/used to be a game.getplayer() function, though I haven't seen it used since around 3.x, which I assume will be resurrected with the grand intro to multiplayer, but yeah, it's pretty much the fact that there's only one player right now.

game.player.print...I'm quite used to it now so it doesn't bother me, as for print=game.player.print ...I don't remember it crashing before but it certainly does now

Lastly, I've noticed a lot of functions taking a table as single argument instead of arguments.

My guess is it's easier for the devs to convert/type-check a lua table than individual args? Plus most of the methods take arguments that would be logically grouped together (positions, positions and item/entity/tile names, etc.) and those can be easily passed to internal functions which take a strut/object rather than a comma separated list of args. But I'm mostly guessing, personally I like passing tables because I find it easier to create a table with the relevant info and then pass it than creating multiple variables and passing all of them, and I find it a bit annoying when the methods (that do take multiple args) don't take a table (recent experience is gettile...), though that's probably only because I've gotten used to using tables for most of them.

Maybe that helps a bit, probably not
But it does take a bit of getting used to, just like pretty much any api

[alloyed]

So about the game.player.print() thing. I tried the same thing and got the same crash, which sucks. The default print() function still works, which is fine if you're willling to open factorio in a terminal window, and you can redefine it to go to the normal window like so

Code: Select all

function print(...) return game.player.print(...) end

but that is sort of verbose for a console that doesn't have a native copy&paste, and since it only prints strings it doesn't really help for introspection all that much. I'm looking for a way to write libraries for the factorio console, so if anybody already knows what hoops I need to jump through, that'd be amazing. It looks they've sandboxed things pretty hard, which makes sense, but it does make things a little harder for me.
The single table argument thing is a common pattern in both lua and javascript to get keyword arguments ala python:

Code: Select all

myfunction("a", "b", "c")

is fine, but

Code: Select all

myfunction{a, b="b", c="c"}

lets you leave out arguments, and makes long lists of arguments more explicit.