Suggestions

A Donation button?

That way we can give you guys money just as thanks for making an awesome game?
(I know it's supposed to be non-profitable, but it's' not like we're being forced to pay for the game or anything so... It could benefit you guys... :D)
 
Last edited:
A Donation button?

That way we can give you guys money just as thanks for making an awesome game?
(I know it's supposed to be non-profitable, but it's' not like we're being forced to pay for the game or anything so... It could benefit you guys... :D)

Them making any money from this game in anyways, could, to my knowledge, result in copyright infringement, so I doubt that would be ever considered.
 
A while back, I had a color script that would not end since it would relaunch at the end. It was terrible, for I was not able to change characters, and all console commands were delayed. Can there be a command that stops scripts, wait time etc?
 
Suggestion:
I'm not sure if I or some else had made this but how cutscenes allowing sounds to be played in them (when I say sounds I mean WAVs). It could add better effects to any cinematic moments that people want to produce.
 
We had fun yesterday.

MSfDkKt.jpg

EAyJdAb.jpg


But it could work better if this game mode were still around:

Ice Hockey: This mode only popped up once in Final Demo 1.08, and was designed for one single stage, Ice Hockey Zone. It was similar to CTF, the objective was to push a snowman onto the goal of the opposing team. Due to a bug, the map was not playable and the mode was subsequently removed.
From: http://wiki.srb2.org/wiki/Gametypes#Outdated_Gametypes

Say, I have two teams, red and blue, and a pushable object. Every time the pushable object is found within the CTF Team Base Sector it scores points and is teleported to the center of the map. The match starts could have a thing flag that defines if the player start is a red or blue team start.
 
Last edited:
But the thing was that when teleporting,a glitch did that when reappearing,the object wasn't pushable anymore. I think it could probably be fixed by setting something so the object is pushable after teleporting though.
 
But the thing was that when teleporting,a glitch did that when reappearing,the object wasn't pushable anymore. I think it could probably be fixed by setting something so the object is pushable after teleporting though.
Could it be that the flag "MF_PUSHABLE" is turned off whenever the thing is respawned?
 
Honestly the object doesn't even need to be respawned, it just needs its momentum killed and position reset to its original spawnpoint. Doesn't even need to go directly to the center of the map. Could probably even be made with a Lua script as of 2.1, just by making the ball check the tag number of the sector it's in or something.
 
Suggestion: Scrap the current Mario Koopa Blast Zone and ask Fawfulfan's permission to replace it with his Pipe Towers Zone (keeping the old name, of course).

As it currently stands, MKBZ is hideous and utterly atrocious in every conceivable way. Unlocking it resembles more of a punishment than it does a reward. It is completely unsalvageable and would need to be remade from scratch to be any good.

Of course, you guys have much better things to do than remake an ancient and trivial bonus level, so it's lucky that Fawfulfan already made a mostly-perfect Mario level that you can replace MKBZ with. It's essentially good as-is without any changes, and it would be a massive improvement.
 
So, now that SOCs are able to use text names, it'd be useful to have an action that executes a script. Also, I say that the CTF maps should be included in the match rotation (they have all the elements for normal match in them after all) and that playing them in team match should make use of CTF's team based spawns and rings.
 
So, now that SOCs are able to use text names, it'd be useful to have an action that executes a script.
There seems to be a bit of confusion here; SOC deals exclusively with numbers, not strings. The text names you're referring to are enumerations, text representations of numbers that get turned back into numbers when SRB2 reads the SOC. The advantage to this over the old system, which you can technically still use, even side-by-side with this one, is that SRB2 figures out what number is being asked for, even if the number for what you want has changed due to a version switch or a certain freeslot being used already.
 
Here's something new: a suggestion of something in 2.1 that should be fixed before 2.1 comes out.

I know, strange indeed, but here me out:

There's been something bugging me about the way the skyboxes are rendered in the preview shots (and in SRB2CB as well)...but I figured it out!

They have too much 'perspectiveness.'

Now, unless you happen to think in the same convoluted way as I do, you ask me, "Metal96, now what the does that even mean?" And rightfully so, it's strange terminology that I have made up to describe a phenomenon I've noticed in the way of 3D visuals, real or not.

I think of 'perspectiveness' as the rate of size change when converting a 3D field to a 2D plane. So, for example, an image with a greater perspectiveness would have more size change, or 'dimensionality,' between the objects in the forefront and those in the back. Less perspectiveness ultimately leads to isometry (think Sonic 3D Blast), where there is no size change between the objects in the forefront and those in the back. This is slightly related to field of view, but not exactly, as, in order to gain isometry in the real world, your field of view would have to be infinitesimal and your distance from the object would have to be infinite, but this of course can be done with the marvels of computer graphics and the human imagination.

Now, something that tends to happen in the real world (or a 3D projection) is that objects lose perspectiveness as they go farther away from the camera; you can see this...well, it's actually easy to do...go run SRB2CB (or SRB2 in OpenGL), and bring down the console, and type the following:

9bjn4Xwl.png


Code:
cam_dist 1024
cam_height 160
gr_fov 15

GtttgoJl.png


We've taken the character farther away from the camera, and then 'zoomed in' on him by decreasing the Field of View (this is why I said it was related to field of view). This in an exaggerated example of what needs to happen to the skyboxes. The objects in them are supposed to be large and far away from the camera, but are small in the map and thus drawn 'normally' with the rest of the graphics slapped on top. This makes it look way out of proportion and kind of strange.

To demonstrate, I have prepared some photos:

6TfjrFTl.jpg


This is my level, in which what is outside the windows will be replaced by skybox, which will be a very large piano.

p7uv9Zal.jpg


This is the skybox rendered with the default system.

fOc7oV0l.jpg


This is the skybox rendered with the new system.

So now I'm gonna put these images together to demonstrate what I mean. Here's it "rendered" in what seems to be the current method:

oXfMXhpl.jpg


And here's what I'm saying to do:

EgY9BOOl.jpg


(please forgive the quick'n'dirty editing)

The first one looks like the piano is looming right outside the window, which is not at all optimal when a map can be far more expansive than just my deck outside the window...Imagine a tree being rendered overtop of this image; the illusion breaks quickly.

The second one looks like shit because it was taken with my potato of a cell phone and then blown up huge could be far more believable if executed correctly, but if you imagine a huge expansive map, such a flattened perspective of the piano would fit right into the background just fine.

Alright, not good examples, but you get the point.

So how does one implement this? By simply changing the perspective equation's coefficiant. So say my function for determining relative size was 100/x, so every 200 mappixels, the size halved. I could change this to 1000/x, so it would take a thousand mappixels for the size to half, (more exaggeration) temporarily while the skybox is being drawn. Slap it together and you have a far more convincing skybox (trust me, I know my examples sucked)
 
Last edited:
...what on Earth are you talking about? The skyboxes look fine. Have you ever seen the 3D skyboxes in any Source game ever? It's basically like that; it moves seamlessly alongside the rest of the level geometry. Dunno if there's a "stays put no matter where in the level you are" option, though.
 
I know what you're talking about, Metal96, and I think it's a cool idea that should be tried. However, I'm not sure software mode has the appropriate faculties to do it.

I think I'm going to try it with RPP.
 
The game Should have Dynamic lights in OpenGL Mode (Like in V1.09.4)

The corona effects? They look awesome, yeah, but I've heard that the things were changed and they just went 'fuck it' because making them all over again is the least of their concerns right now. I've heard that from someone, so don't blame me if I'm wrong. :I
 

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

Back
Top