Talk:Linedef type 403
It should be one fracunit of length equals 0.125 fracunits per tic.
Just checked the source code for version 2.0.5 and to make sure I wasn't mistaken, also made some experiments myself on SRB2DB.
For example, it takes 1 second for the sector's floor to move 35 fracunits if the length of the linedef * is 8. That means it takes 35 tics to move 35 fracunits (35/35 = 1) for a linedef length of 8, which proves that the speed is represented as 1/8 (or 0.125) FUs/tic.
This behaviour works the same for the linedef types 403, 404, 405, 406, 407 and 408.
* For linedef types 403 and 404 it's the length of the linedef, for the rest it's the X distance, of course.
--Ricardo 18:01, 29 May 2010 (UTC)
I always wondered who figured out the original number anyway. Thanks a lot, nice catch. Out of curiosity, did you find this in "p_spec.c"? --SpiritCrusherTalk • Contribs 18:03, 29 May 2010 (UTC)
- Yes, but in the end that's not where the actual "1/8 of the length" code is. In line 1901, p_spec.c makes a call to a function in p_floor.c, EV_DoFloor (line 2330), in which the following code says:
dofloor->speed = P_AproxDistance(line->dx, line->dy);
dofloor->speed = FixedDiv(dofloor->speed,8*FRACUNIT);
- Glad to help --Ricardo 18:17, 29 May 2010 (UTC)
In other words, this applies only to the move floor linedef types, and not any other movement linedefs? --SpiritCrusherTalk • Contribs 19:04, 29 May 2010 (UTC)
- No, it also applies to the ceiling ones. There's a similar function in "p_ceilng.c"(sic), called EV_DoCeiling, which also uses 1/8th of the length of the linedef.--Ricardo 20:18, 29 May 2010 (UTC)
Yeah, that of course too, I meant any other movement linedefs like scrollers. Though I should stop being lazy and look myself. --SpiritCrusherTalk • Contribs 20:40, 29 May 2010 (UTC)
- Well, for non rotation Polyobject movement, it appears that the speed is also 1/8th of a value, in this case the texture X offset. As for the rotation ones, didn't look much into it... The scrollers appear to use the exact value of the linedef length (1 FU of length = 1 FU/tic).
The "Continuous Plane Movements" (linedef types 52-58) also use the exact value of the linedef length.Not all behave in the same way
- Now, what really surprised me were the complexity around the crushers... It seems that the use of the linedef flag "Effect 4" changes the value of the speed or rather the way that value is computed. Basically there's a distinction between the crusher for the linedef type 62 and every other crusher (these include the type 61 and the ones activated by linedef executors). For the former, if the flag "Effect 4" is NOT active, the speed of the crusher (while it's rising, because this specific crusher begins by rising the ceiling) is 1/16th of the linedef length; if otherwise, the flag is active, then the speed of the crusher is 1/4th of the linedef X distance. As for the other crushers, if the flag is NOT active, the speed is 1/8th of the linedef length; if the flag is active, then the speed is 1/4th of the linedef X distance.
- It should be known as well that the "Effect 4" flag also has another side effect on the crushers: while it's active, the speed of the crusher when going down is the same as when going up.--Ricardo 22:52, 29 May 2010 (UTC)
The complexity with Linedef Type 62 happens because it's supposed to be unsynchronized with all the other crushers. I also made a list of all linedef types that use a movement speed and tried to find out what their values are:
- Linedef type 3: "speed = abs(lines[lineindex].dx)/8;" probably means 1/8 FU/tics per FU length too
- Linedef type 4: "linespeed = P_AproxDistance(lines[i].v2->x-lines[i].v1->x, lines[i].v2->y-lines[i].v1->y);" looks like 1 FU/tics per FU length; there is a MAXMOVE though which I can't find what it's defined as
- Linedef type 11: "speed = abs(lines[lineindex].dx)/8;" -> 1/8 FU/tics per FU length
- Linedef type 12: seems to be strangely missing from "p_spec.c"
- Linedef type 30: not in "p_spec.c", though I expected this
- Linedef types 59 and 60 call "EV_DoElevator", there's probably a source file covering this
- Linedef types 150-152 call P_AddOldAirBob, which I know is somewhere in "p_spec.c"
- Linedef types 190-195 call P_AddRaiseThinker, which I think is somewhere in "p_spec.c"
- Linedef type 428 is a executable copy of Linedef Type 60, so it probably uses "EV_DoElevator" too
- I assume pushers use the same speed as scrollers
I'm not finished looking into these, but some I can't figure out (I'm not that good at reading source). Any insights? --SpiritCrusherTalk • Contribs 10:12, 30 May 2010 (UTC)
Okay, this is what I found:
- 3: speed = (Linedef X distance)/8
- 4: speed = Linedef length (max is 60)
- 11: speed = (Linedef X distance)/8
- 12: speed = (Linedef length)/16 (minimum is 1 and if the flag NO_CLIMB is active, the value is "original speed + random number between 1 and 8")
- 30: speed = Linedef length
- 59: speed = 2
- 60: speed = (Linedef length)/4
- 150-152: speed = 1 when the player is standing on the FOF; = 0,5 otherwise
- 190-195: speed = (Linedef length)/4 when the player is standing on the FOF; = (Linedef length)/2 otherwise
- 428: same as line type 60
- pushers: speed = ??
Notes:
All the values are expressed in "fracunits/tic"
- 4: MAXMOVE is defined as 60 in p_local.h, line 53
- 12: the code can be found in p_enemy.c in the function A_RockSpawn (btw, every other SOC action can be found in the same file)
- 30: code in polyobject.c, line 2600
- 59: code in p_floor.c, lines 2617-1618
- 60: code in p_floor.c, lines 2611-2613
- 150-152: code is in P_AddOldAirbob (p_spec.c) and T_RaiseSector (p_floor.c) (aren't these line types deprecated?)
- 190-195: code is in P_AddRaiseThinker (p_spec.c) and T_RaiseSector (p_floor.c)
- pushers: these use much more complex code, all I could figure out was that there's a magnitude, not a speed, and that for the horizontal pushers, such magnitude is proportional with the linedef length and slightly greater for the vertical ones. --Ricardo 21:46, 30 May 2010 (UTC)
Yes, bobbing FOFs are deprecated and all official levels use the moving ones instead. Anyway, thanks for the help, now I just need to integrate these into their respective articles. --SpiritCrusherTalk • Contribs 08:19, 3 June 2010 (UTC)
I'm thinking of going through each of the linedef types to complete the articles with some more relevant information that may be missing. Shall I leave the speed details to you then? --Ricardo 09:23, 3 June 2010 (UTC)
If you're editing the articles anyway, you can do that too while you're at it. I don't mind if I'm not the one who'll add it in eventually. --SpiritCrusherTalk • Contribs 09:33, 3 June 2010 (UTC)