Monster Iestyn's Monstrously Melancholy Maddening SRB2 tidbits thread

[Monster Iestyn]

Hi, welcome to my thorny thread of atrocious alliterations, my terrible topic of worrying witty wild words, my disorganised dump for disparingly dismal facts that everyone seems to have overlooked about SRB2 (so I don't have to put it in my Wiki userspace where there's no way to know if anyone checks)!

...here we go...


Part 1: Perilous PolyObjects (a.k.a The Truth about PolyObjects)

Myths and Truth:

• The tag of "First Line" is simply meant to search for the "Parameters" linedef with the same tag, nothing more. It has no relation to PolyObject ID.
• Parameters linedef's tag therefore has no relation to PolyObject ID either.
• The floor height of Parameter linedef's front sector is the ACTUAL property that needs to be the PolyObject ID.
• Linedef type 316 does not actually exist ...or at least, not as a trigger linedef with special behaviour - in function this is identical to the standard "Continuous" linedef (linedef type 300), and can be used by anything non-PolyObject-related in the same way. (14/01/15) - Linedef type 316's page was deleted from the wiki a while back, rejoice for the truth! B)
• As such PolyObjects with a First Line with Not Climbable set actually can use any trigger linedef special when a player lands on them, rather than just LD 316!

Parent/Child PolyObjects:
PolyObjects can be designated as a parent PolyObject to other, lesser child PolyObjects. This simply means that whenever the parent PolyObject performs a physical action such as moving or rotating, the child PolyObjects linked to the parent will do exactly the same thing!

Parent PolyObjects can be set up as normal. Child PolyObjects require the sector special value of its Parameters linedef's front sector to be set to the PolyObject ID of the PolyObject to designate as its "parent".

Known bugs as of 2.1.11:

• Linedef types 482 - 487 (the Move/Rotate specials) are not able to make child PolyObjects move, and furthermore the "Override" counterparts crash the game on use.
• linedef type 488 (Move by Waypoints) incorrectly offsets the child PolyObjects when close to waypoint destinations, resulting in them appearing to "de-sync" from the parent's path.
• linedef type 30 (Waving Flag) has similar problems as with the Move/Rotate specials.

These issues have been fixed for the next patch/release of SRB2. (14/01/15) - No longer relevant as of 2.1.12 onwards.


Test wad to prove this is true: polyobj-parentchild_test.wad (do note of the issue with LD 448 already mentioned earlier, still proves the concept works though)

Explicitly Include Line:
How this linedef is INTENDED to be used (possibly it is broken):

• EIL linedefs are actually meant to be applied in-level for their own PolyObject with its own anchor and spawnpoint etc, rather than as extras to an existing one
• First Line is not to be used, EIL's effect requires that it is not already present
• Apply EIL to all relevant linedefs
• EIL's tag should match Parameters' tag as First Line would
• Parameters MUST have a parent ID set through its front sector's special for the EIL linedefs to do anything
• Sector brightness level for Parameters can determine a parent ID to override the previous one set after EIL setup

Test in-game ...and voila! Your lines applied through EIL should appear when viewing the DEVMODE automap, but they are not capable of rendering textures in-level currently. They are also completely intangible, so they are effectively useless currently. (Your camera might notice something walking through them though.)

 

[Inazuma]

Bless you based shrek. You have brought me a monster that has enlightened me on one of my weakest areas in mapping.

Maybe now I'll make make some fancy poly objects

 

[Monster Iestyn]

Part 2: Obnoxious Overlays
What they are:
Overlays are a new feature for SRB2 introduced in 2.1 (since initial release), and they exist to make things simpler for having objects display extra visuals for an object. This I believe is another of JTE's generously given gifts for us to use in SRB2, as long as we know how to use them properly!

This feature involves the object type MT_OVERLAY which is specially designed for these purposes. Any object of this type will automatically disappear with its target (which should be set on spawn), and will automatically follow it around otherwise. However, if left untouched on spawn the overlay object will be invisible. It is expected you change the overlay object's state to whatever is required to be displayed on its target - this can be a static state or an animation involving several states, whatever is required!

Even though no actions need to be set for the states used by overlays, var1/var2 are still required. var1 = 0 will make the overlay display in front of the target object, var1 = 1 and above will make it display behind the target object instead. var2 sets the vertical offset the overlay is from the target's bottom height.

Summary of above, for what is required for an overlay object's setup:

• Set overlay's target to the object to display over
• Set overlay's state to the state with the visuals to be displayed
• var1: 0 = in front, 1 = behind
• var2 = vertical offset

Given the awkwardness of setting up an overlay object as already explained above by SOC, it is preferable to do this with Lua.

A_OverlayThink is also available for making objects act like overlays otherwise. var2 works the same as for overlays, but var1 is unused.

Examples in unmodified SRB2:

• A_1upThinker - used by the 1up monitor, to display the (nearest) character skin's 1up icon head over the monitor.
• A_MonitorPop - also used by the 1up monitor, to display the target character skin's 1up icon head over the box that flips after popping the monitor.
• A_SignPlayer - used by the End Level Sign, to display the target character skin's end sign head over the sign itself after it has finished spinning
  
• All shield orbs are capable of spawning an MT_OVERLAY for each of SeeState, MeleeState and MissileState, all of which are used as the visuals to display for each of the overlays. As of 2.1, only the Armageddon and Elemental Shields make use of this feature currently.

Example Lua scripts:

• Luatest-overlaytest2.lua - when Custom 1 button is pressed, an overlay object will automatically be spawned for the player (only can be done once per map). The overlay displays the spinning animation for the player's current skin at time of spawning.
• Luatest-overlaytest3.lua - same as above, except the spinning animation displays behind!
• Luatest-overlaytest.lua- same as first, but with a custom object rather than MT_OVERLAY, and use of A_OverlayThink.

 

[Monster Iestyn]

EMERGENCY NOTICE: I did not get all the facts right in the previous post previously, they are correct now! =E

(Mostly that it turns out A_OverlayThink isn't even required by MT_OVERLAY after all.)

 

[Monster Iestyn]

Did you miss my posts here guys? B)

To tide you lot over while I wait for my old harddrive's contents to come back so I can work on PART 3 of this epic saga, here's something that may be of interest to a few:


PART 2 1/2: The Complete Guide to HURJ (How You REALLY Jump)

Those of you who have been making custom characters since before SRB2 2.1 and still do, do you remember how "jumpfactor" used to be called "jumpheight"?

Turns out that old name was completely misleading: the value you set for jumpfactor/jumpheight is NOT, I repeat, NOT the thing that determines a character's jump height 99% of the time. What 2.1's name should hopefully make more clear is that it actually determines the % of the default jumping thrust your character gets when they press the jump button, as in how fast your character zooms up at the start of a jump.

This STILL doesn't directly give you the maximum jump height you get when you hold the jump button all the way up, but there is nevertheless a way of calculating this...

(WARNING: Those who don't know much maths may suffer beyond this point.)

The formula for calculating the jump height a jump can get up to IS:

*****************************************************************
THE JUMP HEIGHT FORMULA/EQUATION/MAGICAL MATHS THING:


[I][B]jump height = jumpfactor*thrust*(tics+1) - gravity*(tics*(tics+1)/2)[/B][/I]



[B](tics = jumpfactor*thrust/gravity)[/B]
tics are always integers, so fractions should be cut off!

*****************************************************************

[B]For a standard jump:[/B]
thrust = 9.75
gravity = 0.5

[B]For jumpfactor = 1:[/B]
tics = 19

[B]For jumpfactor = 0.85:[/B]
tics = 16

*****************************************************************

[B]Final jump heights:[/B]
*[B]Sonic[/B]/[B]Tails[/B] can jump [B]100 FUs [/B]into the air,
    or [B]124 FUs [/B]if stepping-up onto a platform
*[B]Knuckles[/B] can jump [B]72.8875 FUs[/B] into the air,
    or [B]96.8875 FUs [/B]if stepping-up onto a platform

That's it, yes! If you were expecting something simpler, sorry, that's as simple as it gets!

One hilarious thing to point out is that Sonic's jump height really WAS 100 all this time despite everything! ...same does not go for poor Knuckles however. Oh well, now you know.

Now, if you wanted me to show HOW I got this formula (to be viewed by maths whizs only for safety reasons), check the spoilered content below...

Spoiler

For those of you who know some physics and think
  [B]s = ut + (at^2)/2[/B] would do the trick,
this... doesn't really work in this case.
The simple reason is that SRB2's time isn't
  a [B]continuous[/B] variable (it is a discrete variable!).
In other words you don't get half a tic, or quarter a tic,
  or any fraction of a tic for that matter... you only have whole number tics.

So here we work from scratch:

default jump thrust = 9.75

v = jumpfactor*9.75 (default jumpfactor = 1)
g = gravity (default gravity = 0.5)

[B]Initial stats:[/B]
s = height = 0 FU
v = speed = +9.75 FU/tic
g = gravity = -0.5 (doubles when v = 0) FU/tic^2

[B]for every tic after t = 0:[/B]
s = s + v
v = v - g
(in that order explicitly)

Table of position, speed and gravity values for every tic until v < 0:

[U] [B]t[/B]     [B]s[/B]            [B]v[/B]     [B]g[/B]   [/U]
 0     0           9.75  -0.5
 1     9.75        9.25  -0.5
 2    19           8.75  -0.5
 3    27.75        8.25   ...
 4    36           7.75
 5    43.75	   7.25
 6    51  	   6.75
 7    57.75	   6.25
 8    64  	   5.75
 9    69.75  	   5.25
 10   75  	   4.75
 11   79.75  	   4.25
 12   84  	   3.75
 13   87.75	   3.25
 14   91  	   2.75
 15   93.75	   2.25
 16   96  	   1.75
 17   97.75	   1.25
 18   99  	   0.75
 19   99.75	   0.25
 20  100 	  -0.25   <-- s = jump height
...

Notice how a jump takes [B]20 tics[/B] to finish, but only requires up to
   the [B]19th tic[/B]'s thrust to get to the full height.

Due to SRB2's physics, the thrust can [I]never[/I] reach 0 in this situation!
   Therefore we can safely ignore the 20th tic's thrust by all means. 

t = u/g (9.75/0.5 = 19.5)

t is measured in TICS, so fractions should be cut off

=> t = 19

Now we bring together all these values to work out the total distance
  a jump can take you up.

s = 9.75 + (9.75 - 0.5) + (9.75 - 1) + (9.75 - 1.5)
      + (9.75 - 2) + ... + (9.75 - t * 0.5)

When we bring out the thrust value, we get this:

s = 9.75*(t+1) - (0 + 0.5 + 1 + 1.5 + 2 + ... t * 0.5)

The latter part can be simplified using [B]TRIANGLE NUMBERS[/B]!
(see [URL]http://en.wikipedia.org/wiki/Triangular_number[/URL])

T(n) = n*(n+1)/2

When we plug this formula in:

s = 9.75*(t+1) - 0.5*(t*(t+1)/2)

[B]Our final formula is:[/B]

[B]*****************************
s = u*(t+1) - g*(t*(t+1)/2) *
*****************************[/B]