Dance Menu 0.2.5
- Автор темы b0t.
- Дата начала
foxstargod
Участник
- Сообщения
- 7
- Рейтинг
- 2
ахаха, такое бы сделать для каких-нибудь випов по доступу, например при выигранном раунде что бы танец проигрывался)) выглядит угарно))
XploitiT
Участник
- Сообщения
- 15
- Решения
- 1
- Рейтинг
- 8
CSLover
Участник
- Сообщения
- 3
- Рейтинг
- 1
I have a plugin conflict between a Dance plugin and the AdminFreeLook plugin, and I would like to fix it while keeping the functionality of both plugins intact.
The problem occurs when a player uses the Dance plugin and starts dancing. The dancing player is visible to other players through the dance model created by the Dance plugin, but the actual player entity becomes an invalid spectator target.
As a result, dead players cannot spectate the dancing player, and admins using AdminFreeLook are also unable to select the dancing player as a spectator target.
I previously looked into the SMA source code of both plugins, and it appears that the conflict is related to the way the Dance plugin hides the player's original model and the way AdminFreeLook validates spectator targets.
The Dance plugin hides the player's original model and then uses a separate entity to display the dancing model. Because of this, the original player entity can end up in a state that the Observer/Spectator system or AdminFreeLook considers an invalid spectate target.
The goal is to achieve the following:
The player should still be able to use the Dance plugin normally.
The dancing model should remain visible to other players as intended.
Dead players should still be able to spectate the dancing player.
Admins should also be able to spectate the dancing player using AdminFreeLook.
We should not have to disable any important functionality of either plugin.
Ideally, the conflict should be handled at the ReAPI/engine level without introducing additional spectator or visibility problems.
Could someone help me with this please?
The problem occurs when a player uses the Dance plugin and starts dancing. The dancing player is visible to other players through the dance model created by the Dance plugin, but the actual player entity becomes an invalid spectator target.
As a result, dead players cannot spectate the dancing player, and admins using AdminFreeLook are also unable to select the dancing player as a spectator target.
I previously looked into the SMA source code of both plugins, and it appears that the conflict is related to the way the Dance plugin hides the player's original model and the way AdminFreeLook validates spectator targets.
The Dance plugin hides the player's original model and then uses a separate entity to display the dancing model. Because of this, the original player entity can end up in a state that the Observer/Spectator system or AdminFreeLook considers an invalid spectate target.
The goal is to achieve the following:
The player should still be able to use the Dance plugin normally.
The dancing model should remain visible to other players as intended.
Dead players should still be able to spectate the dancing player.
Admins should also be able to spectate the dancing player using AdminFreeLook.
We should not have to disable any important functionality of either plugin.
Ideally, the conflict should be handled at the ReAPI/engine level without introducing additional spectator or visibility problems.
Could someone help me with this please?
b0t.
Скриптер
- Сообщения
- 40
- Решения
- 2
- Рейтинг
- 36
