[1.1.61+] GameViewSettings to have camera offset (allows aimming, driving and guidance)

[KeepResearchinSpoons]

What

I want to be able to shift the camera around getting the character off the mid of the screen for level-design and gameplay reasons.

How

GameViewSettings could have an rw param of a position (offset); aka {number,number} | {x=number, y=number} | nil (or {0,0}?)
nil or {0,0} as the default;

offset vector is given in tiles
(or, maybe, in % (0.) of vieport size? (Not sure vieport can be reasonably relied to gameplay-wise though)
allows to change where the middle-of-the-screen points at.

Why

reasons include but not limited to:
[*] aim from the riffle (or from your trusty arty cannon!) in the direction of your choise keeping both the interactivity and engine's collisions, zones, events. And the zoom scale of what you want.
[*] guide the player to the point of interest without introducing a cumbersome unresponsive(!) cutscene (this is not a pause, this is a hint!)
[*] shift the camera a bit towards the "enemy side" when you clean the ribbon-like map; half the screen with no bitors on it is not as fun kappa! I need to zoom out to see "farther", but I often can't get too close for them to be all-around, yet need details on that particular part of the screen.
[*] you can also follow the rocket that flies away leaving you behind on the polluted planet with your interpolated eyes for a short while.
[*] You can vibe up-up down-down left-right left-right, fish, enable-exos just along the speaker melody.
[*] did I say driving?

The rest

unholy makeshift workaround

there is a way with a ghost char (but it is limited for obvious reasons)
while you can steer the real char around and back-feed the position with the offset, nades and other stuff would consider you the center; let alone death events etc.

crude lua command

Code: Select all

-- Apache-2.0/MIT/CC0 (c) all the mews
-- /sc
vector = {8,0}
player = game.player
if game.player.character then game.player.character.destroy() end
char = game.player.surface.create_entity({name = "character", position = {0,0}, force = "player"})
function on_tick(event)
  char.walking_state = player.walking_state
  player.teleport({char.position.x + vector[1], char.position.y + vector[2]})
end
script.on_event(
  defines.events.on_tick,
function(event)
  if pcall(on_tick,event) then
  else
    if event.tick % 60 == 0 then game.print("on_tick_err!") end
  end
end)

the killer punch? The latency. You loved driving? Love it even more.

back-rider ideas

As another idea, a separate "following" camera type for the vieport would also solve that maybe?
Abstracting the camera from the controller may sound like a leg-shot or an overkill, but is a popular way around in 3d games.
Kicking the camera around is probably the only other thing apart from shaders (well, colors lights and shadows, "alpha-blinking" included) that can guide and supply hints without creating new "entities" in the player's context field.
I need a hint, not an arrow of a "GOTO or be damned".
So I want ways to control the vieport, the offset to the "usual" is just the easiest from my perspective.

The primary idea behind is to "look around" in the _sane_ distances of a few chunks, what could possibly go wrong getting into the unknown...
The other idea is to not give the direct control of this to the player, but manage it through the Lua (as the source of truth for the offset).
While I do want to have the look-around "everywhere" as a seasoned player, that would be hard as I see it:
[*] mouse is already busy, no "second joystick" here, mind is busy as well, no time to manage it "by-hand"
[*] frequent updates of the value (player actions) would hit the protocol (and replay) with a challenge of keeping the context (what the player sees) over the issue of logging and storing and syncing the pure chaotic randomness the player is from everyone to everyone.
Thus, suggesting it go the Lua-first way I intend to make the setting either static or change it through triggers' effects that "have to happen" through that single Lua thread anyways,

That said, possible options include: make "panning" in the small zone around of say quarter of a chunk through either middle click or maybe ctrl-shift-click?
Say, when some flag like "allow_manual_panning" allows for it, player can pan around all they want; once the flag is set, it is the problem of Lua to smoothly guide the vieport to the point of interest and back to the saved state, dropping all the inputs during the process.
If the center of the screen keeps the middle-light-circle, it could be used as a more "precise" form of a flashlight aka no spamming ctrl-alt-gps. So the flashlight can no longer jump over selected items, but be limited to where the player "looks", should the player choose so.
Side idea: if available for reading, player's panning could be used for "gestures" and "macro" input. Like look down. I said down!.

Misc

[*] this has been discussed in official-discord #mod-making See this message and around for the context
[*] there is no sane way to play around with the vieport (camera) in the present time:
steering a char "remotely" is not fun in numerous ways
camera controls to do so "natively" are simply non-existent to my knowledge
[*] I am not sure an event of this-var-changed or even G-V-Settings updated is needed, but I see little room for inter-mod cooperation unless one becomes a "host" (framework/owner). This is not a problem for us, we "win" data races with frame just fine already. But just a few cents on top for the glue. Just a warning for those little extenders mods vs big ones adopting the feature for their own reasons just as well.