emeraldtiger / re-mobilize Goto Github PK

If mappers use custom hook textures like the one above, it would make sense that, while the player would still be able to aim anywhere on the hook surface, the hook ray would always come from a fixed point which in this case would be the "eye".

More generally the func_hook would target a point entity (for example info_notnull). Then when the player attempts to latch onto the hook panel the hook will latch where the targeted entity is.

Which kind of targeted entity isn't important as long as it's a point entity and thus have an origin. Brush entity could even work by taking their (min+max)*0.5.
People will likely choose an info_notnull but they might as well imagine interesting situations with a monster or train, who knows.

The entity would be targeted by means of the hook's target property.
The hook may have additional regular targets as well (target2, target3, target4).
All 4 targets will be fired upon hooks events (about events, see here). So if the target entity is not an info_notnull and has a use function, it will be called (this might give space for creative map hacks).

Turning a regular trampoline into a wall trampoline could be a matter of a simple spawnflag.
It would allow for nice bounce tricks like when playing pool.

• Sending a grenade in a remote place
• Jumping forward on the opposite wall to bounce back on the starting side to the upper or lower floor (unreachable otherwise)
• Maybe spicing up combats with whatever ideas creative mappers may have...
• Etc.

A wall bouncing pad would arguably look like a regular wiremesh (if using the same texture, which is of course no tmandatory), but the player would quickly realize that it's unreachable and/or too small to allow to go anywhere... So there would be that spark of understanding blinking in their eyes and the excitation of having discovered a brand new instance of a trampoline and having to figure out how to effectively use it.

And even combos:

(or the other way around, btw)
Or even wilder ideas, who knows...

In addition to wall trampolines, ceiling trampolines would leverage the combo possibilities of the rm entities and allow for crazy bouncing tricks involving projectiles and "3D billiard shooting".

Speaking of "ceiling trampoline" is actually misleading since, it's not a special kind of trampoline actually.
It's just a regular trampoline put below a ceiling rather than the usual on ground.
The actual feature request is a modification of the default behavior of a normal trampoline, so that it's now able to react from below or from above as well.

We could even imagine using trampolines in situations where they're neither ceiling or floor trampolines, but "bouncing particle fields" located at an intermediate level and able to be hit from above and from below.

A hook behaves like a regular hook at first sight, except that when the player has traveled all the distance from their starting position to the ray's point of origin, they don't bump into the hook geometry and keep stuck there until they release the HOOK key, as they use to.
Instead they noclip through the hook, keeping their momentum, and finish their trajectory according to Quake physics. Like a "func_hook_illusionary", if that makes sense (I use this name for the sake of clarity but I don't think it deserves a distinct entity, a spawnflag is totally enough imho).
The hook shouldn't look different from usual so that the alternate behavior is a full surprise to the player if the mappers wishes so. Conversely if the mapper wants the different behavior to be clear, they can decide to give the func_hook an alpha value to make it semi-transparent, and the documentation will recommend this practice, while not enforcing it technically.

The cnt property of bouncing entities of projectile type (grenades & rockets) could be used to store the entity's count of bounces, incremented each time the projectile bounces on a trampoline.
Since the cnt property is one of those the progs_dump 3.0 trigger_filter entity is able to check, it would allow for situations where the number of bounces a projectile did before exploding matters:

• Direct shots could be ignored by a shoot target explicitly requiring billiard shots.
• Rewards could be granted whose value would depend on the shooter's skills like in a funfair (the higher cnt, the nicer the reward).

A nice and fun recreational use of bouncing projectiles adding a new flavor to the gameplay. 🙂

I suggest a new #wiki room on Re:Mobilize Discord.
It would be automatically fed with notifications from this Github each time the wiki is updated, so that people involved in Re:Mobilize are notified about all the wonderful additions made to the mod.
Thus, as soon as new features are developed, they can be documented and people instantly become aware of the new possibilities and can include them in their wip reflections and maps.

This is not intended to become the standard trampoline's behavior but an alternate behavior actionable by means of a spawnflag value.

A guiding trampoline affects the bouncing entity's velocity vector by setting to 0 the one of its x, y or z value which is responsible for the "bouncing away".
For example a classic ground trampoline cancels the z (vertical) velocity.
A x-aligned wall trampoline cancels the y velocity.
A y-aligned wall trampoline cancels the x velocity.

Compared to what it would be with the regular behavior, the bouncee's the trajectory is like projected on the trampoline plane.

Of course, the behavior being specific it's up to the mapper to make it clear to the player that special rules apply (different texture, warning centerprint, environmental story telling, whatever).

Thanks to a spawnflag, a trampoline could skip its bounce behavior to keep its fall damage protection trait only.
This cushion effect is currently considered just a side-effect of the entity but it's actually a worthwhile feature deserving the spotlight.
Practically this spawnflag would turn a trampoline into a "trigger_cushion".
Considering how heights matter with all the rm mechanics it could really be useful.

RM entities should support the target, target2, target3 and target4 properties like other progs_dump 3.0 do.
They would be fired each time an RM event occurs.
An RM event occurs when an RM entity updates its state property.

Here are the values I can think of for the state property (don't hesitate to enrich the list if you see other cases I missed):

HOOK
0 Player not hooked on the entity (default)
1 Player currently being hooked

WIREMESH
0 Player not climbing on the entity (default)
1 Player currently climbing

TRAMPOLINE
0 Not bouncing anyone (default)
1 Cushioning the bouncee (landing with no fall damage)
2 Bounce being occuring on player, monster or projectile

Special to trampoline:

• Trampoline states 1 & 2 are very short-life states instantly turned back to 0 as soon as SUB_UseTargets was called.
• If the feature request about guiding trampolines is accepted, my suggestion is that a projectile gliding at the surface of a trampoline raises a "cushion event" (state 1) just once then the trampoline state goes back to 0 (to allow several projectiles to glide on the same trampoline at the same time). On the occasion, the projectile itself might gain a state value indicating it's gliding (until it doesn't touch any guiding trampoline anymore) but let's keep that for later! 😅

No matter the entity type, in all cases of a state set to a value > 0, not only state changes, but the activator global must also be set to the hooked/climbing/bouncing entity: it's a requirement for trigger_filter to properly work.
Upon state value change back to 0, activator has to be set back to world since no one is using the mechanics anymore.

For all entities, SUB_UseTargets has to be called whenever the state property value is changed from 0 to 1 or 1 to 0.
(Special case for trampoline: not when back from 1 to 0, since it makes no sense)

This feature is meant to be used in conjunction with progs_dump 3.0 trigger_filter entity which is able to check an entity's state property to decide whether to call its own targets or not. This is how the rm entities targets, although being called upon every state change, will be able to actually react upon this or that state only (eg. hook-only targets or unhook-only targets).

Granted the sound featured in that video doesn't advocate the feature and make it sound silly and cartoony.

Yet the feature itself is great as it allows for tricky billiard shooting in a flavor which is obviously different from bouncing applied to grenades.

Also see the related Billiard shooting feature request.