ZDoom Wiki Thread

[Gez]

MAPINFO

So...?

What's your problem? Didn't you read this? "Only the most important notions are described on this page, for examples and complete listing of all commands and properties, refer to each definition's subpage."

[Logan MTM]

Oh, i got it!

[Gez]

Alright, all action function pages now have a defaultsort key added to them, so that in the category pages they're no longer all grouped at "A".


In other news, while the bug that caused Template:Title to be wanted even though it wasn't and it existed anyway has been solved during an upgrade, another bug remains which causes "invalid title in result set;" to appear in the wanted page list. This is a bug which has been recently fixed by wikimedia; in the mean time it can also be solved by editing the page(s) responsible; the way to find them is to query the database as explained here.

[randi]

Okay, I took care of that. The refreshLinks.php maintenance script didn't take care of it like one of the bug reports suggested, but resaving the offending page did.

In other news, there are 321 user accounts that have never made an edit. I'm quite tempted to delete them from the database.

[Gez]

Okay, I took care of that. The refreshLinks.php maintenance script didn't take care of it like one of the bug reports suggested, but resaving the offending page did.

Thanks. That had bugged me for a long while.

And now, the wanted page list has finally dropped below 300!

[Blzut3]

I have a suggestion for the action functions not defined in actor. Instead of putting a note at the bottom of the page saying it's only available in a specific actor, use "ClassName::A_Function". This makes the requirement immediately obvious.

[Gez]

And edit all the other codepointers to prefix them with Actor:: or Inventory::? I prefer the way I'm doing things now, because it also explains why it's restricted.

[Blzut3]

And edit all the other codepointers to prefix them with Actor:: or Inventory::?

You could, but it may not be necessary.

I prefer the way I'm doing things now, because it also explains why it's restricted.

How is something like, "This codepointer is restricted to Sorcerer1 and derived classes," is more specific than just telling the reader right away where the function comes from? As I was trying to say before, having a small note near the bottom of the page is easy to miss. Perhaps you can use both methods?

[Gez]

These functions are specific enough, or complex enough, that they deserve to be read thoroughly. I don't want to go on adding a pseudo scope operator to them, or you'll have these easily-confused ADD people wondering why decorate doesn't work even though they did BLAH A 5 Class::A_DoSomething just like it was said in the wiki...

[Macil]

I updated the [wiki]Getaspectratio[/wiki] function to support the vid_aspect cvar and to return accurate values for the aspect ratios.

[Gez]

Threshold reached!

Codepointers covered by the wiki now include:
- All classic Doom codepointers
- All ZDoom-specific codepointers
- All classic Heretic monsters or projectile codepointers
- Nearly all codepointers referred to in more than one actor definition

Remains to be covered:
- Remaining of the Heretic weapon and misc codepointers
- Remaining of the Hexen codepointers
- Remaining of the Strife codepointers

Now some of the old codepointer pages probably need proofreading because I have noticed on [[A_CentaurDefend]]'s article was incorrect and a bit misleading (it's fixed now of course), so similarly flawed information might be found as well elsewhere. Oh well. I'm still glad the wanted pages count went under 250.

[CaptainToenail]

Can you update the MAPINFO page so it contains all the functions and options? I have to go back quite a few editions in the history to get some useful things such as totalinfighting etc.

[Enjay]

Quite recently, there was a discussion and conclusion that certain flags that were previously given as numbers in the Wiki be given their flag names rather than their numbers.

eg, A_SpawnItemEx used to have this:

1 ('''SXF_TRANSFERTRANSLATION''') — Transfer Translation: The spawned actor will use the same translation as the parent.
2 ('''SXF_ABSOLUTEPOSITION''') — Absolute Position: Spawn the actor at an absolute position.
4 ('''SXF_ABSOLUTEANGLE''') — Absolute Angle: Use ''angle'' as an absolute angle, and ignore the parent's angle.

and so on.

But now it has this:

SXF_TRANSFERTRANSLATION — Transfer Translation: The spawned actor will use the same translation as the parent.
SXF_ABSOLUTEPOSITION — Absolute Position: Spawn the actor at an absolute position.
SXF_ABSOLUTEANGLE — Absolute Angle: Use angle as an absolute angle, and ignore the parent's angle.

IIRC, this change was made for technical reasons but, frankly, it's a bit of a pain. Why? I have spent quite some time over the last couple of weeks looking back through old code that used numbers trying to figure out which flags were what and making sense of it - and the Wiki no longer helps me in such an easy manner as it used to. I know that it is still pretty logical but It would be so much easier of the numbers were still readily visible but somehow obviously discouraged. Would something like how Line_SetBlocking does it not be acceptable?

BLOCKF_CREATURES (1): Blocks walking things (players and enemies)
BLOCKF_MONSTERS (2): Blocks monsters (but not players)
BLOCKF_PLAYERS (4): Blocks players
BLOCKF_FLOATERS (8): Blocks floating creatures

ie, the numbers in brackets afterwards, perhaps with a bit of text on the page saying that the numbers are for reference only?


And just so that I know, what is the problem with the numbers anyway?

[Gez]

And just so that I know, what is the problem with the numbers anyway?

A number is meaningless. A name isn't. Numbers might change, names won't.

[Zippy]

Right. It's sort of an "obvious" thing for a lot of programmers that you never really question or think about. Dropping the number in there means you have to dig through and change it if the meaning of the number ever changes. Using a specific named symbol to represent it not only increases the generally readability of the code (in that you won't have to keep the number -> effect table in your head, or have quick access to a translation source) but grants maintenance integrity; ideally the symbol will never change meaning but now it can freely change its value, so if you have to restructure things you only need to go back to where the symbol is given a value and change that value once. All other portions of the code will automatically be up to date and unbroken then. The readability is a bit more important in ZDoom's specific case as the flags don't exactly get restructured often, if at all (though if the flag names had a stronger presence it could have helped with the Skulltag only flag instead of taking up a slot of ZDoom's flag space, but not a big deal).

I agree though that the numbers must be documented on the wiki somewhere. If not on A_SpawnItemEx's page then on a page specifically for documenting the physical value of flags for the event that you might need then.