Suggestions

Welcome to the SRB2 Suggestions topic. Before you post, there are a few things you should know:

1. We know this is a really large topic spanning over 6 years of posts, but try searching to see if your suggestion has been posted before and see if anything comes up. You don't want to beat a dead horse, after all.
2. Please keep discussion to a minimum. If something is going to involve a detailed and long discussion longer than 30-40 posts, please post in a new topic in SRB2 Discussion.
3. Keep discussion of other's ideas civil. You knew this already, though.

Remember that there is absolutely no guarantee that we'll use anything posted in here. We do read this topic for general opinions of what SRB2 lacks, of course, but no promises.

Some stuff in ZDoom that I think would pwn in SRB2:

• Textures
  In ZDoom, you can use any textures, flats, sprites, internal graphics, or whatever on any surface (flats as wall textures and whatnot). Srb2 has duplicates for wall textures of some flats, but that's bad because you get confuzed between the names (For example, people may need to use GFZROCK on the floor and not know the name of the flat)... This may be hard to program, but it'd definately help.
  
• TX_START and TX_END
  IMGZ patches found between TX_START and TX_END are assumed to be single-patch textures by the same name and are automaticly added and usable. Which means you don't need to use PNAMES and TEXTURE1 every time you wanna make another single-patch texture, making things a lot simpler and easier (and in ZDoom's case, you could also use this as an easier way to make large floor textures). This would be great in SRB2, as it'd allow us to use custom textures in contests, because we don't have to worry about merging everyone's PNAMES and TEXTURE1 lumps and people replacing GFZROCK with their own textures and such.
  
• ACS scripts
  ACS scripts are map-based scripts originally implemented in HeXen, which is C/C++ style and simply uses a bunch of predefined functions to do things. This is the BEHAVIOR lump in ZDoom and Hexen maps, and it's VERY powerful. WadAuthor and DoomBuilder support the editing and compilation of such scripts, but we'd need to convert the maps to Hexen format and somehow make all the line specials into Hexen's action specials and make a new version of the ACS compiler to support them. That is a hella lot of work, I won't make you think I have some magic solution to make it easier, but the power... The power is worth it. To me at least. ACS scripts can do everything linedef executors can do (except for the script-executing linedef exec, which I told graue to make in my quest for such power as this) and then some. You can change line and sector specials mid-game, change the camera to a camera mobj placed somewhere in the map beforehand (of which there are three types: Security cameras, aiming cameras, and moving cameras), spawn objects mid-game at spawnpoints placed beforehand (Anything from enemys to cameras to scenery can be spawned at will), spawn objects at X/Y/Z locations (Which means you can spawn an object directly above a player if you want), change object tags and action specials, execute the effects of certain action specials (You can make a script that damages you, thrusts you upwards, AND spawns an object above you to catch you and apply that to a sector if you want), change lighting effects, fade colors, and just about anything else I've ever wanted to do. (Heck, I made a game of Battleship with it, I doubt you'll have trouble finding a new gametype to make using it or enemy AI programs (See DECORATE below) or anything else programming-wise that you need...)
  
• DECORATE
  This is like DeHackEd/SOC, except it creates things from scratch. It was originally made simply to create new static and animated scenery objects (hence the name), but has grown to be able to create all things mobj. Sure, we have empty slots for the SOCing now, but this system was designed for the most flexible ease of use possible. You can inherit propertys from existing objects to make a new edited version, you can create a new object from scratch and define all its states as well (so no looking for obscure numbers in the source code) and tell it to use any action pointer or action special available (so you could have an enemy that attacks by using ACS scripts and opens a door when it dies. Imagine having an enemy that can cause the floor to collapse into a lava pit when it's mostly dead and sprout wings!)... It would be more useful with ACS scripts then without, as that's one of the few things it can do that DeHackEd and SOC editing can't. The fan community has added to it the ability to create new weapons, and I suppose if you're going through all the trouble of making DECORATE, why not add that too? Who wouldn't mind somebody coming along one day and making a new kind of overpowered weapon ring, eh?

That's all for now. If I remember anything I'd forgotten later, I'll be back... I doubt any of this will even be considered for Srb2, though, other then TX_START and TX_END. Of course, if I could just get ZDoom Srb2 off the ground, we'd already have all this, as well as slopes, mirrors, horizon lines, skyboxes, and all those other fun ZDoom things. ;) We'll see... We'll see...

1.1 needs some more useful console commands:

eval <operator> <numbers or variables>

The purpose of this command is to compute simple or complex math using the prefix notation rather than the infix notation; for example, if I wanted to compute 2+2, I would type:

eval + 2 2

Or if I wanted to compute 2+(3*2):

eval + 2 * 3 2

Now, if I wanted to compute 1+3 something and store it in a variable, I'd do this:

eval = AliasedVariable + 1 3

It's pretty basic and it can't possibly be that hard to implement.

comp <output_type> <operator> <numbers or variables>

This command follows the same concept as "eval" except it works more like a hex calculator. For example, if I wanted to compute 2+2 and I wanted the output to be equal to one byte, I would do this:

comp byte + 2 2

Or, if I wanted to compute 255+255 and I wanted the output to be equal to one word (or two bytes to those not familiar with hacker-lingo), I would type this:

comp word + 255 255

And the output would be FFFF.

stop

The purpose of this command is to force any commands being processed by the console to stop immediately.

dumpmap <filename>

This is especially useful if one wishes to get a dump of a map exactly as it is at the time of dumping; for example, if the player picked up some items and killed one or two enemies, then the map would be modified as such. Maybe not very useful to the newbie player, but could be very useful for developers.

dumpvis <filename>

Useful for dumping what SECTOR numbers, how many THINGs, how many SEGs and how many NODEs are in the player's view at the time of dumping; also, if you guys use this, be sure to include a dump of the player's coordinates on the BLOCKMAP and maybe his offset in REJECT (in hex?) in the exported log file.

dumpthing <thing#> <filename>

Takes the corresponding THING # as it was placed in an editor and dumps it's coordinates and flags in hex into whatever <filename> is. Also more of a developer thing than much else.

envtest <line#> <filename>

Retests the player's polar coordinates against the line set in <line#> and exports the player's distance from that line in X, Y, and "Z" into <filename>. More for developers.

Let me save us all some time with that, SSN.

Darkhaven3 said:

eval <operator> <numbers or variables>

Click to expand...

In ZDOOM.

Darkhaven3 said:

comp <output_type> <operator> <numbers or variables>

Click to expand...

Not in ZDOOM, but variation of eval, so I dunno if it'd be that hard to derive.

Darkhaven3 said:

stop

Click to expand...

Not in ZDOOM, AFAIK.

Darkhaven3 said:

dumpmap <filename>

Click to expand...

In ZDOOM... I think. Dunno if it (or the similar "dumpthings" command) keeps Things or ditches them, but we already have a "writeobjects" command for objectplace, so just use that.

Darkhaven3 said:

dumpvis <filename>

Click to expand...

Not in ZDOOM.

Darkhaven3 said:

dumpthing <thing#> <filename>

Click to expand...

Might be. The command's there, but I'm not sure if the actions are the same.

Darkhaven3 said:

envtest <line#> <filename>

Click to expand...

Not in ZDOOM.

I would prefer we ditch the whole "PLAY" sprite system and go with what I made for SRB2RP. Instead of having PLAYA0, PLAYB0, PLAYC0, etc. for Sonic and whatever you want for custom characters, make it use STNDA0, STNDB0, STNDC0, etc. for standing, WALKA0, WALKB0, WALKC0, etc. for walking, and all that... Then you can have an adjustable amount of frames in any animation, so you can have a 26 frame jumping animation or a 1 frame walking animation or whatever. I programmed it myself and it worked fine, though I failed to get netgames to work with it, which is most of the reason I dropped SRB2RP. I spent days working on it just to break netgames. But if you could get it to work in netgames... You'd never have to worry about breaking character wads again. Because anything you add on would be optional, and you could program in what to replace animations with when one has 0 frames in it. But we wouldn't need to have 180 sprites in every character wad anymore. Thus we would have a lot more people willing to make a lot more character wads. Crappy Sonic 3 ripoffs would spring up from every direction, it'd be great.

Some kind of type-on or fade in/out text options for CECHO would add quite a lot to it. And possibly the ability to use a custom font whom you supply the first few letters of or something. And instead of making the words appear in the exact center of the screen, centering them around 30% of the screen from the top would make it look MUCH better. (Hexen uses 37.5%, though ZDoom only uses that as a default) Yes, I want almost all things from ZDoom to be in SRB2 one way or another, since I can't make ZDoom SRB2.

Also, if you could make the Knuckles bots let you jump on them when they're climbi- ... Oh wait, bots are my job, sorry.

Somehow magically make joystick binds seperate from keyboard binds so you don't have joystick controls overriding keyboard controls X.x
And make it so that you can have the same control assigned to 2 joysticks. So you can have one joystick turn and move forward and backward, while the other joystick turns and looks up and down. I don't really like strafing by joystick in SRB2, though analog control is very wonderful...

This may sound like the stuff from page 5, but it's different. Trust me...

fork exp cmdtru cmdfls

It may look rather funky at first glance, but it's actually quite simple. Here's what it would look like in C: exp: Expression. Thing to evaluate, such as 1+1=2
cmdtru: Aliased command to execute if the expression is true
cmdfls: Aliased command to execute if the expression is false

Consider the following: Or this: The first one should always print out '5 + 5 < 20! Yeah!', and the seccond one will tell you to get more rings if you have less then five. Very usefull.

We also need variables such as $rings, $lives, $score <playernum>, $color <playernum>, $skin <playernum>, $name <playernum>, $playernum <name> $time, $prm1 (the first parameter that makes the equation correct if it is), $prm2 (the second one), $x, $y, $z, $lastthingsaid, $currentlevel... Consider the possibilitys.
You could do something like this:

Fork $skin 1,2,3,4,5,6,7,8,9,10 = tails,knuckles, swichtosonic nothing
alias switchtosonic "changeskin $prm1 sonic"
alias nothing "echo No players were found playing as tails or knuckles."

Also, there should be another gametype called special, which lets you make up your own gametypes. These commands would be useful for it.

Changeskin <playernum> (host only)
Changecolor <playernum> (host only)
Teleport <playernum> <x> <y> <z> (host only)
Gravity <playernum> (host only) ---- Seperate gravity for each player
Globalgravity (host only) -- Works like 1.09 gravity change.
Changescore <playernum> (host only)
Createobject <thingnum> <x distance from you> <y distance from you> <z distance from you> (x and y work by direction)
Deleteobject <thingnum> <x distance from you> <y distance from you>
<z distance from you>
Allowplayertocreateobjects <playernum> (host only)Allowplayertodeleteobjects <playernum> (host only)
Createobjectatplayer <playernum> <x distance away from player> <y distance away from player> <z distance away from player>

It would seem somebody deleted this suggestion in one of the purges, so I'm resuggesting it - Quake-style bindings, like +forward, -back, +jump, +mlook, et cetera. Mostly for use in scripts, really.

A 3rd-person crosshair would be nice.

What i've always hated is that Team match (by color)doesnt show whos on your team. How about you do something like you did in CTF, and have the team you be on show what color team your on pressing Tab, and having your name also show in that color if you get hit, die, or type.
For Player, you could have it be like in a sorta graph format, and theres 3 colums, and on top of each is a sonic spot, a tails one, one for knux, and a blank one for wads (could be oppupied with zim if none are present) and the players name is listed underneath the face.

Admittedly, I haven't checked this for myself, but if it isn't there, add it in.

Music changer linedef executors should have the option to fade out the music currently playing and THEN switch to the other music, instead of just an instant switch.

Something similar to the following might help new users along a bit: When the list server is notified of a new game, it could send a few packets, with a second or so between each, to the machine running the game, on the port that it's running it on. The game, for its part, could CECHO a warning, and maybe a pointer to portforward.com, if it hasn't received any UDP packets from the master server by ten seconds or so after registering with it.

Oooh, ooh, before I forget; Add the possibility of having a set number of lives in match mode, so it efficiantley becomes an 'elimination' mode. That would rule, and at the very least add some much-needed replay value to match. It's already been mined of all interesting playability, so why not? =P

Oh, and Spazzo, nice idea.

You know how it's been suggested before that players have names above their head in netgames? Well how about something like that.. but only in CTF, and you can only see them when they're on your team? Maybe not a name, just an arrow so you know where everyone is. It'd be really helpful if you're trying to find out where your flag holder is.

Maybe the game should come up with a little "YOU MUST HAVE PORT 5029 OPEN TO HOST. IF IT IS NOT OPEN, NO ONE WILL BE ABLE TO JOIN" screen when you select Host Game for the first time.

It would at least help out with people hosting unjoinable servers a small bit.

Server hosts should be able to see a users IP Address upon joining the server.

The BAN command should also work with IP addresses

UNBAN command, for removing a single ban instead of all of them.

I literally need a flag for the Change Music linedef executor, one which waits for the current music to reach the end before playing the new one. Quite basically, I want to do something in the lines of Mystic Mansion (Sonic Heroes), where a different segment of music plays per room, but it won't actually change segments unless the one currently playing reaches the end.

Some sort of pulley object, like the ones in SA1's Red Mountain and a few of the stages in StH. That is, a handle that, when touched, holds the player ala Tails and carries him over a set path. The path could be determined with axis changers or something, and the speed could be determined by angle.

An OpenGL special objects for maps.
(1 x 1 px. things, for example, that give off OGL lights, only visible in OGL mode [things being things in maps]) Ther could be other OGL specials, that's just an example of something that could be done.