Suggestions

Would it be possible to have a way to execute a vanilla command inside a custom one, sort of like the super() action in SOC?


This would be amazing for custom scripts that for example require permissions, for example "ban 5" could first run a check for Terminal permissions if used by a Terminal admin that isn't the host/admin, and if the check is successful then write to the host console; if the player typing it were the host it would call its normal command.


Or "name Sonic" could run a check to see if the player is not muted by a custom script and only then allow players to change their name.


Or many many many other things....
Yes, but you can do this with Lua.

Actually, yes and no.
Yeah, you can go ahead and make a new command, but it would be more accessible if you could just put your cool command on top of an existing one and still call the original command whenever applicable. (EDIT: Thinking about the "name" example, it would be useful to somewhat counter name scripts?)
Nowadays, if you override a command such as "ban", you are no longer able to ban people due to you overriding the command that writes the ban to a file along with pushing the victim off the server.

The ability to call the vanilla variant of an overriden command would be neat, but it would cause problems if multiple scripts were to have different features, people wanted to use both and it happened that the script authors overrode the same commands.
EDIT: But on the other hand, what are the chances?

Or "name Sonic" could run a check to see if the player is not muted by a custom script and only then allow players to change their name.
You already can't change your name while the server has mute enabled. In fact, joiners are stuck with the default "Player #" name.
 
Last edited:
A version of rope hangs that does not need way points, and an alternate version for dynamic rope hangs to allow for stuff like moving ropes or Mystic Cave's hanging vines that lower players.
 
Support for True-color .png 32 bit textures, tired of dealing with the limited color palette and having to convert the textures, and update the power of 2 restriction on FLATs so that we can freely apply textures of any sizes on planes, also let us apply wall textures on planes and vise-versa.

NAT hole punching?

lol
 
Last edited:
I don't know if this is already in the cards or not, but can you guys add a variable toggle for the character header / mobj which keeps the player character facing forward in platformer game modes? For instance: if a custom character is supposed to be able to shoot projectiles in single player, then the designer will likely want to control which direction the character is facing at any given moment.
 
I don't know if this is already in the cards or not, but can you guys add a variable toggle for the character header / mobj which keeps the player character facing forward in platformer game modes? For instance: if a custom character is supposed to be able to shoot projectiles in single player, then the designer will likely want to control which direction the character is facing at any given moment.

I'm assuming you're talking about the new system for player angling in 2.2. Unless it's been changed since I learnt of this, I'm fairly certain the angle the player faces is a separate variable from the traditional mo.angle—you'll most likely be able to force it to mo.angle's value at any or all times.
 
The above is correct. It is known as "player.drawangle".

As an interesting aside, and to make my post not a complete waste of time, Kart has ALSO implemented an identical decoupling of angle for spinout purposes under the name "player.frameangle". I found it pretty funny, and I figure yall's might too.
 
My suggestions are simple; Add HUD hooks other than "game" and "scores", specifically one that runs during intermission screens ("intermission") and ones that run in certain menus ("title", "options", "servers", "multiplayer", etc.). Along with this I'd like to see some more options for hud.enable and hud.disable in menus (like menu items), and more font options for the hud, like the large nights numbers, if possible the header font for menus, and if possible the main score/time/rings hud font.
 
Very unimportant suggestion: For version 2.2, have more things be based on TICRATE in some way. For example, rather than a speed of 10, have a speed of 350/TICRATE, and rather than a state duration of 5, have a state duration of 0.15f*TICRATE... or something like that.

Preferably (in my own opinion) at least have this affect things that would be set up in levels (like linedef lengths and texture offsets), even if you leave the rest of the game code alone.

Of course, this is a very, very "boring" and "impactless" thing on its own that may cause a lot of trouble and headaches and such (and thus I both doubt that it'll happen and can understand if it won't), but it could help make the game a little easier for modders to change the framerate of, as then people wouldn't also necessarily have to change level files in some way for levels that use certain effects.
Plus, while yes, you could multiply 36 (Sonic's normalspeed) by 35 (the current TICRATE) in a calculator to know that Sonic can run 1260 FRACUNITs per second, simply seeing "1260/TICRATE" would make one know that fact without having to multiply anything manually. (Not that that would matter much regardless, though.)
 
I personally don't agree with that suggestion, it's just asking for trouble anyone involved. What about Lua scripts, this would be breaking compatibility for something that no one would get gain out of. Not to metions floats would be involved, which is inaccurate and that's why the game don't use floats, but fixed integers.
 
Last edited:
I personally don't agree with that suggestion, it's just asking for trouble anyone involved. -
I know. Like I said, I doubt that it'll get implemented at all, and I understand if it won't, but there (hopefully) can't be any harm in suggesting it.

- What about Lua scripts, this would be breaking compatibility -
Not necessarily. I'm suggesting for it to be implemented on the definition side of things (e.g. a character's "normalspeed" value being hard-multiplied by 35 and divided by TICRATE in the definition), not usage (e.g. specifically not "mobj.x+=mobj.momx*35/TICRATE"), which means that "35" is the same as "1*TICRATE" and "1" is the same as "35/TICRATE", meaning that any values in Lua stuff or such that doesn't use TICRATE will act the same as before (as well as act the same as if it was changed to use TICRATE appropriately, except that in the latter case it'll support different TICRATEs better).

As an example, let's say that a Lua script sets a speed of 36*FRACUNIT in 2.1. If it was to be changed to 1260*FRACUNIT/TICRATE (or better yet, (1260*FRACUNIT)/TICRATE) for this hypothetical 2.2, it'd result in 36*FRACUNIT (if TICRATE is 35). If it was left unchanged, it would still just be 36*FRACUNIT, which is the same value.

It will definitely break compatibility with in-level stuff if linedef lengths or texture offsets are important for effects, however, but I expect 2.1 levels to be incompatible with 2.2 anyway. (I know that that's not a completely valid argument for breaking support for stuff, but I still think that that's an ever so slightly valid argument.)

- for something that no one would get gain out of. -
There have been past attempts at making SRB2 run at higher framerates than 35 (like 60 or even 144), met with some trouble due to most of SRB2 being hardcoded to expect TICRATE being 35 (rather than being hardcoded to take TICRATE into account). Having SRB2 support "variable" TICRATEs "natively" (especially at least in level data) would make such a feat much easier to accomplish. Not simply easy, of course, just somewhat easier than having to change all values (especially ones that are part of levels).

I'm not saying that version 2.2 of SRB2 should be 60FPS or such, but it would be sort of nice if some "groundwork" for that was slowly done, version by version, to possibly allow such a thing in far-future official versions, as well as not-quite-as-far unofficial versions.

- Not to me tions floats would be involved, which is inaccurate and that's why the game don't use floats, but fixed integers.
Trust me, I dislike floats greatly for that kind of reason. So while yes, a state duration of "0.15f*TICRATE" may seem like a float, I still want the result of it to be saved as an integer, it's just hard to write fractional numbers without using floats in the calculation itself. An alternative approach would be "(15*TICRATE)/100", but that just looks a bit messier to me.
 
There is already a mostly working branch for 2.2 that runs at 70 or 140 fps. Instead of doing it like that, though, it works by leaving most game logic at 35 fps and only changing the parts that matter. (For instance, who cares if Crawlas move every frame?)
 
Unrelated, but speaking of Crawlas, I would love to see them and other enemies use a new A_Chase, because unless that was already changed, the current one honestly makes things limited and janky, they can only move in 8 directions, and any speed higher than that of a red crawla makes them visually teleport ontop of already not having any momentum whatsoever (Cybrakdemon is a good exemple of that)
 
We have controls specifically for custom Lua actions, being Custom 1/2/3. However, these controls occasionally overlap between mods (Example: TauntVoices uses Custom 2 for taunting with most characters, but a few taunt with Toss Flag instead as Custom 2 is already in use by those characters), and some mods may be well-suited for some Custom control layouts while others may be well-suited for other layouts.

What sort of chance and possibility is there of allowing custom Lua scripts to add their own controls that can be re-mapped at will and can overlap with any other controls (since overlaps might be wanted in some cases), which SRB2 will then also save and remember between game sessions (even if the WAD isn't loaded for several game sessions in a row)?


For example, perhaps something like AddControl("LIGHTDASH","Ring Lightdash","E",nil) would add a variable to all players called BT_LUA_LIGHTDASH, which returns if the button is pressed or not, with the control being added in the options menu under the displayed name "Ring Lightdash", with the default control being set to E if a "lua_lightdash" setcontrol is not found in a configuration file for the WAD file.

The above AddControl's parameters are in order the internal name (uppercase with "BT_LUA_" added in front for the variable name, lowercase with "lua_" in front for setcontrol), display name (used in the options menu controls list), and default key 1 and 2 (for the first time that the WAD is loaded).
The second split-screen player's controls for it would always be blank (because making mod makers supply default keys for player 2 may cause even more conflicts with players' existing control layouts than just for player 1).

Mod developers would have to take care to avoid the same internal name being used by multiple mods, but that may in many cases be as simple as adding a character/mod name in front of the internal (and display) name.


Implementation-wise... I really don't know, but probably something involving looking for the AddControl function thing in Lua scripts when loaded, taking them into account if they exist, and of course getting rid of them for the "handling" of what the Lua script should do and such in-game.

I understand that this may be really hard, but I personally think that it's worth at least thinking about for a bit.
 
We have controls specifically for custom Lua actions, being Custom 1/2/3. However, these controls occasionally overlap between mods (Example: TauntVoices uses Custom 2 for taunting with most characters, but a few taunt with Toss Flag instead as Custom 2 is already in use by those characters), and some mods may be well-suited for some Custom control layouts while others may be well-suited for other layouts.

What sort of chance and possibility is there of allowing custom Lua scripts to add their own controls that can be re-mapped at will and can overlap with any other controls (since overlaps might be wanted in some cases), which SRB2 will then also save and remember between game sessions (even if the WAD isn't loaded for several game sessions in a row)?


For example, perhaps something like AddControl("LIGHTDASH","Ring Lightdash","E",nil) would add a variable to all players called BT_LUA_LIGHTDASH, which returns if the button is pressed or not, with the control being added in the options menu under the displayed name "Ring Lightdash", with the default control being set to E if a "lua_lightdash" setcontrol is not found in a configuration file for the WAD file.

The above AddControl's parameters are in order the internal name (uppercase with "BT_LUA_" added in front for the variable name, lowercase with "lua_" in front for setcontrol), display name (used in the options menu controls list), and default key 1 and 2 (for the first time that the WAD is loaded).
The second split-screen player's controls for it would always be blank (because making mod makers supply default keys for player 2 may cause even more conflicts with players' existing control layouts than just for player 1).

Mod developers would have to take care to avoid the same internal name being used by multiple mods, but that may in many cases be as simple as adding a character/mod name in front of the internal (and display) name.


Implementation-wise... I really don't know, but probably something involving looking for the AddControl function thing in Lua scripts when loaded, taking them into account if they exist, and of course getting rid of them for the "handling" of what the Lua script should do and such in-game.

I understand that this may be really hard, but I personally think that it's worth at least thinking about for a bit.
That would be a cool idea, but the menu code would need a rewrite I think.
 
a track for silence or a "null" music choice that doesn't spam the console.


Edit: to be more clear, this would be for the change music linedef action.
 
Last edited:
Here's a neat idea that I think should be in SRB2: One-way FOFs. By one-way FOFs, I mean FOFs that can only be passed through one side (similar to "Intangible from top/bottom," but for a side.) Maybe also supply a Thing for the direction (in case of certain terrain forms, like triangles, ellipses, or octagons) and have it taggable. Also, would you be able to make Things taggable, sort of like the Slope Vertexes?
 
This isn't exactly a suggestion, but is there any chance that SRB2 could be ported to a different engine in a distant future?
 

Who is viewing this thread (Total: 3, Members: 0, Guests: 3)

Back
Top