Game Ideas

The name is self-explanatory

Add a static function that escapes strings, so we can use the native escape outside of database methods This can be usefull for scripters that want to build an ORM that builds queries with string concats

API Design: File("package://MyPackage/Client/File.txt")

Make BaseEntity:IsA support classe names (strings) as first argument, but keep classes/objects tables supported This would be usefull when in some case where you have to search from a classname but don't directly have a reference to the class table e.g: ent:IsA(_G["MyClass"]) would be replaced by ent:IsA("MyClass") which is more elegant

Add lua class Promise to Nanos World to use async context in a better way Example:

Add an option to hide all UI elements from screen (full immersion).

######################### I : Keybind combos Having the ability to bind combos of keys would be very nice for gamemode which have a lot of different binds It'd allow to use a same key for 2 binds, if binded in addition to another key (which would be different in the 2 binds) E.g: In case "RightMouseButton" is used to lock/unlock aim with a weapon, "Alt" + "RightMouseButton" could be used to change the scope type on the weapon ######################### II : Better events / Option A: New InputEvents enums It would be nice to have these following InputEvent enumerators: InputEvent.DoubleClick InputEvent.Continuous In the context of Input.Bind , this would be the behaviour for the new enums: DoubleClick trigger callback function once a double click on the binded key is detected Continuous trigger callback function each tick the binded key is down In the context of the enum used in Input.InputKey : DoubleClick triggers a double click Continuous fakes a press each tick / Option B: Create "Bind Types" to make the keybinds behaviour configurable by the user Makes the client choose how each keybind should be treated, with one of the following options: "Press" "Release" "Double Click" "Continuous" This option will probably bring some side effects tho, like making InputEvent parameter obsolete in Input.Bind I'll also maybe add the need to have the ability to limit which bind types can be used when registering a new bind (same thing for the native keys) ######################### III: Misc. Additionally, it would be nice to have the binding menu support mouse wheel up and mouse wheel down separately (currently all you can do is bind to mouse wheel)

Mainly because it's incredibly faster

Currently there's no way of knowing which key does what in some cases Let's use the "MoveForward" bind as reference; this bind is responsible for 2 different actions (move forward, move backward), what differentiate these actions is the scale of the bind (1.0 for forward, -1.0 for backward) We should have a way to know the scale associated to the bind in Input.GetMappedKeys cause the order of the keys in the table returned by this function depend of the name of the key E.g: if we bind "move forward" to "A", and "move backward" to "B", Input.GetMappedKeys("MoveForward") will return {[1] = "A", [2] = "B"} , but in case we bind forward to "B" and backward to "A" it will still return the same table, so we have no way of knowing which key does what Solutions to this would be either: Return the scale of the key in Input.GetMappedKeys to have a table formatted as {[1] = {key = "A", scale = 1.0}, [2] = {key = "B", scale = -1.0}} or Sort the table relatively to the keybind scale instead of the name of the key used on the bind, so the order will always stay the same no matter the name of the keys

From TomDotBat issue: https://github.com/nanos-world/issues/issues/446 Some developers and server owners have a lot going on in their game which results in major slowdowns. This can be worked around by allowing developers to balance the load on several threads. Expose methods to the scripting environment that allow developers to use multiple threads. This could be achieved with an existing Lua threading library such as: Lanes or Effil. Several adjustments will need to be made to ensure threads are destroyed when a player leaves a game, it also shouldn't be possible to spawn an extreme amount of threads and potentially cause harm to a player's computer. Looking back at how servers on garry's mod perform, they all suffered when too much was going on. Obviously the simple solution is to remove content, but you're losing gameplay features in that case.