Get size of window.

[alexa]

I want to be able to draw a red square in the top left corner of the map relative to wherever the player is. Right now I have this code

Code: Select all

    rendering.draw_rectangle({
      surface = game.surfaces["nauvis"],
      left_top = game.players[1].position,
      right_bottom = { 
        game.players[1].position.x + 10, 
        game.players[1].position.y + 10 
      },
      filled = true,
      color = { r = 1, g = 0, b = 0, a = 0.1 }
    })

which draws a rectangle whereever the player is. I would like to do playerPos - windowSize / 2 which would draw it in the corner
Is there any api in which i could access the window size. For mod specific reasons I cannot draw this as a part of the gui.

[Choumiko]

Your best bet probably is https://lua-api.factorio.com/latest/Lua ... resolution and maybe LuaPlayer.display_scale (iirc it is the interface scale you can adjust in the settings)
and then watch for https://lua-api.factorio.com/latest/eve ... on_changed to redraw your rectangle

[Klonan]

This isn't really going to work, because you can't read the players zoom level.

For mod specific reasons I cannot draw this as a part of the gui.

What are those specific reasons?
Maybe we can add something to the base game to help

[alexa]

I am looking to add weather to factorio, right now the thought process has been to draw an image over the screen. Since my last post I realized that I am dumb and it's just LuaPlayer.display_resolution. Thank you Choumiko. This appears to work for the default zoom level however does not update when the player zooms in or out. I thought this would be a simple fix but it doesn't appear that the zoom is accessible. viewtopic.php?t=10146. This confuses me somewhat because while it is deterministic surely it is stored internally somewhere, so internally why is it not accessible to the mod api? Alternately there doesn't appear to be a way to capture scroll wheel events so I am not sure I can just do a wrapper around it. Though I might just be being bad again. Thanks.

Edit: I forgot to say why the gui wouldn't work, because I am not doing to draw a single image over the entire screen, it shouldn't scale, instead there should be more images that are only drawn if they need to be. I would like to access the zoom in order to determine how many of these images to draw

[eradicator]

This isn't really going to work, because you can't read the players zoom level.

Maybe we can add something to the base game to help

Btw, this has always puzzled me. It seems that this would be a simple synchronization of input-actions, so why is zoom not readable? Or rather...is it entirely out of the question to ever make it readable?
______________________
@OP:
As far as hacks and my own thoughts about possible implementations of visual wheather go:
I think it's possible to "hijack" the games zoom by abusing linked_control custom inputs to simply steal all the zoom actions and implement the zooming yourself. This is a horrible hack that would likely be incompatible with any other mod that also tries to do "something with zoom". I've thought about making a generalized implementation, but was unsure if other people would care to use it.
As an approximation and if the graphics are always-same-in-world-size you could ofc simply always assume max zoom level.
If you want to have the graphics as always-same-size-on-screen then maybe support for scale_with_zoom on draw_sprite objects would solve the problem? Currently it seems to be only supported for text objects.

[alexa]

Good to know, I would like to avoid that level of hack but at least there is some way around it. Thanks

[Rseding91]

Btw, this has always puzzled me. It seems that this would be a simple synchronization of input-actions, so why is zoom not readable? Or rather...is it entirely out of the question to ever make it readable?

Because it would generate a lot of network data for something that hasn't been deemed necessary in the base game yet.

[eradicator]

Btw, this has always puzzled me. It seems that this would be a simple synchronization of input-actions, so why is zoom not readable? Or rather...is it entirely out of the question to ever make it readable?

Because it would generate a lot of network data for something that hasn't been deemed necessary in the base game yet.

Thanks. I always assumed that all "defines.input_action"'s are synchronized. But looking at the list again now i notice that zoom isn't even part of it. As far as i understand input actions are 95% of the network traffic? So if i used above hack of linking zoom-in zoom-out, and assuming that players zoom about as much as they walk around, that would mean the hack would about double network traffic... is that about right?

[alexa]

After looking through this mod https://mods.factorio.com/mod/SmogVisualPollution I have found that they do it by drawing over every chunk. I run on a potato and loading this onto an established map dropped my fps significantly. So for me the "ideal" mod api would be access to the camera position an zoom. This being said I understand that this must be very very difficult from a multiplayer programming point of view which I did not initially consider.

So the next idea I had is to rewrap the player camera. This obviously is not ideal but it appears that wube is doing this in some capacity in https://github.com/wube/factorio-data/b ... camera.lua for the scenarios. I haven't looked into this enough to get 100% of how it works but this does seem promising

[Optera]

As long as weather effects are only visual and don't change anything in the game state they should be running as camera overlay only for clients that have them enabled like clouds or film grain in night vision.

In case the API doesnt yet support modifying camera filters that's something that could be added without any thought about network performance or desync potetntial.

[eradicator]

@alexa:
Implementation:
Drawing over every chunk in the world is not nessecary. The positions of players are known. The maximum zoom-out is known (unless mods change it, but even that can be compensated). So you really only ever need to draw stuff in an approximate ~5 chunk radius around each player, and when the players move/log out you can delete the rest. There's one unsolvable though: The player can use the map to view remote areas, but as far as i know the api doesn't expose the position that the player is currently viewing.

Conceptual feedback:
Localised weather like in minecraft might also be interesting. I.e. if it rains it doesn't rain on the whole planet at once, only in some places.

@Optera: Camera filters aren't possible, and @posila said that he doesn't want to support "fullscreen post-process".

[Optera]

@Optera: Camera filters aren't possible, and @posila said that he doesn't want to support "fullscreen post-process".

Bummer, I guess we need ENB injection for Factorio