Re: Zooming in a mod ?
Posted: Fri Mar 04, 2016 10:47 pm
This functionality should be arriving in 0.13.binbinhfr wrote:In another subject, I would also love to have a way to detect keypress events.
Page 1 of 2
Re: Zooming in a mod ?
Posted: Fri Mar 04, 2016 11:10 pm
great !Supercheese wrote:This functionality should be arriving in 0.13.binbinhfr wrote:In another subject, I would also love to have a way to detect keypress events.
I would also like the ability to play a little soundfile (not only in direct relation with a button click).
Re: Zooming in a mod ?
Posted: Fri Mar 04, 2016 11:25 pm
All clients are executing the same code. If one client reads a value, all of them do.binbinhfr wrote:Ok. I understand better, even if I don't know why the client of player2 would like to read zoom of player1
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.binbinhfr wrote: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.
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.binbinhfr wrote: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 ?
Re: Zooming in a mod ?
Posted: Fri Mar 04, 2016 11:50 pm
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).binbinhfr wrote:I would also like the ability to play a little soundfile (not only in direct relation with a button click).
P.S. If anyone knows of a better way to play a sound for a player, I'd love to hear it.
Re: Zooming in a mod ?
Posted: Sat Mar 05, 2016 2:26 am
Thanks for the idea !Supercheese wrote: 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).
Re: Zooming in a mod ?
Posted: Sat Mar 05, 2016 5:44 pm
prg wrote: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.binbinhfr wrote: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.
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.
Re: Zooming in a mod ?
Posted: Sat Mar 05, 2016 7:15 pm
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.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.
Re: Zooming in a mod ?
Posted: Sat Mar 05, 2016 7:51 pm
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 wasbinbinhfr wrote: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.
Code: Select all
player1.zoom = player1.zoom * 2Code: Select all
if player1.zoom > .5 then player1.print("foo") else player1.print("bar") endRe: Zooming in a mod ?
Posted: Sat Mar 05, 2016 9:37 pm
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.prg wrote:But if you did something like
you'd already get a desync.Code: Select all
if player1.zoom > .5 then player1.print("foo") else player1.print("bar") end
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 ?
Re: Zooming in a mod ?
Posted: Sat Mar 05, 2016 9:58 pm
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.binbinhfr wrote: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.
Sure. Trybinbinhfr wrote: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.
Code: Select all
game.local_player.print(tostring({}))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 wrote:So why not supposing that authors that will use the zoom variable will do it reasonnably ?
Re: Zooming in a mod ?
Posted: Sat Mar 05, 2016 11:51 pm
Ok, but really, who would change the real game data according to the zoom value ?prg wrote:
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.