Suggestions

So LUA lets you change a lot of flags and S_SKIN values with the Player_T lib, but for some reason it doesn't have startcolor as an interchangeable option. There'd be a lot of cool things possible if you could decide what colors to change under seperate conditions.

IN fact, even BETTER would be if this could be implemented for not just characters, but for general mobjs as well! It... seriously can't be that hard to do, and would eliminate the need for buggy sprite "over-layering" like we've seen some wads do. Anyone else think that's a cool idea? It'd open up a lot more possibilities if you ask me. :P
 
If you ended up changing the startcolor of a sprite, it would cause the original color changing section to be forced to its original color before color change. For example, if you changed the start color on Sonic to the red shades, you would end up being able to change the shoe color... but the rest of the body would be stuck with green.

(Could be some sort of option to edit/add colormaps, though.)
 
Just clearing up the facts here: you can't modify the actual S_SKIN stats for a skin. player_t has copies of some of the S_SKIN stats, yes, and startcolor is not one of them.
 
Speaking of startcolor, why don't we just add in an optional startcolor2 to the S_SKIN? This could help with making characters change colors with the fireflower and not look so ugly, or help get rid of sonic and tails' ugly grey pixels.
 
Last edited:
Suggestion: how 'bout the inclusion of a "portal render depth" option into the video menu (like in Portal itself)? That way those of us with nothing better to do with our CPU time can render portals to infinity and those who need every ounce for gameplay can set it to like 3 or so. (I want my mirrors like Red's demo shot)
 
Alright, got two suggestions.

Somehow, make it possible to apply another colormap to a sprite that already has a colormap applied to it: (for instance, applying an eggman style flash to a sprite that has already had its color changed.) (or perhaps before, even.)

Another suggestion would be some method to switch out graphical patches that individual players can see: For instance, displaying arrows over the members of your team in CTF, while managing to avoid the opposing team from viewing it. (and perhaps showing alternative "sprites" when GR_MD2 is on.)
 
Suggestion: how 'bout the inclusion of a "portal render depth" option into the video menu (like in Portal itself)? That way those of us with nothing better to do with our CPU time can render portals to infinity and those who need every ounce for gameplay can set it to like 3 or so. (I want my mirrors like Red's demo shot)
The MAXPORTALS console var exists for adjusting that, but it wasn't added in the options menu because 1) no vanilla content uses portals, and 2) it's a rather advanced video option, and cranking it up too far can and has caused me memory overflows.
 
It would be good if maximum nested portals could be set per-portal (and the colour/texture for the portal in the final nested render could be set to something other than black). Of course, this would be in conjunction with MAXPORTALS to limit the maximum number regardless of what the map says; a boolean FORCEMAXPORTALS would be great too for weirdos who want to see their computer catch fire.
 
It has nothing related with previous posts but meh, I'd suggest the option of not loosing emeralds upon restarting a SP map!
It's frustrating to finally have the 7, and having to restart because Mr. SynchFail joins the game and keep joining it even if he knows he causes synch fails! So we have to restart the map, and loose all our precious emeralds. I cry everytime to this story.
 
I'd suggest the option of not losing emeralds upon restarting a SP map!
It's frustrating to finally have the 7, and having to restart because Mr. Synch-Fail joins the game and keep joining it even if he knows he causes synch fails! So we have to restart the map, and lose all our precious emeralds, just to let Mr. Synch-Fail join our game.

Well, I'm sure there's a reason for why that's so...

But, I do agree... I can't come up with anything as to why you lose all 7 emeralds upon restarting.
It's not like you can gain anything if you restart a map and still keep the 7 emeralds in hand.

In fact, it would relieve a lot of stress on players that want to keep the 7 emeralds instead of obtaining them again through the NIGHT's stages (which are more tedious then the 2.0 Special Stage levels).
I'd like a reply on why this is so.
 
I don't know if this a suggestion, but I personally think the super forms should be able to glow in dark areas in the next version. Right now, they're blending in the shadows.

srb20001.gif
 
I don't know if this a suggestion, but I personally think the super forms should be able to glow in dark areas in the next version.

Ah, the merits of OGL strike aga—*shot*

HOWEVER since I know little to nothing about how the code works and thus cannot comment, I will still pose a little thing to contemplate on how to maybe make such a thing work:

Ok, so in the regular SRB2 world, there's a basic depth fog for darkened sectors, right? This emanates from the camera and relies on either one of the TRANSxx lumps (though those are explicitly for transparency, I'd assume) or, more likely, the COLORMAP lump to map to palette properly, yes? Either that or there's a blender directly in the software renderer that works magically somehow but I doubt that. Anyway, so what could be done is that, when a "light source" such as a super character is detected, the game grabs its depth from the camera via whatever function grabs pixel depth for the current lighting algorithm, knows that that depth should be full brightness or flashing or whatever, and then simply ramps up and down to that colormap value over a fixed depth range (or a fixed step size, which would probably look better) rather than relying on the normal light value.

In other words:
  1. Game grabs relative depth for light emitter
  2. Game begins to draw rows (floor) and columns (walls) like normal
  3. Each row/col's depth is checked against the ramp for the light's depth
  4. If the ramp for the light's depth has a higher colormap value attached to it, that value is drawn; else the regular value is used

Boom. Cheap lighting in software that would look get progressively terribler the farther from the camera the light was, but if implemented only for super characters (as static light emitters have sectors on their side), it would probably look great.

Also, my suggestion: how about a "removefile xyz.wad" command? The game would unload a mod or reload vanilla content over it while deactivating SOCs/Lua scripts. Great for not having to exit the game everytime one wants to change something.
 
Also, my suggestion: how about a "removefile xyz.wad" command? The game would unload a mod or reload vanilla content over it while deactivating SOCs/Lua scripts. Great for not having to exit the game everytime one wants to change something.

This was previously suggested; the only reason this isn't implemented now is because of the difficulty of removing WAD's after they have been loaded.
 
Also, my suggestion: how about a "removefile xyz.wad" command? The game would unload a mod or reload vanilla content over it while deactivating SOCs/Lua scripts. Great for not having to exit the game everytime one wants to change something.

https://github.com/STJr/SRB2/blob/master/src/doomdef.h#L439

Reverting game state to before a file was added is already difficult; Lua makes this even more so, to the point of being nearly unreasonable. (No, you can't just "deactivate" Lua scripts.)
 

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

Back
Top