Zooming in a mod ?

[binbinhfr]

Hi,

i try to write a mod that can zoom extra wide if necessary, so I use the instruction "game.local_player.zoom = zoom", but it says that this function can only be used when called from the console... So it's impossible to change the zoom setting inside a mod ? You can only type the command in the console ? I cannot even read only this value... Strange...

[Supercheese]

It's just the "local_player" part that can only be used from the console. You should still be able to do this with something like:

Code: Select all

game.players[1].zoom = 0.125

... or whatever other zoom value you want.

(Also, instead of player1, you might need to figure out the player index of another player.)

[binbinhfr]

Thanks for your help. It works.
The only strange thing is that zoom seems to be write-only. It gives an error if I try to read it, but works if I write it...
see in doc-html/LuaPlayer.html there is a "W" instead or a "R". But then if I change the zoom using my mousewheel, I cannot figure out what's the new value in order to modify it smoothly.

[Klonan]

Thanks for your help. It works.
The only strange thing is that zoom seems to be write-only. It gives an error if I try to read it, but works if I write it...
see in doc-html/LuaPlayer.html there is a "W" instead or a "R". But then if I change the zoom using my mousewheel, I cannot figure out what's the new value in order to modify it smoothly.

I think if zoom was readable you might be able to desync the game with some poor scripting.


What you can do is like (going off memory here)

Code: Select all

script.on_event(defines.game.on_tick, function(event)

if global.ending_tick = nil then
  global.zoom_time = 60*5 -- 5 seconds
  global.ending_tick = game.tick + global.zoom_time
  global.start_zoom = 0.1
  global.end_zoom = 1
  global.zoom_rate = math.sqrt((global.end_zoom - global.start_zoom)^2)/global.zoom_time
  global.zoom_tick = 0
end

global.zoom = global.start_zoom + (global.zoom_tick * global.zoom_rate)
for k, p in pairs (game.player) do
  p.zoom = global.zoom 
end
global.zoom_tick = global.zoom_tick +1

if game.tick = global.ending_tick then
    script.on_event(defines.game.on_tick, nil)
    global.ending_tick = nil
end

end)

This is no means tested and will work or something, but since you're changing the zoom each tick, player input won't affect the players actual zoom

[binbinhfr]

I guess I have to change "defines.game.on_tick" into "defines.script.on_tick" , because it creates an error.

However, what you propose is a progressive zoom, but I still cannot start from the actual zoom value which is unreadable.
I would like to initialize your global.start_zoom with the actual zoom, in order to make things smooth.

> I think if zoom was readable you might be able to desync the game with some poor scripting.

I do not understand. Writing the zoom can really create brutal zoom changes, but why is reading zoom a problem ? Till I do nothing with it, I should be able to read a simple variable...

[Rseding91]

I guess I have to change "defines.game.on_tick" into "defines.script.on_tick" , because it creates an error.

However, what you propose is a progressive zoom, but I still cannot start from the actual zoom value which is unreadable.
I would like to initialize your global.start_zoom with the actual zoom, in order to make things smooth.

> I think if zoom was readable you might be able to desync the game with some poor scripting.

I do not understand. Writing the zoom can really create brutal zoom changes, but why is reading zoom a problem ? Till I do nothing with it, I should be able to read a simple variable...

Zoom is not saved in the game save file. So, you read it at one moment and it says "1.3" and then someone joins the multiplayer game and the script on their computer reads the zoom of player 1 which is now 1 (default) because zoom wasn't saved and the 2 players games are reporting different zoom levels for the same player. If either mod did anything with that information other than set zoom and discard the values the two games would not match each other and the game would desync.

Thus, zoom is write-only.

[Klonan]

I guess I have to change "defines.game.on_tick" into "defines.script.on_tick" , because it creates an error.

Sorry thats a mistake on my behalf, it should be like this:

Code: Select all

script.on_event(defines.events.on_tick, function(event)

if global.ending_tick = nil then
  global.zoom_time = 60*5 -- 5 seconds
  global.ending_tick = game.tick + global.zoom_time
  global.start_zoom = 0.1
  global.end_zoom = 1
  global.zoom_rate = math.sqrt((global.end_zoom - global.start_zoom)^2)/global.zoom_time
  global.zoom_tick = 0
end

global.zoom = global.start_zoom + (global.zoom_tick * global.zoom_rate)
for k, p in pairs (game.player) do
  p.zoom = global.zoom 
end
global.zoom_tick = global.zoom_tick +1

if game.tick = global.ending_tick then
    script.on_event(defines.game.on_tick, nil)
    global.ending_tick = nil
end

end)

[binbinhfr]

Zoom is not saved in the game save file. So, you read it at one moment and it says "1.3" and then someone joins the multiplayer game and the script on their computer reads the zoom of player 1 which is now 1 (default) because zoom wasn't saved and the 2 players games are reporting different zoom levels for the same player. If either mod did anything with that information other than set zoom and discard the values the two games would not match each other and the game would desync.

Thus, zoom is write-only.

Well I still not understand why Zoom of player 1 can bother player 2, who has his own viewing angle corresponding to his own position and zooming value. How can these zooms induce a desync ? Player1's view is drawn using player1.zoom on his screen and player2's view is drawn using player2.zoom. How player1.zoom can affect the screen of player2 ? I must be missing something, but I admit I never played in multiplayer mode.

[prg]

Code: Select all

if player1.zoom > threshold then A else B end

The same code runs on every client, so the zoom of every player would need to be known to every other player and this simply isn't synchronized at the moment.

[binbinhfr]

Code: Select all

if player1.zoom > threshold then A else B end

The same code runs on every client, so the zoom of every player would need to be known to every other player and this simply isn't synchronized at the moment.

Ok. I understand better, even if I don't know why the client of player2 would like to read zoom of player1 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.

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 ?

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

Anyway thanks for your explanations and your time.

[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.