tduniverse / cyberverse Goto Github PK

Currently, the game requires CLI arguments to connect to a specific server, but it may be a more immersive experience, if we had the server browser built into the game (on the main menu) instead of having an external launcher.

https://github.com/jpribyl/action-docker-layer-caching seems to be the proposed fork for it.

The native log statement that comes when spawning a server isn't present up until you close the container in WSL.
Maybe it's some missing stderr/stdout stream, maybe something else, too.

Currently we're using random NPCs to replicate other players, because it's probably more difficult to use Vs (as they may have body properties that need to be set, were never meant to be animated in third person) and as some people/servers certainly also like appearing as existing NPCs

Let's find out what is required to get some basic Vs to render.

Currently, we have no useful way of authentication. There is a packet, but it only sends the windows username.
To be of use, we need a (preferrably passwordless) approach that also leads to stable user identifiers.

My idea was to have a central hosted oidc compliant IdP (preferrably doing identity brokering with the major game stores).
Then, after logging in on the website, the JWTs (maybe the auth token, but especially the ID token) are used towards the individual user-hosted game servers. The tokens are signed, so the server can trust them, but is probably capable of using the auth token to query more information from an API endpoint (e.g. on which servers the user has been banned).

The only remaining question is how this interfers with #7 . It's much easier when we use an oidc flow from a desktop application than it probably is to cram into the red4ext DLL.

• The server needs to be informed about damage that is both incoming on the player and outgoing from the player.
• The server in the default configuration will just reflect that damage and
  • confirm the damage to the client (*) otherwise we could roll back the damage (think: godmode)
  • relay the damage incident to other players, which will reduce the NPCs health accordingly.

*: The client should first accept the damage and only roll it back on demand, as this is a relatively rare use case. It's only about how other NPCs health appears to you as a player and about self-inflicted damage (e.g. fall damage).

Also: As hinted above with "default configuration", there will be server plugins that may influence how damage is calculated (maybe with a scalar factor, but more common will be preventing damage). Maybe we can also add a "immune" flag to handle the godmode use-cases relatively well.

Basically, the created entity should have a component (and the related PS), so for instance when entering a car that has already been spawned by another player, we can tell the server that we wanted to enter exactly that car (by looking up if the entity we mount has a network id), otherwise we need to ad-hoc spawn a car and enter that.

yeah imo component is the cleanest solution
technically you can register persistent state without having an actual component
look at what I do in DynamicEntitySystem, you'll just need composite PersistentID with entity id and unique component name

There is a lot of locomotion / state machine that we need to synchronize / derive from NPC states. It may not be worth it to try to synchronize them perfectly (e.g. the keyframe inside the walk animation that we are currently), but we should at least start and stop animations accordingly.

This can be done as simple as: When the NPC moves forward, play the walking animation. That way, we can derive it without requiring actual packets.

For things such as swimming and ladders, additional packets may be required. Jumping is already stubbed via the PlayerActionTracker, just implemented falsely, as it listens to key-presses instead of the actual jumping.

• A player should spawn/transfer it's loadout onto the server, so there are entityIds (or "handles") to the weapons they are currently carrying.
• When equipping such a weapon, there will be another packet that maps hands to the handle (e.g. equip right hand: katana)
• Other clients need to be able to spawn the weapons in game and make the NPC equip them, as a result.
  • Whether this packet contains the full weapon information each time or if the client also needs to cache the handles for a specific npc, remains to be discussed. But I think we can waste the bandwidth here for an easier implementation. However the client maybe already has a ref<WeaponObject> at hand anyway?
• Damage is not part of the scope of this issue, maybe replicating attacks (shooting, aim angle replication, hitting animation for meele) is.

And commit the results so tweakdbstr.txt is not required to build the code. It may be done whenever there's adjustments to the tweakdbstr or like only once.

What counts is that we have something like:

namespace Cyberverse.Server.TweakDb.Generated;

public enum Character {
  Judy,
  Panam
}

Maybe we'd also want actual class members instead of an enum, so we can directly grab the string "Character.Panam" or their uint crc32 hash from them.

Currently, when pressing space on the intro video, we will load the last used savegame, but it would be more useful to not need that manual interaction.
For development purposes, it may even be nice to skip all the banners before the intro video even is a thing.

• Add a new packet that is sent when entering and leaving a vehicle
• This needs to build upon #2, so it can actually send an enter packet instead of force-spawning
• The current behavior of only spawning the entity should also send the new entering packet right after
• When the client receives a relayed "mount vehicle" packet for other entities, the NPCs should also take a seat.
• Backend may need to understand that to stop teleporting the NPC in that case

Currently, only the actual "recordId" is synced, so the tweakDB entry representing the entity itself, but not the appearance (cab, jackies bike, ...)