WheteThunger / MonumentAddons

Add entities, spawn points and more to monuments
https://umod.org/plugins/monument-addons
MIT License
5 stars 9 forks source link

movable spawn points #40

Closed m-hynek closed 2 years ago

m-hynek commented 2 years ago

8

implemented basic logic for moving spawnpoints

m-hynek commented 2 years ago

I was busy lately, so after some delay I got back to this and modified code I posted before.

There is case when moving entity that has less population than spawn points (or less SpawnPerTick than pop), moved entity can respawn in another spawnpoint = dissapear after moved. Should be entity killed manually and then force it to spawn on that same spawn point, instead of using spawnGroupController.Respawn()?

Other option could be just moving spawned entity and believe it will respawn in same position (as it should anyway), and dont bother with respawns.

What approach makes more sense?

WheteThunger commented 2 years ago

I think the most correct approach would be to move all of the spawn point instances with the spawn point. This could probably be achieved with the following steps.

  1. Calculate/cache the local position and rotation of each entity relative to the spawn point (not relative to the monument).
  2. Move the spawn point.
  3. Move each entity to the new correct world position, as determined by its local position and rotation captured earlier.

There might be some minor issues with moving vehicles, since I've seen that teleporting a modular car for instance can make it spin around a bit, which can be mitigated. Here is the overly complicated way I did it in Spawn Modular Car (my first plugin). There's probably a simpler generic solution.

m-hynek commented 2 years ago

I noticed strange behavior with vehicles - when a vehicle is moved +- one foundation size away from its spawn point, it is no longer connected to spawn point adapter. I think it may be intended for vehicles - when player takes one, adapter forgets it so new one can be spawned. We can add condition to not remove vehicle from adapter when telekinesis moving it, but i couldnt find code of this behavior

m-hynek commented 2 years ago

In addition to modifying vehicle rigidbody to kinematic in Telekinesis plugin, we should change behavior of moving modular cars - when I aim at car module and execute /tls command, it moves only that module while it is still parented to its chassis. Aiming at car chassis allows to move whole car. I cant see any useful use case of moving only car module, so Telekinesis should move whole car no matter what module was targeted by /tls.

WheteThunger commented 2 years ago

I noticed strange behavior with vehicles - when a vehicle is moved +- one foundation size away from its spawn point, it is no longer connected to spawn point adapter. I think it may be intended for vehicles - when player takes one, adapter forgets it so new one can be spawned. We can add condition to not remove vehicle from adapter when telekinesis moving it, but i couldnt find code of this behavior

Yes, this is intended. It's in SpawnedVehicleComponent. The disconnect you describe is probably caused by the fact that the original position is cached (Vector3 _originalPosition), which was done as a performance optimization since getting the current position makes a call to native. I suggest we just stop caching it.

In addition to modifying vehicle rigidbody to kinematic in Telekinesis plugin, we should change behavior of moving modular cars - when I aim at car module and execute /tls command, it moves only that module while it is still parented to its chassis. Aiming at car chassis allows to move whole car. I cant see any useful use case of moving only car module, so Telekinesis should move whole car no matter what module was targeted by /tls.

Sure, that can be added to Telekinesis.

WheteThunger commented 2 years ago

Are we taking into account the fact that a single spawn point can spawn multiple entities randomly in a radius? For instance, how barrel spawners work. This is why I suggested keeping each entity's relative position to the spawn point then transforming relative to the spawn point's new position, to allow the entities to keep the same relative orientation. Arguably this isn't very critical since the positions are random in that case anyway; could possibly just randomly reposition them.

m-hynek commented 2 years ago

Are we taking into account the fact that a single spawn point can spawn multiple entities randomly in a radius? For instance, how barrel spawners work. This is why I suggested keeping each entity's relative position to the spawn point then transforming relative to the spawn point's new position, to allow the entities to keep the same relative orientation. Arguably this isn't very critical since the positions are random in that case anyway; could possibly just randomly reposition them.

No I didnt think about Exclusive option. It in fact moved all objects into same position as result of this oversight, so as quick fix I added call of SpawnPoint.GetLocation that randomizes placement as configured per spawnpoint. Im not sure if we should randomize positions if 'Exclusive' option is set to false, since it can confuse user when entity ends up in place different than it was when Telekinesis stopped, but I left it as it is so behavior is unifiorm.

But I didn't find code that is making sure entities wont spawn into another. If Rust checking this this internally or it is not convinient enough, it may be worth to refactor it so entities are moved realatively to spawn point.

WheteThunger commented 2 years ago

But I didn't find code that is making sure entities wont spawn into another. If Rust checking this this internally or it is not convinient enough, it may be worth to refactor it so entities are moved realatively to spawn point.

That's only being checked when the CheckSpace option is set, and even then, it doesn't work well with random positions; it's useful primarily for vehicles and structures (i.e., dwellings such as at Desert Military Base). You'll notice sometimes in vanilla that barrels will be clipping into each other.

WheteThunger commented 2 years ago

Tested and working great. Merged. Nice work!