<![CDATA[G1R:MP Forum - G1 Remake Multiplayer Community

<![CDATA[G1R:MP Forum - G1 Remake Multiplayer Community - Suggestions]]> https://g1r-mp.com/forum/ Wed, 04 Nov 2026 01:06:57 +0000 MyBB <![CDATA[Monster/NPC-Animation / World Snap / Torches / Magic]]> https://g1r-mp.com/forum/showthread.php?tid=72 Fri, 23 Oct 2026 05:51:44 +0000 Chenentano]]> https://g1r-mp.com/forum/showthread.php?tid=72
Examples:
setMonsterAnim(sleep)
SetMonsterAttackSpeed(2)
SetNativeAI(true)

setNPCNativeAI(true) or smth

__

Right now monsters can run trough walls etc, would be great if it's possible to fix it engine sided.

__

I cant find a way to equip torches right now except the via native menu. The same with magic runes and scrolls.]]>
Examples:
setMonsterAnim(sleep)
SetMonsterAttackSpeed(2)
SetNativeAI(true)

setNPCNativeAI(true) or smth

__

Right now monsters can run trough walls etc, would be great if it's possible to fix it engine sided.

__

I cant find a way to equip torches right now except the via native menu. The same with magic runes and scrolls.]]> <![CDATA[Własne animacje + propy]]> https://g1r-mp.com/forum/showthread.php?tid=71 Wed, 21 Oct 2026 14:49:18 +0000 JoePL]]> https://g1r-mp.com/forum/showthread.php?tid=71 <![CDATA[setLoadingScreenSkip]]> https://g1r-mp.com/forum/showthread.php?tid=65 Sun, 27 Sep 2026 09:36:33 +0000 Rul3zZ]]> https://g1r-mp.com/forum/showthread.php?tid=65 __________

setLoadingScreenSkip(true)

addEventHandler("onClientLoadingScreenFinished", root, function()
showLoginMenu()
end)

__________

Default stays as it is today (false), so nothing changes for other servers.
Nice to have: setLoadingScreenText("...") for our own hint text on the loading screen.

]]> __________

setLoadingScreenSkip(true)

addEventHandler("onClientLoadingScreenFinished", root, function()
showLoginMenu()
end)

__________

Default stays as it is today (false), so nothing changes for other servers.
Nice to have: setLoadingScreenText("...") for our own hint text on the loading screen.

]]> <![CDATA[playSoundFromGame]]> https://g1r-mp.com/forum/showthread.php?tid=64 Sun, 27 Sep 2026 09:25:14 +0000 Rul3zZ]]> https://g1r-mp.com/forum/showthread.php?tid=64 playSound playSound3D.

Code:
local handle = playSoundFromGame("GVL_G1R_VOICE24_CONVERSATIONSMALLTALK_3", false, 0.8)

Code:
local handle = playSoundFromGame3D("GVL_G1R_VOICE24_CONVERSATIONSMALLTALK_3", x, y, z, false, 0.72, 1.5, 18.0)

Code:
stopSound(handle)

Plays in the player's own game language.
Returns false if the key doesn't exist.
The handle works with the existing audio functions (stopSound, setSoundVolume, setSound3DPosition, ...).

Use case: ambient NPC chatter on RP servers using the game's own voice types.]]> playSound playSound3D.

Code:
local handle = playSoundFromGame("GVL_G1R_VOICE24_CONVERSATIONSMALLTALK_3", false, 0.8)

Code:
local handle = playSoundFromGame3D("GVL_G1R_VOICE24_CONVERSATIONSMALLTALK_3", x, y, z, false, 0.72, 1.5, 18.0)

Code:
stopSound(handle)

Plays in the player's own game language.
Returns false if the key doesn't exist.
The handle works with the existing audio functions (stopSound, setSoundVolume, setSound3DPosition, ...).

Use case: ambient NPC chatter on RP servers using the game's own voice types.]]> <![CDATA[Kilka sugestii]]> https://g1r-mp.com/forum/showthread.php?tid=63 Wed, 23 Sep 2026 21:24:17 +0000 JoePL]]> https://g1r-mp.com/forum/showthread.php?tid=63 Dziś serwer widzi tylko, co gracz ma w slotach, a nie to, czy trzyma broń w dłoni. Dla magii jest to już dostępne (
inHand w onPlayerSpellEquip), dla broni białej i łuku nie.

Code:
getPlayerWeaponMode(playerId)  --> "none"|"fist"|"melee"|"bow"|"crossbow"|"magic"
onPlayerWeaponModeChange(playerId, previousMode, newMode)

2. Obrażenia NPC
Dziś żadne zdarzenie nie mówi, że gracz uderzył NPC. onPlayerHitdotyczy tylko walki gracz–gracz.

Code:
onNpcDamage(npcId, attackerId, damage, damageType, healthAfter)
setNpcHealth(npcId, hp) / setNpcMaxHealth(npcId, hp) / getNpcHealth(npcId)
setNpcInvulnerable(npcId, true)  -- kupiec, którego nie da się zabić
onNpcDeath(npcId, killerId)

3. Wyciąganie broni przez NPC

Code:
setNpcWeaponMode(npcId, "melee")  -- wyciąga broń z setNpcWeapon
setNpcWeaponMode(npcId, "none")    -- chowa

4. Obrót NPC w stronę gracza
Dziś jedyną drogą jest setNpcPosition z nowym kątem, czyli teleport, który przerywa trasę.

Code:
setNpcLookAt(npcId, playerId)      -- obraca się i śledzi gracza wzrokiem
setNpcLookAt(npcId, false)        -- koniec

5. Atak NPC na gracza (potwory już to mają przez setMonsterTarget)

Code:
setNpcCombatTarget(npcId, playerId)  -- strażnik atakuje
setNpcCombatTarget(npcId, false)      -- przerywa walkę
setNpcAttackDamage(npcId, 15)
onNpcAttack(npcId, targetPlayerId, damage)

6. Animacje NPC (ten sam katalog 118 animacji co startAnim dla graczy)

Code:
startNpcAnim(npcId, "threaten", false, 0.15)  -- gest „schowaj to!”
stopNpcAnim(npcId)

7. Percepcja NPC (wzrok z przeszkodami, jak isPlayerInTarget, ale dla NPC)

Code:
isNpcSeeingPlayer(npcId, playerId [, maxDist = 15, fov = 120])  --> bool

]]> Dziś serwer widzi tylko, co gracz ma w slotach, a nie to, czy trzyma broń w dłoni. Dla magii jest to już dostępne (
inHand w onPlayerSpellEquip), dla broni białej i łuku nie.

Code:
getPlayerWeaponMode(playerId)  --> "none"|"fist"|"melee"|"bow"|"crossbow"|"magic"
onPlayerWeaponModeChange(playerId, previousMode, newMode)

2. Obrażenia NPC
Dziś żadne zdarzenie nie mówi, że gracz uderzył NPC. onPlayerHitdotyczy tylko walki gracz–gracz.

Code:
onNpcDamage(npcId, attackerId, damage, damageType, healthAfter)
setNpcHealth(npcId, hp) / setNpcMaxHealth(npcId, hp) / getNpcHealth(npcId)
setNpcInvulnerable(npcId, true)  -- kupiec, którego nie da się zabić
onNpcDeath(npcId, killerId)

3. Wyciąganie broni przez NPC

Code:
setNpcWeaponMode(npcId, "melee")  -- wyciąga broń z setNpcWeapon
setNpcWeaponMode(npcId, "none")    -- chowa

4. Obrót NPC w stronę gracza
Dziś jedyną drogą jest setNpcPosition z nowym kątem, czyli teleport, który przerywa trasę.

Code:
setNpcLookAt(npcId, playerId)      -- obraca się i śledzi gracza wzrokiem
setNpcLookAt(npcId, false)        -- koniec

5. Atak NPC na gracza (potwory już to mają przez setMonsterTarget)

Code:
setNpcCombatTarget(npcId, playerId)  -- strażnik atakuje
setNpcCombatTarget(npcId, false)      -- przerywa walkę
setNpcAttackDamage(npcId, 15)
onNpcAttack(npcId, targetPlayerId, damage)

6. Animacje NPC (ten sam katalog 118 animacji co startAnim dla graczy)

Code:
startNpcAnim(npcId, "threaten", false, 0.15)  -- gest „schowaj to!”
stopNpcAnim(npcId)

7. Percepcja NPC (wzrok z przeszkodami, jak isPlayerInTarget, ale dla NPC)

Code:
isNpcSeeingPlayer(npcId, playerId [, maxDist = 15, fov = 120])  --> bool

]]> <![CDATA[Cancellable pre-action hooks for custom resources]]> https://g1r-mp.com/forum/showthread.php?tid=61 Thu, 17 Sep 2026 16:02:48 +0000 Rul3zZ]]> https://g1r-mp.com/forum/showthread.php?tid=61
Could G1R:MP expose server-side hooks that let custom resources reject gameplay actions before their effects are applied?
According to the wiki, pickup, drop and damage events report completed changes.
For RP servers, public pre-action hooks would allow ownership checks, protected items and custom combat restrictions.

For example.:

_____________________________________________________

addEventHandler("onPlayerRequestPickup", root,
function(playerId, objectId)
-- Custom permission check
if not canPlayerTakeItem(playerId, objectId) then
cancelEvent()
end
end
)

_____________________________________________________

Similar hooks for dropping, equipping, consuming items and applying damage would be useful. Cancellation should prevent the action without requiring scripts to undo inventory or health changes afterward.

This would complement the existing native validation and completion events. Are public pre-action hooks planned?]]>
Could G1R:MP expose server-side hooks that let custom resources reject gameplay actions before their effects are applied?
According to the wiki, pickup, drop and damage events report completed changes.
For RP servers, public pre-action hooks would allow ownership checks, protected items and custom combat restrictions.

For example.:

_____________________________________________________

addEventHandler("onPlayerRequestPickup", root,
function(playerId, objectId)
-- Custom permission check
if not canPlayerTakeItem(playerId, objectId) then
cancelEvent()
end
end
)

_____________________________________________________

Similar hooks for dropping, equipping, consuming items and applying damage would be useful. Cancellation should prevent the action without requiring scripts to undo inventory or health changes afterward.

This would complement the existing native validation and completion events. Are public pre-action hooks planned?]]> <![CDATA[Instances / Virtual Worlds]]> https://g1r-mp.com/forum/showthread.php?tid=60 Thu, 17 Sep 2026 15:58:47 +0000 Rul3zZ]]> https://g1r-mp.com/forum/showthread.php?tid=60
For our Roleplay server, this would be useful for character creation, private RP events and separate dungeon groups.

Players in different instances should not see, hear or interact with each other. NPCs, world items, combat and spatial voice should respect the same separation.

For example.:
__________________________________________

local instanceId = createInstance()

setPlayerInstance(playerId, instanceId)
setNpcInstance(npcId, instanceId)

-- Return to the main world
setPlayerInstance(playerId, 0)

-- Once players have left
destroyInstance(instanceId)

__________________________________________

Server-controlled membership and clear cleanup rules would help prevent entities or interactions leaking between instances.

I couldn't find this in the wiki. Is something similar already available or planned?]]>
For our Roleplay server, this would be useful for character creation, private RP events and separate dungeon groups.

Players in different instances should not see, hear or interact with each other. NPCs, world items, combat and spatial voice should respect the same separation.

For example.:
__________________________________________

local instanceId = createInstance()

setPlayerInstance(playerId, instanceId)
setNpcInstance(npcId, instanceId)

-- Return to the main world
setPlayerInstance(playerId, 0)

-- Once players have left
destroyInstance(instanceId)

__________________________________________

Server-controlled membership and clear cleanup rules would help prevent entities or interactions leaking between instances.

I couldn't find this in the wiki. Is something similar already available or planned?]]> <![CDATA[Object placement previews and editing API]]> https://g1r-mp.com/forum/showthread.php?tid=59 Thu, 17 Sep 2026 15:55:56 +0000 Rul3zZ]]> https://g1r-mp.com/forum/showthread.php?tid=59
For our Roleplay server, we are building an in-game world editor.

`spawnItem` already supports exact coordinates, yaw and ground snapping.

To complement this, could we get:

- Transparent, client-only previews without collision or pickup.
- Camera raycasts for placement targeting.
- Functions to move, rotate and delete existing world items.

an small Example.:
____________________________________________________________

-- Client: local preview
local preview = createObjectPreview("itfo_apple", x, y, z)
setObjectPreviewOpacity(preview, 0.45)

local hit = raycastFromCamera(maxDistance)
if hit then
setObjectPreviewPosition(preview, hit.x, hit.y, hit.z)
setObjectPreviewRotation(preview, yaw)
end

destroyObjectPreview(preview)

-- Server: edit an existing item
setWorldItemPosition(objectId, x, y, z)
setWorldItemRotation(objectId, yaw)
destroyWorldItem(objectId)

________________________________________________________

Placement would use the existing `spawnItem` after server validation.
These additions would allow preview → adjust → confirm, plus editing placed items.

I couldn't find these features in the wiki. If equivalents already exist, a short example would be appreciated!

Cheers!]]>
For our Roleplay server, we are building an in-game world editor.

`spawnItem` already supports exact coordinates, yaw and ground snapping.

To complement this, could we get:

- Transparent, client-only previews without collision or pickup.
- Camera raycasts for placement targeting.
- Functions to move, rotate and delete existing world items.

an small Example.:
____________________________________________________________

-- Client: local preview
local preview = createObjectPreview("itfo_apple", x, y, z)
setObjectPreviewOpacity(preview, 0.45)

local hit = raycastFromCamera(maxDistance)
if hit then
setObjectPreviewPosition(preview, hit.x, hit.y, hit.z)
setObjectPreviewRotation(preview, yaw)
end

destroyObjectPreview(preview)

-- Server: edit an existing item
setWorldItemPosition(objectId, x, y, z)
setWorldItemRotation(objectId, yaw)
destroyWorldItem(objectId)

________________________________________________________

Placement would use the existing `spawnItem` after server validation.
These additions would allow preview → adjust → confirm, plus editing placed items.

I couldn't find these features in the wiki. If equivalents already exist, a short example would be appreciated!

Cheers!]]> <![CDATA[[Feature request] IsPlayerCombatMode]]> https://g1r-mp.com/forum/showthread.php?tid=57 Tue, 15 Sep 2026 17:40:36 +0000 PaolSon44]]> https://g1r-mp.com/forum/showthread.php?tid=57
Something like that will be cool:

isPlayerCombatMode

Checks wheter player is in combat mode. Usually like held melee / distance weapon, fists or use magic.

Syntax

Quote:bool isPlayerCombatMode(int playerId)

Examples

Quote:if isPlayerCombatMode(playerId) then
unbindKey("tab", "both", handleScoreboard)
end

In this way server can check player combat state, so this will enable to protect other functions which would be disturb a combat. Big Grin

]]>
Something like that will be cool:

isPlayerCombatMode

Checks wheter player is in combat mode. Usually like held melee / distance weapon, fists or use magic.

Syntax

Quote:bool isPlayerCombatMode(int playerId)

Examples

Quote:if isPlayerCombatMode(playerId) then
unbindKey("tab", "both", handleScoreboard)
end

In this way server can check player combat state, so this will enable to protect other functions which would be disturb a combat. Big Grin

]]> <![CDATA[Nameplate Color]]> https://g1r-mp.com/forum/showthread.php?tid=55 Sun, 13 Sep 2026 17:14:36 +0000 Xardas0327]]> https://g1r-mp.com/forum/showthread.php?tid=55 I think it can be useful for deathmatch teams or for guilds.

Quote:SetPlayerNameplateColor(playerid, r, g, b)

Quote:local r, g, b = GetPlayerNameplateColor(playerid)

I think it is useless if the name and the id can has different color, but who knows. Big Grin

]]> I think it can be useful for deathmatch teams or for guilds.

Quote:SetPlayerNameplateColor(playerid, r, g, b)

Quote:local r, g, b = GetPlayerNameplateColor(playerid)

I think it is useless if the name and the id can has different color, but who knows. Big Grin

]]> <![CDATA[Random Number]]> https://g1r-mp.com/forum/showthread.php?tid=54 Sun, 13 Sep 2026 17:04:38 +0000 Xardas0327]]> https://g1r-mp.com/forum/showthread.php?tid=54
For example:

Quote:getRandomInt(includeMinInt, excludeMaxInt) -- Maybe it also should be fine if the top number is include too.

and

Quote:getRandomFloat (includeMinFloat, includeMaxFloat ) -- The top number should be included here.

Note:
I tried to use this code. But if I use this code, the server drop my character and the server reconnected it. (even on 0.1.3)
Moreover, this is not true random. I should use something similar like this math.randomseed(os.time()), but the os is not available from 0.1.3.

Quote:local startPositions = {
{ x = 1116.75, y = -1007.51, z = -36.66 },
{ x = 1106.01, y = -1049.35, z = -29.86 },
{ x = 1100.28, y = -1050.55, z = -35.44 },
{ x = 1115.40, y = -1049.39, z = -37.10 },
{ x = 1161.29, y = -1050.89, z = -42.04 },
{ x = 1154.55, y = -1011.29, z = -42.16 },
}

addCommandHandler("castle", function(playerId, commandName)
local randomIndex = math.random(1, #startPositions)
setPlayerPosition(
playerId,
startPositions[randomIndex].x,
startPositions[randomIndex].y,
startPositions[randomIndex].z
)
end)

]]>
For example:

Quote:getRandomInt(includeMinInt, excludeMaxInt) -- Maybe it also should be fine if the top number is include too.

and

Quote:getRandomFloat (includeMinFloat, includeMaxFloat ) -- The top number should be included here.

Quote:local startPositions = {
{ x = 1116.75, y = -1007.51, z = -36.66 },
{ x = 1106.01, y = -1049.35, z = -29.86 },
{ x = 1100.28, y = -1050.55, z = -35.44 },
{ x = 1115.40, y = -1049.39, z = -37.10 },
{ x = 1161.29, y = -1050.89, z = -42.04 },
{ x = 1154.55, y = -1011.29, z = -42.16 },
}

addCommandHandler("castle", function(playerId, commandName)
local randomIndex = math.random(1, #startPositions)
setPlayerPosition(
playerId,
startPositions[randomIndex].x,
startPositions[randomIndex].y,
startPositions[randomIndex].z
)
end)

]]> <![CDATA[Webp format]]> https://g1r-mp.com/forum/showthread.php?tid=52 Wed, 09 Sep 2026 14:10:10 +0000 JoePL]]> https://g1r-mp.com/forum/showthread.php?tid=52 <![CDATA[SpawnItemAt]]> https://g1r-mp.com/forum/showthread.php?tid=49 Sun, 06 Sep 2026 19:08:54 +0000 Chenentano]]> https://g1r-mp.com/forum/showthread.php?tid=49
it would be great if we get a new function to randomize the position of the spawned items

Code:
spawnItemAt(itemKey, x, y, z)

Greetings

]]>
it would be great if we get a new function to randomize the position of the spawned items

Code:
spawnItemAt(itemKey, x, y, z)

Greetings

]]> <![CDATA[# Feature request: per-observer nameplate state]]> https://g1r-mp.com/forum/showthread.php?tid=45 Sun, 06 Sep 2026 12:02:57 +0000 JoePL]]> https://g1r-mp.com/forum/showthread.php?tid=45 # Feature request: per-observer nameplate state

**Target:** G1R:MP scripting API (server-side)
**Requested by:** Eldoria RolePlay
**Verified against:** documentation dump 1.2.1 / platform update 0.1.2
**Status of workarounds:** all known alternatives verified and ruled out (§4)

---

## 1. What we are trying to build

A **stranger system**: a roleplay server where a character's name is not public
knowledge. You do not know who someone is until they tell you.

- Two players who have never met see each other as `Nieznajomy (147)`
("Stranger #147") — a stable per-character number, not a name.
- After an in-character introduction (`/przedstaw`), each side learns the
other's real name **permanently**, and only for themselves.
- The relation is directional and per-pair: A knowing B says nothing about
whether C knows B.

The chat side of this already works — we send chat messages per recipient, so
each observer can be given a different sender label.

**The overhead nameplate is the only thing we cannot do**, and it defeats the
whole feature: the name floats above the character's head for everyone
regardless of what the observer has learned.

---

## 2. What we are asking for

### 2.1 Preferred: per-observer nameplate text

Code:
bool setPlayerNameplateTextFor(int observerId, int targetId, string text)

Code:
bool resetPlayerNameplateTextFor(int observerId, int targetId)

Code:
string|false getPlayerNameplateTextFor(int observerId, int targetId)

Sets the nameplate text that **`observerId` sees above `targetId`**, overriding
the global value set by `setPlayerNameplateText`.

### 2.2 Minimal acceptable: per-observer nameplate visibility

If per-observer text is too invasive, a per-observer **visibility** toggle is
enough to unblock us:

Code:
bool setPlayerNameplateVisibleFor(int observerId, int targetId, bool visible)

Code:
bool resetPlayerNameplateVisibleFor(int observerId, int targetId)

We would then keep the global nameplate text as the character's **real name**
and hide it from observers who have not been introduced. Strangers see no
nameplate at all; the `Nieznajomy (147)` label is carried by chat only.

This is strictly smaller than 2.1 and reuses state the engine already
replicates. **Either one unblocks the feature — we do not need both.**

---

## 3. Semantics we need

These apply to both variants.

| Aspect | Required behaviour |
| --- | --- |
| **Precedence** | The per-observer value overrides the global one. With no override present, the observer sees exactly what `setPlayerNameplateText` / `setPlayerNameplateVisible` set. |
| **Default** | No overrides exist. Current behaviour is unchanged for every resource that does not call the new functions. |
| **Direction** | Strictly one-way. `setPlayerNameplateTextFor(A, B, ...)` must not affect what B sees above A. |
| **Replication** | Same guarantees as the existing nameplate state: reliable, server-authoritative, **replayed on relevance entry and late join**. Without this, an override silently disappears when the pair walks apart and back together. |
| **Lifetime** | Cleared automatically when **either** player disconnects. Player ids are reused; a leftover override would show one player's name above a different player. This is the single most important requirement in the table. |
| **Ownership** | Same model as other 0.1.2 state: only the creating resource may set or clear its overrides; they are removed when that resource stops. |
| **Return value** | `bool`, consistent with the other setters, so a rejection is detectable. Returning `true` on a no-op repeat is fine. |
| **Validation** | Same text rules as `setPlayerNameplateText` (48 code points / 96 UTF-8 bytes, control characters and HTML delimiters rejected). |

### Cost profile — why this should be cheap

Overrides change **only when two characters are introduced**, not per frame and
not per tick. In practice that is a handful of calls per player per session.

The natural shape is a sparse map keyed by `(observerId, targetId)`, replicated
only to the one observer. There is no per-frame work and no broadcast: the
delta goes to a single client.

---

## 4. Alternatives we tested and ruled out

We checked these against the 1.2.1 documentation before filing. Listing them so
the same ground is not covered twice.

**`setPlayerNameplateText`** — one value for everyone.
> *"Changes a player's server-authoritative overhead nameplate text."*

**`setPlayerNameplateVisible`** — global, explicitly so.
> *"Shows or hides a player's overhead nameplate **for all observers**."*

**`setPlayerNametagText` / `setPlayerNametagShowing`** — not a separate channel.
> *"Compatibility alias for `setPlayerNameplateText`."*

**`create3DText` with a viewer filter** — would not scale even if `options`
supported one (today it accepts only `drawDistance`, `scale` and `r/g/b/a`).

Overhead labels need one label per **(observer, target)** pair. Twenty players
standing together is 20 × 19 = 380 labels; the documented limits are **256 per
resource and 2048 server-wide**, and `serverconf.cfg` allows 500 slots. The
cap is exhausted by a single crowded camp.

*(A `visibleTo` filter on `create3DText` would still be useful for other things
— private quest markers, per-player hints — but it does not solve this.)*

**Client-side rendering** — not possible. The client API exposes only
`setCameraTarget` and `resetCamera`; there is no world-to-screen projection and
no world-space drawing, so a client cannot position labels itself.

---

## 5. Acceptance scenarios

Concrete cases we would test against.

1. **Baseline unchanged.** A resource that never calls the new functions
behaves exactly as today.
2. **One-way override.** `setPlayerNameplateTextFor(A, B, "Gorn")` → A sees
`Gorn` above B; C still sees the global text; B's view of A is unaffected.
3. **Survives distance.** A and B walk out of relevance range and back. A still
sees `Gorn`.
4. **Survives reconnect of the observer.** A reconnects; A still sees `Gorn`
above B *(assuming the resource re-applies it — see 6)*.
5. **Id reuse is safe.** B disconnects, a different player joins and receives
B's old player id. A must **not** see `Gorn` above the new player.
6. **Reset.** `resetPlayerNameplateTextFor(A, B)` → A falls back to the global
text, not to an empty plate.
7. **Rejection is visible.** Invalid text, unknown player id or a target owned
by another resource returns `false`.

---

## 6. What we do if this is not available

We hide overhead nameplates for **everyone** (`setPlayerNameplateVisible(id,
false)` for all players) and carry identity through chat alone.

This is consistent — nobody ever sees a name that contradicts what they know —
but it removes a piece of information the engine already renders well, and it
means players cannot identify even their own friends at a glance. We would
rather not do that, hence this request.

---

## 7. Summary

One capability is missing: **the nameplate state cannot be varied per
observer.**

- Smallest change that unblocks us: `setPlayerNameplateVisibleFor`.
- Better result for players: `setPlayerNameplateTextFor` (+ `reset…`).
- Everything else on our side is built and waiting: the `acquaintances` table,
the per-pair lookup, the in-character introduction command and the config
switch that turns it all on.]]> # Feature request: per-observer nameplate state

**Target:** G1R:MP scripting API (server-side)
**Requested by:** Eldoria RolePlay
**Verified against:** documentation dump 1.2.1 / platform update 0.1.2
**Status of workarounds:** all known alternatives verified and ruled out (§4)

---

## 1. What we are trying to build

A **stranger system**: a roleplay server where a character's name is not public
knowledge. You do not know who someone is until they tell you.

- Two players who have never met see each other as `Nieznajomy (147)`
("Stranger #147") — a stable per-character number, not a name.
- After an in-character introduction (`/przedstaw`), each side learns the
other's real name **permanently**, and only for themselves.
- The relation is directional and per-pair: A knowing B says nothing about
whether C knows B.

The chat side of this already works — we send chat messages per recipient, so
each observer can be given a different sender label.

**The overhead nameplate is the only thing we cannot do**, and it defeats the
whole feature: the name floats above the character's head for everyone
regardless of what the observer has learned.

---

## 2. What we are asking for

### 2.1 Preferred: per-observer nameplate text

Code:
bool setPlayerNameplateTextFor(int observerId, int targetId, string text)

Code:
bool resetPlayerNameplateTextFor(int observerId, int targetId)

Code:
string|false getPlayerNameplateTextFor(int observerId, int targetId)

Code:
bool setPlayerNameplateVisibleFor(int observerId, int targetId, bool visible)

Code:
bool resetPlayerNameplateVisibleFor(int observerId, int targetId)

We would then keep the global nameplate text as the character's **real name**
and hide it from observers who have not been introduced. Strangers see no
nameplate at all; the `Nieznajomy (147)` label is carried by chat only.

This is strictly smaller than 2.1 and reuses state the engine already
replicates. **Either one unblocks the feature — we do not need both.**

---

## 3. Semantics we need

These apply to both variants.

| Aspect | Required behaviour |
| --- | --- |
| **Precedence** | The per-observer value overrides the global one. With no override present, the observer sees exactly what `setPlayerNameplateText` / `setPlayerNameplateVisible` set. |
| **Default** | No overrides exist. Current behaviour is unchanged for every resource that does not call the new functions. |
| **Direction** | Strictly one-way. `setPlayerNameplateTextFor(A, B, ...)` must not affect what B sees above A. |
| **Replication** | Same guarantees as the existing nameplate state: reliable, server-authoritative, **replayed on relevance entry and late join**. Without this, an override silently disappears when the pair walks apart and back together. |
| **Lifetime** | Cleared automatically when **either** player disconnects. Player ids are reused; a leftover override would show one player's name above a different player. This is the single most important requirement in the table. |
| **Ownership** | Same model as other 0.1.2 state: only the creating resource may set or clear its overrides; they are removed when that resource stops. |
| **Return value** | `bool`, consistent with the other setters, so a rejection is detectable. Returning `true` on a no-op repeat is fine. |
| **Validation** | Same text rules as `setPlayerNameplateText` (48 code points / 96 UTF-8 bytes, control characters and HTML delimiters rejected). |

### Cost profile — why this should be cheap

Overrides change **only when two characters are introduced**, not per frame and
not per tick. In practice that is a handful of calls per player per session.

The natural shape is a sparse map keyed by `(observerId, targetId)`, replicated
only to the one observer. There is no per-frame work and no broadcast: the
delta goes to a single client.

---

## 4. Alternatives we tested and ruled out

We checked these against the 1.2.1 documentation before filing. Listing them so
the same ground is not covered twice.

**`setPlayerNameplateText`** — one value for everyone.
> *"Changes a player's server-authoritative overhead nameplate text."*

**`setPlayerNameplateVisible`** — global, explicitly so.
> *"Shows or hides a player's overhead nameplate **for all observers**."*

**`setPlayerNametagText` / `setPlayerNametagShowing`** — not a separate channel.
> *"Compatibility alias for `setPlayerNameplateText`."*

**`create3DText` with a viewer filter** — would not scale even if `options`
supported one (today it accepts only `drawDistance`, `scale` and `r/g/b/a`).

Overhead labels need one label per **(observer, target)** pair. Twenty players
standing together is 20 × 19 = 380 labels; the documented limits are **256 per
resource and 2048 server-wide**, and `serverconf.cfg` allows 500 slots. The
cap is exhausted by a single crowded camp.

*(A `visibleTo` filter on `create3DText` would still be useful for other things
— private quest markers, per-player hints — but it does not solve this.)*

**Client-side rendering** — not possible. The client API exposes only
`setCameraTarget` and `resetCamera`; there is no world-to-screen projection and
no world-space drawing, so a client cannot position labels itself.

---

## 5. Acceptance scenarios

Concrete cases we would test against.

1. **Baseline unchanged.** A resource that never calls the new functions
behaves exactly as today.
2. **One-way override.** `setPlayerNameplateTextFor(A, B, "Gorn")` → A sees
`Gorn` above B; C still sees the global text; B's view of A is unaffected.
3. **Survives distance.** A and B walk out of relevance range and back. A still
sees `Gorn`.
4. **Survives reconnect of the observer.** A reconnects; A still sees `Gorn`
above B *(assuming the resource re-applies it — see 6)*.
5. **Id reuse is safe.** B disconnects, a different player joins and receives
B's old player id. A must **not** see `Gorn` above the new player.
6. **Reset.** `resetPlayerNameplateTextFor(A, B)` → A falls back to the global
text, not to an empty plate.
7. **Rejection is visible.** Invalid text, unknown player id or a target owned
by another resource returns `false`.

---

## 6. What we do if this is not available

We hide overhead nameplates for **everyone** (`setPlayerNameplateVisible(id,
false)` for all players) and carry identity through chat alone.

This is consistent — nobody ever sees a name that contradicts what they know —
but it removes a piece of information the engine already renders well, and it
means players cannot identify even their own friends at a glance. We would
rather not do that, hence this request.

---

## 7. Summary

One capability is missing: **the nameplate state cannot be varied per
observer.**

- Smallest change that unblocks us: `setPlayerNameplateVisibleFor`.
- Better result for players: `setPlayerNameplateTextFor` (+ `reset…`).
- Everything else on our side is built and waiting: the `acquaintances` table,
the per-pair lookup, the in-character introduction command and the config
switch that turns it all on.]]> <![CDATA[Soundfiles]]> https://g1r-mp.com/forum/showthread.php?tid=43 Fri, 04 Sep 2026 13:27:45 +0000 Chenentano]]> https://g1r-mp.com/forum/showthread.php?tid=43 ,

it would be great, if you can implement soundfiles.

onPlayerConnect() -> useSoundFile()

Greetings]]> ,

it would be great, if you can implement soundfiles.

onPlayerConnect() -> useSoundFile()

Greetings]]>