G1R:MP Forum - G1 Remake Multiplayer Community - Suggestions

Cancellable pre-action hooks for custom resources

Thu, 17 Sep 2026 16:02:48 +0000

Hi!

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?

Instances / Virtual Worlds

Thu, 17 Sep 2026 15:58:47 +0000

Hi!

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?

Object placement previews and editing API

Thu, 17 Sep 2026 15:55:56 +0000

Hi!

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!

mouse handler and equip weapon fix

Thu, 17 Sep 2026 10:31:45 +0000

- add handling mouse movements
- setplayerweapon function adding properly only melee weapons but not ranged

[Feature request] IsPlayerCombatMode

Tue, 15 Sep 2026 17:40:36 +0000

Hey,

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.

Nameplate Color

Sun, 13 Sep 2026 17:14:36 +0000

It would be useful, if we can change the nameplates' color.
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.

Random Number

Sun, 13 Sep 2026 17:04:38 +0000

It would be good if we have random number generator.

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)

Webp format

Wed, 09 Sep 2026 14:10:10 +0000

Would it be possible to add support for the **WebP format to RMLUI**? This would be very useful for textures and UI icons, as WebP allows for significantly smaller file sizes while maintaining good quality. Ideally, it would work similarly to the current support for PNG/JPG.

SpawnItemAt

Sun, 06 Sep 2026 19:08:54 +0000

Hey,

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

# Feature request: per-observer nameplate state

Sun, 06 Sep 2026 12:02:57 +0000

# 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.

Soundfiles

Fri, 04 Sep 2026 13:27:45 +0000

Hey ,

it would be great, if you can implement soundfiles.

onPlayerConnect() -> useSoundFile()

Greetings

Feedback & Suggestions After the Release

Sun, 30 Aug 2026 14:50:25 +0000

So, I’ve been testing it since the release, and honestly, it’s a really impressive piece of work. You can definitely see that it’s still in its early stages, but I have to give a big shout-out to everyone working on it. It’s already looking very promising.

With that said, here are a few ideas / things I would personally find useful — and I don’t think I’m the only one.

My suggestions / needs:

- Ability to place objects in the world
For example, placing a sword or another item on the ground, on a table, etc.

- Some way to track `equip` / `unequip` interactions
Something similar to `onPlayerJoin` or other events would be extremely useful. This could allow us to prevent certain items from automatically being equipped from the inventory when a player joins the game — although I assume something like this may already be in work.
Alternatively, it could be useful to have some kind of client/server native or event that sends something like:
`interaction("equip")`
This would allow developers to listen for and log these interactions themselves.
It’s also possible that something like this already exists and I simply missed it on the wiki.

- NPC clothing / skins
I’m having some trouble properly applying clothing or skins to NPCs. It’s entirely possible that I’m doing something wrong.
However, since weapons are working perfectly fine for me, I’m not entirely sure if that’s the case.

- Spawn IDs on the wiki
I think it would be really useful to have a list of spawn IDs on the wiki — for things like armor, weapons, and other usable objects. Having these documented in one place would make development much easier.

I think these features would provide a really solid foundation for building more advanced systems on top of this.
Of course, I completely understand that this is the **first release and still an alpha**, so I’m not expecting everything to be available right away.
I mainly wanted to share some feedback and ideas based on what I’ve tried so far.

And once again, huge respect to everyone working on this. It’s already a great piece of work, and I’m looking forward to seeing where it goes. <3

Monster combat

Sun, 30 Aug 2026 10:02:13 +0000

Feature suggestions for monsters:

1. commandMonsterAttack(monsterId) - a command that makes the monster perform an attack, so the server can tell it to strike when it is in range of its target.

2. Stopping distance at the target. The monster should stop at the attack range of its species instead of running into the player and passing through them.

3. walkMonsterTo(monsterId, x, y, z) - moving a monster to a point. NPCs have routes, monsters can only chase or be teleported. This would make it possible to recreate the pack circling behaviour from the single player.

4. Raising a monster's maximum health. Right now setMonsterHealth silently clamps the value to the template maximum and still returns true. This is needed for elite monsters and bosses.

5. Collision between monsters, so groups stop walking into each other and "levitating".

PlayerDimension

Wed, 26 Aug 2026 09:29:28 +0000

Hey,

it would be great to create new dimension for players.

Good examples:
Register -> Char creation -> createNewDimension -> deleteAfterCreation (anti-overlap)
Instanced Arena PvP
Dungeons/Raids

If its possible already and ive overlooked it, flame me pls.

Greetings

Chen