ClearUtils.clearProjectiles(client);

[Commaster]

Is it possible to add such function and call it at around https://github.com/popstarfreas/Dimensions/blob/dev/node_modules/dimensions/clientcommandhandler.ts#L51 ?

Known bad situation:

• Player has chloro set and an owned Projectile type 226.
• Player shifts dimensions and still thinks he has that projectile.
• Player proceeds to shoot Projectile type 227 from his imaginary projectile type 226. The new dimension is very confused.

Thank you.

[popstarfreas]

That seems like a good addition. It seems like a client-state synchronisation issue similar to #41. Is it better to send the server the information on the projectile upon switching or is it better to attempt to remove it?

[Commaster]

Transferring the projectiles over is nearly impossible: Even if the client is able to keep the owner+ident combo of the projectiles, the chances that the global(server) projectile id is unused in the new dimension are pretty slim.
So killing off projectiles seems like the way to go: Buff-based projectiles will be respawned by the buff refresh loop on the client, Equipment-based projectiles will be respawned by the equips update loop on the client.
Letting the client start off from scratch (like after running /clear projectiles) will cause the least issues.

[popstarfreas]

I don't think that's how it works from what I remember. The client decides on an id, and that is bound with their player id (what you said about owner+ident) to identify projectiles, the server will search through its array until it finds that combination for any projectile updates, I don't remember any server-side projectile id. I don't know how that interacts with the client when their player id changes though.

Buff-based projectiles may be respawned, but do you get things like the Solar Flare shield getting reset? That might be problematic.

[Commaster]

Also each client knows about the projectiles of other players. And when you jump dimensions those "other" projectiles will just lay dormant in the client memory. (That is if the client doesn't have one global 1000 projectiles array and instead keeps arrays for each player... Which I doubt)
Making the client forget everything about the previous dimension and then feed it information about the new dimension (we might have to send all server projectiles of the new server during the transition 🤔 ) leads to a more synchronized behavior.
I will check how Solar Flare works, thanks for the heads up.

[Commaster]

Solar Flare isn't a projectile but rather client-side Dust(s). Works directly off of Buffs (type 170, 171, 172).
This buff (and the chloro buff in the example above) check their consistency every tick.
tl;dr: The player will keep his current Solar Flare level and the Solar Flare levelup counter.

[popstarfreas]

How about minions? Does that reset the minions spawned?

[Commaster]

Minions are projectiles, so yes. And might be for the better since the new dimension might have different inventory/permissions.

[popstarfreas]

Yes but I don't believe that should be the responsibility of Dimensions. The server itself could easily remove them on the case that it doesn't want them. It would be especially annoying in the case that no SSC is involved, and the user is constantly getting their minions removed.

[Commaster]

Constantly? I guess there's a use case involving a LOT of dimension shifts.
Guess emulating all the ProjectileNew packets will be the solution?

[Commaster]

I'm just not sure how the server will react to new projectiles a mile away from where the player appears or even off the map if the world size is different.

[Commaster]

Would it be possible to add a config option for the switcher to either push the projectiles over or to kill them? If the target dimension is SSC and the transferred projectiles don't line up with their SSC inventory it could trigger an anti-cheat.
Or at least lower the Player.State below 10 until they are fully aware of the new dimension?

[popstarfreas]

Well a config option might work, because that way the host can choose which one fits what they're doing best. May also be possible to give the option to clear "always" or "ssc", so that they can enable it for SSC only? Since that sounds like the biggest reason to use clearing.

[Commaster]

Great idea since you can detect if the target dimension is in SSC mode 👍
"never", "ssc", "always"

[popstarfreas]

I assume that you're not up for programming it, so I self assigned it but if I am wrong then I'd be welcoming to a PR that adds it, since I don't have a lot of time to work on it.

[Commaster]

I've never used typescript/javascript so you clearly have more expertise in this.
...
Nobody has time nowadays, I know 😃

[popstarfreas]

I know it's been a while and I've not worked on it yet, I'm hoping that I can get around to it soon once I have time off.

[popstarfreas]

You can test the build using the zip at #56 and let me know if that does what you want yet. It keeps track of client projectiles and will send destroy projectile for each active projectile to the client when receiving world info while switching.

[popstarfreas]

Oh and I forgot to mention that you need to add the following to the config:

        synchronization: {
            projectiles: {
                enabled: true,
                type: "clear",
                when: "ssc",
            }
        }

[Commaster]

The problem with "keep" is that you can't guarantee that the target dimension will have free/enough projectile slots. They are hardcoded to 1000 slots and run out very quickly with a couple of players. Mostly only possible for small minigame-like dimensions.