Closed m-hynek closed 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?
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.
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.
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
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.
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.
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.
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.
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.
Tested and working great. Merged. Nice work!
8
implemented basic logic for moving spawnpoints