Suggestion Title: Interactive Arcade Cabinets
Suggestion Description: Here goes nothing xD
I think I should start this off by admitting that this suggestion is a long-shot, given what it entails. If it instantly gets denied then fair. I think it even getting put on the backburner would be a surprise.
I do believe there is a case to be made for its security and efficacy, though, despite it sounding like a huge risk.
I did some light testing on a local GMod server, and found that setfenv *appears to be* pretty good for safely running Lua code. It didn't even know what "print" was, so I'd say that's a good sign for security.) Added CompileString to the beginning of it, and it still ran safely in a new environment. Realised this was big, came to make a suggestion.
Essentially, players will be given the ability to write their own server-side and client-side logic for arcade cabinets (both of which will require approval by a staff member of appropriate rank), with access to a small API to draw graphics to the screen on the client, and handle inputs and interactions on the server.
API Features:
A small graphics API for the screens, with the ability to draw textures and primitive shapes of varying colours. Probably reminiscent of Garry's Mods own draw library.
Input system, which detects if certain keys are pressed. (Could use enums like FORWARD, BACK, etc, to eliminate input networking.) If this could somehow work with multiple players, that would also be badass.
The player could be queried for if they want to insert some money (with this particular function being subject to a cooldown to prevent the player being spammed), and then the game can act upon the information, based on if it was successful or not.
Vice versa, it could award money to the player based on an amount in the machine, with the cabinet owner able to insert cash for distribution.
If it could freeze control of the player's movement (with a dedicated hotkey to force the game to release control and reset the game it to its start state), that could also be very cool, as it would give the arcade owner the ability to let players control the game with their keyboard.
Players would ideally get access to a simple net library for sending information to any nearby clients. Rate limited to prevent performance issues on the server.
Access to some kind of developer-specific database would be cool - so that cabinet owners can have leaderboards that sync across cabinets - would be good. It would need to be rate-limited 100%.
Cabinets:
Lower-end cabinets are noticeably lower in pixel count, like the 70s and 80s, while higher tier cabinets could give you access to something more akin to modern day cabinets.
Players would have the option to disable the rendering of cabinets, but this also prevents them from being able to interact with them.
Why should this be added?:
- The problem of working with pre-existing chat mechanics essentially becomes non-existent, as players are given an open suite to design interactive games for the cabinet.
- The variety possible with this would cause legal incomes to increase significantly, without detracting from the criminal elements of the server.
- Far less clutter in chat from rolls.
- Another god-tier feature for PERP that sets it apart even further.
- The 3D2D UI stuff that the poker and blackjack tables use maybe could be cannibalized to save time.
- Script approval system could be used for other ideas, like player-made events for example.
- Devs get to flex.
- Damnit I'll write the thing if it gets it added, I just really really want this.
What negatives could this have?:
- Possible security risks if Lua has some loopholes around setfenv. Would need people that know the deep lore about exploits in this game to test it.
- Another line of approvals that would need to be done by people that can verify the code's safety and fairness (not just a 100% guaranteed "you lose!" screen), and would take significantly longer than image approval.
- Possible low-effort games.
- Possible lag, code would need vetting.
- Low net updates would significantly reduce the number of game types possible.
- Clutter of arcade cabinets at hotspots around the map could kill the vibe of PERP.
What problem would this suggestion solve?: Feature rich games for people to play when they're not raiding.
Simple Bazaar pop-up games could become in-depth video games with their own followings throughout the city, maybe even some kind of miniature in-server competitive scenes.
People complaining about lack of legal incomes would have another option.
Code Example:
Serverside
local Character = { --serverside character
Position = 0
}
if (Controllers[1]:WasKeyPressed(Enums.Keys.Forward)) then
Character.Position = Character.Position + 1 --move our character right serverside
Net.Send("SyncPosition", Character.Position) --tell the players around the cabinet this
end
Clientside
local CharacterColor = Color(255,255,255,255) --create one color, reuse
local Character = { --clientside character
Position = 0
}
Net.Listen("SyncPosition", function(new_position)
Character.Position = new_position --players see our character at the new position
end)
function DrawScreen(pixelWidth, pixelHeight)
Draw.Circle(pixelWidth * 0.5 + Character.Position, pixelHeight * 0.5, 16, CharacterColor) --pos_x, pos_y, radius, color
end
(Threw that together quickly, I'm sure the actual API would look far more elegant)
Suggestion Description: Here goes nothing xD
I think I should start this off by admitting that this suggestion is a long-shot, given what it entails. If it instantly gets denied then fair. I think it even getting put on the backburner would be a surprise.
I do believe there is a case to be made for its security and efficacy, though, despite it sounding like a huge risk.
I did some light testing on a local GMod server, and found that setfenv *appears to be* pretty good for safely running Lua code. It didn't even know what "print" was, so I'd say that's a good sign for security.) Added CompileString to the beginning of it, and it still ran safely in a new environment. Realised this was big, came to make a suggestion.
Essentially, players will be given the ability to write their own server-side and client-side logic for arcade cabinets (both of which will require approval by a staff member of appropriate rank), with access to a small API to draw graphics to the screen on the client, and handle inputs and interactions on the server.
API Features:
A small graphics API for the screens, with the ability to draw textures and primitive shapes of varying colours. Probably reminiscent of Garry's Mods own draw library.
Input system, which detects if certain keys are pressed. (Could use enums like FORWARD, BACK, etc, to eliminate input networking.) If this could somehow work with multiple players, that would also be badass.
The player could be queried for if they want to insert some money (with this particular function being subject to a cooldown to prevent the player being spammed), and then the game can act upon the information, based on if it was successful or not.
Vice versa, it could award money to the player based on an amount in the machine, with the cabinet owner able to insert cash for distribution.
If it could freeze control of the player's movement (with a dedicated hotkey to force the game to release control and reset the game it to its start state), that could also be very cool, as it would give the arcade owner the ability to let players control the game with their keyboard.
Players would ideally get access to a simple net library for sending information to any nearby clients. Rate limited to prevent performance issues on the server.
Access to some kind of developer-specific database would be cool - so that cabinet owners can have leaderboards that sync across cabinets - would be good. It would need to be rate-limited 100%.
Cabinets:
Lower-end cabinets are noticeably lower in pixel count, like the 70s and 80s, while higher tier cabinets could give you access to something more akin to modern day cabinets.
Players would have the option to disable the rendering of cabinets, but this also prevents them from being able to interact with them.
Why should this be added?:
- The problem of working with pre-existing chat mechanics essentially becomes non-existent, as players are given an open suite to design interactive games for the cabinet.
- The variety possible with this would cause legal incomes to increase significantly, without detracting from the criminal elements of the server.
- Far less clutter in chat from rolls.
- Another god-tier feature for PERP that sets it apart even further.
- The 3D2D UI stuff that the poker and blackjack tables use maybe could be cannibalized to save time.
- Script approval system could be used for other ideas, like player-made events for example.
- Devs get to flex.
- Damnit I'll write the thing if it gets it added, I just really really want this.
What negatives could this have?:
- Possible security risks if Lua has some loopholes around setfenv. Would need people that know the deep lore about exploits in this game to test it.
- Another line of approvals that would need to be done by people that can verify the code's safety and fairness (not just a 100% guaranteed "you lose!" screen), and would take significantly longer than image approval.
- Possible low-effort games.
- Possible lag, code would need vetting.
- Low net updates would significantly reduce the number of game types possible.
- Clutter of arcade cabinets at hotspots around the map could kill the vibe of PERP.
What problem would this suggestion solve?: Feature rich games for people to play when they're not raiding.
Simple Bazaar pop-up games could become in-depth video games with their own followings throughout the city, maybe even some kind of miniature in-server competitive scenes.
People complaining about lack of legal incomes would have another option.
Code Example:
Serverside
local Character = { --serverside character
Position = 0
}
if (Controllers[1]:WasKeyPressed(Enums.Keys.Forward)) then
Character.Position = Character.Position + 1 --move our character right serverside
Net.Send("SyncPosition", Character.Position) --tell the players around the cabinet this
end
Clientside
local CharacterColor = Color(255,255,255,255) --create one color, reuse
local Character = { --clientside character
Position = 0
}
Net.Listen("SyncPosition", function(new_position)
Character.Position = new_position --players see our character at the new position
end)
function DrawScreen(pixelWidth, pixelHeight)
Draw.Circle(pixelWidth * 0.5 + Character.Position, pixelHeight * 0.5, 16, CharacterColor) --pos_x, pos_y, radius, color
end
(Threw that together quickly, I'm sure the actual API would look far more elegant)
Last edited:
