How about NAT hole punching? There's already the master server, it'd be perfect to set up for it, making hosting a lot more accessible and easier.
Server connects to MS, getting assigned a port by the OS>MS tells clients not only the IP, but also the port>connections are established

Also, this was already talked about on Discord, but I'm reporting here too for the sake of record.

Exit sector behavior could be changed to toggle a "finished" flag for every player that enters it, just once per map, as opposed to constantly setting player.exiting to above 0 while standing in the sector, instead just setting it once. This would make customizing post-exit behavior with Lua much easier.

__________________
put me back in the simulation immediately you oversized soda machine

What if colormaps were palette / transmaps lumps?
The game would simply use another palette to render what's inside the colormap. The problem with that would be the possibility to have more than 255 colors on-screen, breaking gifs, but on the other hand, this would allow software to render colormaps without eating away all the quality from sprites (this would also possibly make it faster to process since it wouldn't have to approximatively remap colors again), and openGL to render said colormaps in a better way than this ugly ass fog without hair tearing renderer rewrite.
Not only that, but this could allow for some really good looking colormaps, and infinite customization reguarding those.

__________________

Quote:

Originally Posted by Bronydude2k5

If you make me a Sash Lilac wad, I'll make you a sonic sprite hack of any choice.

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.

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.

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?

Quote:

Originally Posted by gregory_house

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.

__________________
Ever tried to start a project until you find out it's too complicated then you abandon it

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.

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.

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.

__________________
Look for either "GoldenTails", "GoldenHedgie", or "GoldenEnchilada" on servers.

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.

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.

Quote:

Originally Posted by Steel Titanium

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

Quote:

Originally Posted by Steel Titanium

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

Quote:

Originally Posted by Steel Titanium

- 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)

__________________

Quote:

Originally Posted by Bronydude2k5

If you make me a Sash Lilac wad, I'll make you a sonic sprite hack of any choice.

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.