Talk:Linedef type 259

From SRB2 Wiki
Jump to navigation Jump to search

Wait, can't you just go into hexadecimal mode and add them all together? –SonicMaster 21:39, 25 November 2007 (PST)

That almost worked before, on the condition that you didn't try to specify the same flag twice. Now that the composite flags have been added, though, it doesn't. --Oogaland 15:18, 2 December 2007 (PST)


FF_RENDERALL is equivalent to FF_RENDERPLANES and FF_RENDERSIDES not just in effect but also in value. Similary FF_CUTLEVEL. It might be worth clarifying this; the current wording suggests there's a difference. If Kaysakado doesn't particularly feel like doing it, I'll get to it eventually, but I didn't want to tread too heavily on his fresh edits. --Oogaland 15:11, 2 December 2007 (PST)

How does the wording suggest theirs a difference? It says specifically not to use both, but instead just to use FF_RENDERALL. Also, since you're the one who originally wrote the article, IIRC, I just want to clarify: What's the difference between FF_RENDERPLANES and FF_BOTHPLANES? One last thing, if you want to tread heavily, tread away. I don't mind. ~Kaysakado  • Talk 15:43, 2 December 2007 (PST)

It says specifically not to use both, but instead just to use FF_RENDERALL.

Yes, that's the bit that I thought indicated that there was a difference. I felt it was analogous to saying, "To write 'potato', don't write 'pot' and then 'ato', just write 'potato'." I might adjust it to say "it's simpler to..." or something.

FF_BOTHPLANES causes both planes always to be rendered, even if the BSP traversal says they're occluded. This (I think) is useful for translucency and FOFs that you can go inside. --Oogaland 05:31, 6 December 2007 (PST)


FF_SOLID (0x6) is nothing more than FF_BLOCKPLAYER OR FF_BLOCKOTHERS and so it doesn't add anything new to creating custom FOFs, but because it's specified in the source and other composite flags like FF_RENDERALL, FF_CUTLEVEL and FF_INTANGABLEFLATS are displayed in here, why not add it to the table? --Ricardo [Contribs] [Talk] 20:22, 10 June 2010 (UTC)

Yeah, sure. I don't know why it was missing in the first place. --SpiritCrusherTalkContribs 07:09, 11 June 2010 (UTC) 犬夜叉(Inuyasha) 13:52, 11 June 2010 (UTC)

Okay, I understand the redundancy. So that means FF_RENDERALL, FF_CUTLEVEL and FF_INTANGABLEFLATS should go away as well? --Ricardo [Contribs] [Talk] 22:00, 11 June 2010 (UTC)

Or we could make a separate table for the composite flags. That might make things a bit easier to understand. --SpiritCrusherTalkContribs 08:08, 12 June 2010 (UTC)

I was leaning towards "What the heck was SonicMaster thinking?" myself... Perhaps I should have made it more clear. 犬夜叉(Inuyasha) 09:13, 12 June 2010 (UTC)

FF_CRUMBLE randomly bringing down connected FOFs.

I've made a map containing 36 FOFs, where control sectors are connected to each other and target sectors are also connected to each other, and control sectors also share a similar tag. After playing with the map for a while touching random FOFs, I can confirm that FF_CRUMBLE does NOT randomly bring down connected FOFs. I can provide a map if needed. --Rapidgame7 (talk) 15:43, 3 February 2017 (UTC)

Good catch, apparently that "info" had been there all the way back from 2007 when this page was first created. May actually have meant dragging down all FOFs sharing the same control sector but that's totally different to just any adjacent FOFs. (Also if it were a real thing, being actually randomized wouldn't be any use at all lol) =V -- Monster Iestyn Talk 16:40, 3 February 2017 (UTC)

FF_BUSTUP needing to be paired w/ FF_SHATTER, FF_SPINBUST, FF_STRONGBUST, etc.

If these bustable conditions also require BUSTUP's value of 800000 to be added to it in order for the FOF to actually become bustable, then what is even the point of listing their conditions without the BUSTUP value already added? It just seems a little confusing when you're trying to gloss over the table. Is there literally any use for those values outside of being combined with BUSTUP? -~ ♠ Gambit ♠ ~- (talk) 23:03, 26 October 2020 (UTC)

That's actually the values those particular constants have in the source code and in Lua scripts, so it makes sense to display those particular values for accuracy purposes. FF_SHATTERBOTTOM also has a second use: when combined with FF_SWIMMABLE instead of FF_BUSTUP, it turns water into THZ goop. (This is also why there is a FF_GOOWATER constant that has the same value as FF_SHATTERBOTTOM.) Monster Iestyn Talk 23:54, 26 October 2020 (UTC)