Grind rails like in Sunset Overdrive? Created 5 years ago2019-03-26 02:54:25 UTC by crystallize

http://www.youtube.com/watch?v=DFu1xVzeCAY

Arbitrary entry point is crucial.
Can I make something like this in Goldsource or Quake and fit into limits? I tried making a bunch of triggers but then I'm running short on clipnodes even with about 300 rail segments and I still have to map the level itself.

Not doable unless you code it into the engine, and I don't see that being an easy task either.

well you could try using func_friction on the edges with low friction and borders on the sides with heights 32 to avoid the player slipping off but coding it would probably be better

A madman who did Tactical Espionage Action would beg to differ, he used like hundreds of SoHL entities on every map, even made a stealth system with them.

SoHL can be pretty unstable to work with sometimes, at least in the latter releases, as far as I've seen.

Not doable unless you code it into the engine, and I don't see that being an easy task either.

into the game*
We don't have access to the engine. XD

BUT, it's possible. And here's one of my ideas. Defining an entrance trigger for the slide, and using path_corner entities to slide between. Then simply interpolate the player's position to the next path_corner, depending on what they're facing, and what they're closest to. It'd take some maths and time, but it's certainly possible.

Essentially, you'll get some sort of trigger_railslide entity, which detects whether a player is inside, and when the player enters it, it'll move the player as if the player were a func_train. Then, it checks which path_corner the player is closest to, and it takes the player's original position, and interpolates between that and the path_corner's, so that the entrance could be smooth and arbitrary.
I'd do a proof of concept (this stuff requires coding just one entity), but it's 01:24 here, so. :/

Essentially, you'll get some sort of trigger_railslide entity

I think I can already do that using just one trigger per rail segment but triggers eat up clipnode limit: with all limit hacks, 400 illusionaries eat up 22.2% of clipnode limit so I assume the triggers would as well and 1800 segment rail (say, around a nice tall tower) would use it all without any other geometry and any geometry at all. The trick is doing that without putting a trigger on every segment.

I believe you can do that without triggers.
Instead of trigger_railslide, let's imagine a point entity called func_railslide. It sends a trace between one path_corner and the other. If the player is in the trace, it starts working just like trigger_railslide would.

I drew the concept on paper today, I'll explain it in detail when I get home.

400 illusionaries eat up 22.2% of clipnode limit

Even with zhlt_noclip 1? Hmm.

Even with zhlt_noclip 1? Hmm.

Speaking of triggers, I believe with zhlt_noclip they wouldn't work because clips are their essence.

I think the best way to define grindable rails is point entities that define the rails like path_track does. When a player comes close enough you snap them to the rail and move them relative to the lines between points.

"I think the best way to define grindable rails is point entities that define the rails like path_track does. When a player comes close enough you snap them to the rail and move them relative to the lines between points."

This. Except I had an idea about checking whether the player is touching the line between the two points. "Close enough" is a bit harder to do.

"Speaking of triggers, I believe with zhlt_noclip they wouldn't work because clips are their essence."

I was talking about the illusionaries. And here's the concept.
rs1 checks traces between pt1 and pt2. If the player, for example, jumps on it, then rs1 will take that player and check the velocity. It'll determine the direction of movement according to the velocity, and accordingly, it'll snap the player to that traceline, and move the player smoothly to either pt1, or pt2, depending on the direction.

As you can see, the minimum keyvalues required for the entity to work are the start and end path entity. It's quite simple.

Now, in this case, three things can happen:

1. Player jumps off the rail
This is really simple. Check pev->buttons and dismount the player, maybe add a number like 50 to velocity.z.

2. Player arrives at pt1
Same thing as case 1. We have no neighbouring railslide node, so dismount the player (also, don't forget to 'lose' the pointer that points to the player entity, cuz' the player no longer belongs to rs1).

3. Player arrives at pt2
This is where things get interesting. The entity loses control of the player, and tells rs2 to handle the player. Then rs2 will move the player to rs3, and if the player reaches pt3, they will be dismounted.

Now, I believe that this specific way won't work for multiplayer. :/
It'd take some extra work to optimise this for multiplayer, since you have to take multiple players into account and thus somehow point to multiple entities at once, usually done with a for loop iterating until it hits the max player count.

On another thought, maybe you could just take one func_railslide and let it take on an entire group of path entities? Kinda like a func_train.

I thought I'm cool as I am tinkering with something complex but you just made it look so simple that my ego is utterly destroyed. It's okay though. Can't understand how could I miss this idea of multiple individual sliding entities, it seem so obvious.

And I thought I was presenting something complex.
But yeah, having 50 entities or so, each doing a part in the entire thing, it can take up more entity data in the BSP, entity slots, and it might have an impact on performance too.
Either way, can you program this, or should I provide you all the code?

I would really appreatiate your help as I never wrote a single entity from scratch. (all I ever did was tinkering with direct assignment of player's viewangles with gamepad a-la console games or making func_tank to rotate immediately) Meanwhile I'll still try to do the same with entities but movetype system and how triggers only react to solid entities, these are real pain in the ass.

I got you covered: Creating new entities

Also, here's a bit of material to understand the SDK itself:

Looking at a simple entity class
Creating a new entity class (my tutorial up there is this, but far simpler - I should port it to TWHL soon)
Finding your way around the SDK
Printing to the console with ALERT()
Engine functions
String handling in GoldSrc

The specific entity that you'll wanna make will need these three:

• traces
• some func_train code (imagine that our player is a func_train)
• some vector maths and logic

Thanks! I'll take a look.