How do I soc a Hang-Rail type object...

Status
Not open for further replies.
EMPEROR METALLIX said:
Now aside from a little scenery, how can we make this look realistic, like sonics holding onto an object attatched to the rail...
Click to expand...
You MIGHT be able to SOC an invisible spring with no gravity. This invisible spring would have the spawnstate of a state with a SPR_DISS sprite (Invisible). Once this spring is hit, it'll go to it's seestate that should repeat itself and show the hang-rail sprite.

The seestate is what most objects that are springs (mobj flag of MF_SPRING) go in to after being hit. In this case, once this invisible object is hit you should have it have a state repeating itself and which has a state action of A_CapeChase. But before the A_CapeChase, don't forget to have a state doing an action of A_FindTarget to find the nearest player!

tl;dr/easier understanding:
New mobj thing with flags of MF_NOGRAVITY, MF_SPRING, MF_FLOAT, and MF_SHOOTABLE.
Spawnstate of a state with a spriteset of SPR_DISS, duration of -1.
Seestate of a state of the same thing but pointing to a state, duration of 1
Next state having an action of A_FindTarget, looking for the nearest player, duration of 0, pointing to the state with A_CapeChase.
Next state having action of A_CapeChase, chasing it's target, duration of 1, pointing to itself.

As for the actual rail, you might need to use a series of FOFs.
In this case, you could position the hang rail object JUST below the actual rail (Z height/offset of 0) and add a mobj flag of MF_SPAWNCEILING (?) to the rail object. This way, adjusting the mobj thing's Z height/offset would be upside down and slightly easier to work with possibly (?). You could use the ceiling spike as your guide.
 
That's a great idea flame, but the problem is, how will it be possible for the mobj to not chase the player when the player is done using the rail? (unless I missed that)
 
Hyper Shadic X said:
That's a great idea flame, but the problem is, how will it be possible for the mobj to not chase the player when the player is done using the rail? (unless I missed that)
Click to expand...

Ah, very good for catching this. I have another theroy.
Regarding A_CapeChase, you can set a Z offset to the object to make it hover around the said player, using the state's VAR2. It's tricky but possible.

After the A_CapeChase bit is done, you'll need to do a bit of map editing.. Create another invisible FOF (Control sector) with the state changing linedef executor, make it almost exactly the same I did in the demonstration map. Create a sector at the END of the zoomtube waypoints (Unless there's already one there and I forgot) that the invisible FOF is tagged to. Adjust the FOF's ceiling height and floor height to be just above the player's head at the end of the Zoom tube so then we know the A_Capechasing object would hit this sector.
Look for the copied linedef sector that changes the state. Make the length of it be 314 we know that the mobj will 'kill itself'. Setting the linedef length to 314 would make the mobj go into a S_DISS state and dissapear ( :D ).
Don't forget to also change the tags of both the sector and linedefs!
 
Flame, you are a mapping and SOCing genius. There is no other word for it. However, you can make the Mobj's sprite have a Z axis in the sprite itself that's in the position where Sonic's hands are (did that make ANY sense?! o-O), thus not needing to SOC the Z Position thing (I think).

And regarding removing the rail, that idea is so crazy it just might work. o_O
 
This reminds me of that ten sector competition that the DooM fans had some time ago. You had to use limited sectors in a different creative way to make a good level.
Kinda reminds me of how you guys are using the soc action things.
 
Hyper Shadic X said:
However, you can make the Mobj's sprite have a Z axis in the sprite itself that's in the position where Sonic's hands are (did that make ANY sense?! o-O), thus not needing to SOC the Z Position thing (I think).
Click to expand...
Sprites go by X/Y offsets [In XWE and SlumpED as far as I know]. If you're doing something regarding a Z offset, then you obviously are editing something else. :P

First of all, yes I did understand. Secondly, there's benifits and flaws to what you said.
Editing the X/Y offsets of the sprite [In XWE, SlumpED, or whatever you use] would benifit by visual effects, yes, but this doesn't change the actual mobj thing. Only editing the sprites of the object would not affect the mobj's actual Z offset from the player while A_CapeChasing the player. That is, we didn't have a VAR2 controlling the z offset from the player. The object's Z offset would be the same as the player (Even when it doesn't look like it is), thus the object would never hit the sector that we just created at the end of our ZoomTube.
 
Ahh, yes, I misunderstood, and got Y mixed with Z. Silly me. ^^; That's true, the character could be hanging on the end of the Mobj, which would look messed up, especially if Sonic's hands aren't even touching the rail (imagine holding nothing when the item you should be holding is behind your hands). This also happens with Tails picking up a player, as in, moving froward a lot would have Sonic's hands slowly slip away from Tails'.. So, complication FTW. :P
 
Ice said:
This reminds me of that ten sector competition that the DooM fans had some time ago. You had to use limited sectors in a different creative way to make a good level.
Kinda reminds me of how you guys are using the soc action things.
Click to expand...

That post reminds me of Rush Job Zone by Neo Chaotikal. It had exactly ten sectors, and it pulled off an 8.00 in the contest, which happened to be third place for the Match Division.
 
This also happens with Tails picking up a player, as in, moving froward a lot would have Sonic's hands slowly slip away from Tails'.. So, complication FTW. :P
Click to expand...
That's just a problem with SRB2. :)
A state that has A_CapeChase, duration of 1, and looping itself over would not act how Tails acts when picking up a player.
 
This is the part of the thread where Draykon comes out of nowhere and gives his two cents.

Make the rail handle "thing" a scenery object that dies one tic after being spawned. Instead of the regular "Hanging On" frame, create a new state for the player, that still uses the "Hanging On" sprites, but loops itself, using A_SpawnObjectRelative to spawn the "rail handle" over the player's head. If everything is set correctly, the player will spawn the "handle" at the same rate as it dies, making it appear to simply move in a fashion similar to A_CapeChase, but completely dissapearing when the player reaches the end of the rail.

CapeChase isn't the only way to make an object appear to "follow" another object, so long as neither are animated.
 
Or, we can have 3 types of Mobjs. One is the hang rail handle you see, the other is the hang rail handle you don't see but travel on in the zoom tube, and the last one is the hang rail handle you see when you get off the rail.

Here's how it works:
...........===============
____P122222222222222223____
..........|..................................|
..........|..................................|
..........|..................................|

Key:

. = placeholder.
_ = state-switch sector & start of Zoom Tube/end of Zoom Tube.
_ = ground.
P = Player.
123 = mobjs (1st mobj, 2nd mobj, and 3rd mobj).
=============== = rail.

It works like this: When the character touches the zoom tube and touches the "spring," it goes into it's see state, which has the "A_FindTarget" action. The next state it goes into has the "A_CapeChase" action. Within a second (35 tics, I think), it goes into the "S_DISS" state, making it gone.

That was for the first Mobj. The one labeled "2" would be the same, only it would be invisible before you touch it. That way, there isn't 20 rail hangers.

The mobj labeled "3" would be the same too, only, it is invisible, it does not use "A_CapeChase," and after you touch it, it's always visible.

This would be useful only to Zoom Tubes that are straight, or zoom tubes that were properly set up (which would probably take a while to make it not look like crud).
 
Draykon said:
Instead of the regular "Hanging On" frame, create a new state for the player, that still uses the "Hanging On" sprites, but loops itself, using A_SpawnObjectRelative to spawn the "rail handle" over the player's head.
Click to expand...
But you would need A_DualAction repeating itself and calling A_SetTics with A_SpawnObjectRelative wouldn't you? I have doubts with this working with only A_SpawnObjectRelative. Of course, I'm thinking of how SRB2 handles the player states.
 
SRB2's automatic adjustment of the player states "duration" only applies to the states that by default function as player states. If the state used here is a freeslot, no A_SetTics would be required.
 
Ordinary SOCcing within the obvious limitations is actually pretty simple and straightforward, it's just once you start dealing with manipulating the hardcoded features, as well as stuff directly affecting the player that things start to involve more complicated stuff.

Flame is referring to a hardcoded trick SRB2 uses to make animation appear more fluid. Unless a MAINCFG parameter is checked, the player's duration is altered as his speed is altered. This means that the duration value entered from a SOC is ignored. To get around this issue, A_SetTics exists to allow one manually alter the duration of a player state, without disabling the effect altogether.

However, the effect applies based on state number, meaning it only effects the states that the player enters by default. If the player somehow enters a freeslot state, the effect does not apply, and duration is used as usual. So there's no need to use A_SetTics with my idea.

That make it easier to understand?
 
Status
Not open for further replies.

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

Back
Top