Suggestions

A flag to make a Rising FOF wait a bit before falling back down. Rising FOFs which you have to spindash on are currently useless because you need to jump to stop spinning, making the FOF fall back down.
 
If the player is "Springing", the player should change back to his "Springing" state if traveling upward if previously being in their falling animation.
Code:
if ((player->mo->state == &states[S_PLAY_FALL1]
        || player->mo->state == &states[S_PLAY_FALL2]) 
        && (player->mo->momz > 0))
     P_SetPlayerMobjState(player->mo, S_PLAY_PLG1);

The same thing should apply for when the player is upside down. Also the player should be given the correct spring frame when "Springing" upside down.
Code:
if ((player->mo->state == &states[S_PLAY_FALL1]
        || player->mo->state == &states[S_PLAY_FALL2]) 
        && (player->mo->momz < 0) && (player->mo->eflags & MFE_VERTICALFLIP))
     P_SetPlayerMobjState(player->mo, S_PLAY_PLG1);
else if (player->mo->state == &states[S_PLAY_PLG1] 
        && (player->mo->momz > 0) && (player->mo->eflags & MFE_VERTICALFLIP))
     P_SetPlayerMobjState(player->mo, S_PLAY_FALL1);
 
Last edited:
Bi-directional conveyor belt

It's a conveyor belt that changes its direction (invert direction in 180 degrees) every X tics. Likely LD-510, the linedef length controls the speed; the direction the flat will scroll is the linedef direction; A linedef flag sets the conveyor as bi-directional; front side X-texture offset defines the time in tics that conveyor belt inverts its direction.

EDIT:

Transfer line working for X-texture offset

I'm testing the "Transfer line" flag in a FOF-conveyor belt, I discovered that "Transfer line" can transfer Y-texture offset very well, but can't do it with X-texture offset. I'd like to "scroll" a bit THZCONV1 and THZCONV3 textures.
 
Last edited:
We need a few more Trigger Linedef Executor conditions. Here are some suggestions:

1. Trigger Linedef Executor - Sector Overlap: The concept is simple: if an FOF is within the floor and ceiling limits of the sector (or a sector or FOF is inside another FOF), the Linedef Executor is triggered. This could produce effects such as a gateway in which a pole rises, touches the top, and sets off a pole right next to it, which does the same thing, and repeats itself.
2. Trigger Linedef Executor - Has Powerup: This linedef executor trigger will activate if a character with a Shield or something enters it.
 
2. Trigger Linedef Executor - Has Powerup: This linedef executor trigger will activate if a character with a Shield or something enters it.

Complementing fawfulfan's idea:

1) New Sector type/Linedef: Trigger Linedef Executor - Shield Check

Maybe I'm crazy. This idea came from this post (about Attraction Shield):

We could think of interesting gimmicks/effects for Attraction Shield: a player with Attraction Shield can turn on electric traps and electrocute other players on multiplayer maps, and turn on lights or move doors or machines if he steps on a socket [or dynamo], on single player and coop.

Some traps and effects could be triggered depending on the shield you are using.
 
The problem with this is: How would a player guess that he needs a shield in order for a trigger to work, especially which shield?
 
Lightdash is actually very useful in some places when there is a string of rings leading to another platform you have to use it a ot in some wad levels like Sa2 an SRB2U so i wouldn't exactly call it useless just not really used much cause no one ever thinks about that.
 
The problem with this is: How would a player guess that he needs a shield in order for a trigger to work, especially which shield?
That's up for the map designer to create some sort of giveaway. How would you know you you have to collect rings for a linedef executor to run without some sort of instruction telling you to do so?
 
Well if you play it an have to skip levels by multiplayer cause of that ringline you have to use lightdash for. but most people i play there levels some add scripts to bring lightdash back.
 
Server variable - autochange
If autochange is true, if the next map is for a different gametype then the current map, switch to the default gametype of the next map.

Trigger Linedef Executor - Floor Touch - Most Players
If the majority of players are in the sector, then the tagged Linedef Executor Trigger is activated.
 
I'm sure this has been mentioned before, multiple times, but I'll bring it up again because I want to get my point accross. The character system's strictness in design is totally understandable, alot of SRB2's character wads were a bit overpowered in 1.09.4 but I have a issue regarding ability2's functioning.

If you choose ability2 = 1, you're forced to remove the spin if you only wanted to make your character have a nojumpspin. Plus, you're also forced to use multiability (which doesn't even apply to all abilities anymore) whether you intended to or not. So you can't have a character using a jump->fall animation that can spin. Maybe not everyone is going to want to curl up into a ball (or spin like a top in Espio's case) whenever they jump.

The solution would be to remove the nojumpspin part from "ability2 = 1" and make a new value "ability2 = 2" which would allow nojumpspin and being able to spin, without multiability being forced on characters.

Okay, I got my point accross, what do you people think of my reasoning?

Moderator Notice:
 
Last edited by a moderator:
A way to make springs bounce you backwards, no matter what way you hit it. AKA, Casino Night bumper things.

A spring that holds you to it, and will only launch you if you press the jump button. AKA, Casino Night flippers.
 
New Sector Type or Linedef flag - Trigger Linedef Exec. No longer in the sector

Example: player steps on a switch and door opens; if player leaves the sector, the door starts to close.

If by linedef flag: a touch floor triggers two linedef executors, the 1st one opens the door immediately, the 2nd linedef has an "execute if no longer triggered" flag, then the door closes after the player has left the sector.
 
Here's an idea that's simple and cool: Make it so that Death Pits destroy any item that falls into them, not just players. This would mean, for example, that when a ring falls into a Death Pit, it vanishes instead of bouncing back up. This makes sense, and it would make Death Pits more realistic.
 
New Thing

A spring that keeps on bouncing you higher and higher each time you bounce on it, until you land on the ground. It also stops bouncing you higher at a certain height.
 
Here's an idea for something that'll never happen: The Portable Spring. Crack open its item box and then press an action key to let 'er rip. One-time use only. Especially helpful for Sonic in Match Stages.
 
Let the red ring have a separate sound and let it be edited so that can be a different object only (Like Senku's Sword). Maybe you can add like maybe 8 extra sprites for the ring like PLAYq1 or something.
 
Last edited:

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

Back
Top