Zooming in a mod ?

[Supercheese]

In another subject, I would also love to have a way to detect keypress events.

This functionality should be arriving in 0.13.

[binbinhfr]

In another subject, I would also love to have a way to detect keypress events.

This functionality should be arriving in 0.13.

great !

I would also like the ability to play a little soundfile (not only in direct relation with a button click).

[prg]

Ok. I understand better, even if I don't know why the client of player2 would like to read zoom of player1

All clients are executing the same code. If one client reads a value, all of them do.

But it would be nice that the zoom variable would return the correct value for the player on his own client, and maybe return 1 or nil on other clients.

Sounds like a bad idea. Of course you would only use that to implement smooth zooming which might even work, but the next guy is going to change some of the game state that's supposed to be synchronized based on such a value and we'd have another desync report caused by a broken mod in the bug reports forum.

Could you confirm this : in multi, game.players[1] is not always the local player who is running the local client ? game.players[1] is the same on every mod in the game ?

Right, there is no way of knowing which one the local player is AFAIK. If you type stuff in the console you can use game.local_player for that, but this doesn't work in a script.

[Supercheese]

I would also like the ability to play a little soundfile (not only in direct relation with a button click).

At the moment, the way to do this is a tad circuitous: you have to spawn an entity at the player's position that has a sound effect associated (e.g. explosion). You can see examples of this in the mods I've made (see signature).

P.S. If anyone knows of a better way to play a sound for a player, I'd love to hear it.

[binbinhfr]

At the moment, the way to do this is a tad circuitous: you have to spawn an entity at the player's position that has a sound effect associated (e.g. explosion). You can see examples of this in the mods I've made (see signature).

Thanks for the idea !

[ratchetfreak]

But it would be nice that the zoom variable would return the correct value for the player on his own client, and maybe return 1 or nil on other clients.

Sounds like a bad idea. Of course you would only use that to implement smooth zooming which might even work, but the next guy is going to change some of the game state that's supposed to be synchronized based on such a value and we'd have another desync report caused by a broken mod in the bug reports forum.

seems like what people really want is a way to run code only on one machine and based on offline settings (like zoom in this case, or a common request file data) and then send the result of the code to all clients.

[binbinhfr]

Of course you would only use that to implement smooth zooming which might even work, but the next guy is going to change some of the game state that's supposed to be synchronized based on such a value and we'd have another desync report caused by a broken mod in the bug reports forum.

I understand the idea of desync, but really i do not understand which important gamestate is related to this zoom value, which only describes the way one particular player looks at the world.

[prg]

I understand the idea of desync, but really i do not understand which important gamestate is related to this zoom value, which only describes the way one particular player looks at the world.

The zoom itself is not important, but depending on the value different clients are reading from it, other state could be changed. If all you did was

Code: Select all

player1.zoom = player1.zoom * 2

it would be fine even if other players would see garbage for this value. But if you did something like

Code: Select all

if player1.zoom > .5 then player1.print("foo") else player1.print("bar") end

you'd already get a desync.

[binbinhfr]

But if you did something like

Code: Select all

if player1.zoom > .5 then player1.print("foo") else player1.print("bar") end

you'd already get a desync.

Well I do not exactly understand the way Factorio multiplay works and how clients exchange data, and what kind of limited data they exchange. Very few I guess.

I suppose that mod's authors have to understand what they write to avoid desync, but honestly, I suppose that there are numerous other ways to induce a desync if you really want it. So why not supposing that authors that will use the zoom variable will do it reasonnably ?

[prg]

Well I do not exactly understand the way Factorio multiplay works and how clients exchange data, and what kind of limited data they exchange. Very few I guess.

I think it's just input actions that affect game state. Player walked $distance into $direction, player inserted $item into $entity. Player zoomed to $zoom_level doesn't seem to be included in that.

I suppose that mod's authors have to understand what they write to avoid desync, but honestly, I suppose that there are numerous other ways to induce a desync if you really want it.

Sure. Try

Code: Select all

game.local_player.print(tostring({}))

in a multiplayer game. That will print the address of a table that will get allocated differently for everyone.

So why not supposing that authors that will use the zoom variable will do it reasonnably ?

That would be a question for the devs. Not sure if this would be a safe assumption so I guess they're trying to limit the potential for useless bug reports as much as possible.

[binbinhfr]

That would be a question for the devs. Not sure if this would be a safe assumption so I guess they're trying to limit the potential for useless bug reports as much as possible.

Ok, but really, who would change the real game data according to the zoom value ?