ZDoom Wiki Thread

[Gez]

First the deprecation warning on SetLineBlocking may be a little misleading. This is a Hexen feature, and as such compatibility is a must and not just "may be retained". Perhaps a notice suggestion the use of Line_SetBlocking would be better?

That's the Template:WarnDeprecated boilerplate. It is excessively alarming IMO too.

Also it might be worth mentioning the purpose of FunctionName(const:parameters). This serves a purpose in optimizing scripts since a const function doesn't use push instructions for each of it's arguments.

Does it actually have a noticeable impact?

[Zippy]

First the deprecation warning on SetLineBlocking may be a little misleading. This is a Hexen feature, and as such compatibility is a must and not just "may be retained". Perhaps a notice suggestion the use of Line_SetBlocking would be better?

That's the Template:WarnDeprecated boilerplate. It is excessively alarming IMO too.

While it is a little aggressive, it does serve its primary point: any new maps created after the point of deprecation should never use the feature; instead using the replacement feature. While it can technically, and in a lot of ways completely safely, be gotten away with, its still a point of both principle and caution. So anyone who feels they know better may certainly disregard it (at their own peril if the case actually merits it), but for the people who don't know any better or actively refuse learn better, if the extra aggressiveness just convinces them even more that they should be using the correct new feature out of some imagined risk then really what harm is there in it?

Also it might be worth mentioning the purpose of FunctionName(const:parameters). This serves a purpose in optimizing scripts since a const function doesn't use push instructions for each of it's arguments.

Does it actually have a noticeable impact?

I don't recall specifically but I seem to remember Randy or Graf at one point saying that scripting was efficient enough to the point that the effect of using the const was incredibly negligible.

[Blzut3]

Does it actually have a noticeable impact?

It may not have an impact performance wise, but it might be a nice tip for those who may be having problems with runaway scripts. I know there was a thread about a non-infinite loop runaway at least once.

Edit: At the very least it may be worth documenting these things so that if someone finds old code using it they understand what it means. Even if we don't document it on the page for each function where it applies.

While it is a little aggressive, it does serve its primary point: any new maps created after the point of deprecation should never use the feature; instead using the replacement feature. While it can technically, and in a lot of ways completely safely, be gotten away with, its still a point of both principle and caution. So anyone who feels they know better may certainly disregard it (at their own peril if the case actually merits it), but for the people who don't know any better or actively refuse learn better, if the extra aggressiveness just convinces them even more that they should be using the correct new feature out of some imagined risk then really what harm is there in it?

My point is the ZDoom wiki is often used as a general reference for things even outside of ZDoom. While there may be a better alternative in ZDoom, someone writing a Hexen compatible script may not want to use the alternative. Thus the deprecation warning is kind of out of place in this one specific instance.

[Zippy]

Does it actually have a noticeable impact?

It may not have an impact performance wise, but it might be a nice tip for those who may be having problems with runaway scripts. I know there was a thread about a non-infinite loop runaway at least once.

Sure. Using the wiki's defined distance function is an easy way to induce that. If you have a few objects to check at sufficient distances you'll hit the instruction limit easy. In that specific case there are easily workable alternatives (specifically distance approximations that are accurate while the two points are close enough, etc.).

Hm. I think I'd still personally take a runaway script as a sign that I'm doing something wrong but I suppose it's worth noting somewhere.

My point is the ZDoom wiki is often used as a general reference for things even outside of ZDoom. While there may be a better alternative in ZDoom, someone writing a Hexen compatible script may not want to use the alternative. Thus the deprecation warning is kind of out of place in this one specific instance.

I'm approaching it from the opposite side. Because the wiki is primarily a source of modding information for ZDoom, preference is given to the strong deprecation warning, but there's no trouble with including a special note SetLineBlocking's article that it is Hexen compatible.

[Gez]

And here we see the how useful templates can be.

[FDARI]

The function PlayerNumber contains a usage example with script number 1000. The beginner's guide still specifies a number range from 1 - 999 and a quick test with the compiler proves that the restriction does still apply. It is a minor issue, but examples should be free of errors, right?

Code: Select all • Expand view

script 1000 ENTER
{
   Thing_ChangeTID(0, 1000 + PlayerNumber());
}

Also; if I run across equally obvious errors in the wiki, should I post here and/or correct the page, or forever hold my silence?

[Gez]

Well, as far as script numbers go, they're fairly arbitrary (you're not supposed to necessarily use the same number as in the examples), but why not.

Also; if I run across equally obvious errors in the wiki, should I post here and/or correct the page

Yes.

[cq75]

Should we add something to Sector_Set3dFloor about side texture alignment?

[Gez]

Why do people even ask these questions?

[cq75]

Why do people even ask these questions?

I can't speak for the other people who asked a "should we add X to the wiki" question, but I was hoping somebody else who knew more about the subject than I do would add something, because right now I'm not 100% sure of how it works. But if nobody else is interested in writing it, I'll mess with the function in DB until I feel comfortable with it and add something myself.

[Gez]

I'm getting "Internal error -- Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information." when attempting to save a change to Player properties.

---

* '''{{LE|Player.DamageScreenColor}}''' ''string''
* '''{{LE|Player.DamageScreenColor}}''' ''string''[, ''float''] {{svn|2435}}
:The color the player's display turns when the player is in pain. This can be specified as three hex values for R, G, B respectively, or as a literal color name (e.g. "blue"). If this isn't defined, it defaults to red. The intensity of the flash can be scaled from 0.0 to 1.0.

[Gez]

I'm getting "Internal error -- Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information." when attempting to save a change to Player properties.

Still broken, on all pages I've tried.

[randi]

Should be fixed now.

[Gez]

It is, thanks.

[randi]

The wiki has been updated to MediaWiki 1.16.0. Please let me know if anything was broken during the upgrade.