From DoomWiki.org

(Ordering)
(Tables)
Line 59: Line 59:
  
 
::::: I agree that 80% invisible tables would be unacceptable, but there may be a little misunderstanding: [[User:Xymph/DMMPST#Hexen_tabs|my approach]] is to put the three single-player tables in one tab and the two multiplayer ones in the other, and I already covered the mobile issue in my discussion of that. The question remains whether invisible multiplayer tables only (40%) may as yet be acceptable? There are also two [[User:Xymph/DMMPST#2016-08-25|formatting complications]] (the params to col-break and prettytable not working), maybe you can find a solution for them? Alternatively, if tabs are still unacceptable, what do you guys think of the two-row approach? --[[User:Xymph|Xymph]] ([[User talk:Xymph|talk]]) 16:45, 25 August 2016 (CDT)
 
::::: I agree that 80% invisible tables would be unacceptable, but there may be a little misunderstanding: [[User:Xymph/DMMPST#Hexen_tabs|my approach]] is to put the three single-player tables in one tab and the two multiplayer ones in the other, and I already covered the mobile issue in my discussion of that. The question remains whether invisible multiplayer tables only (40%) may as yet be acceptable? There are also two [[User:Xymph/DMMPST#2016-08-25|formatting complications]] (the params to col-break and prettytable not working), maybe you can find a solution for them? Alternatively, if tabs are still unacceptable, what do you guys think of the two-row approach? --[[User:Xymph|Xymph]] ([[User talk:Xymph|talk]]) 16:45, 25 August 2016 (CDT)
 +
 +
::::::← unindenting ←
 +
 +
The two-row approach seems fine, though I don't actually mind a single row either if it doesn't cause layout issues in some cases (I imagine it might be too unwieldy on mobiles). --[[User:Gez|Gez]] ([[User talk:Gez|talk]]) 18:52, 1 September 2016 (CDT)
  
 
==List of things==
 
==List of things==
 
Since you've added the stealth monsters, you should probably add also the MBF dog (888) -- it's used at least in [[Valiant]] (where is is dehacked into an arachnorb). --[[User:Gez|Gez]] ([[User talk:Gez|talk]]) 17:15, 18 August 2016 (CDT)
 
Since you've added the stealth monsters, you should probably add also the MBF dog (888) -- it's used at least in [[Valiant]] (where is is dehacked into an arachnorb). --[[User:Gez|Gez]] ([[User talk:Gez|talk]]) 17:15, 18 August 2016 (CDT)
 
: Soitenly. And while you're here again, could you answer my question [[#Ordering|above]]? Otherwise I'll assume that the current classification of both items is fine. --[[User:Xymph|Xymph]] ([[User talk:Xymph|talk]]) 02:09, 19 August 2016 (CDT)
 
: Soitenly. And while you're here again, could you answer my question [[#Ordering|above]]? Otherwise I'll assume that the current classification of both items is fine. --[[User:Xymph|Xymph]] ([[User talk:Xymph|talk]]) 02:09, 19 August 2016 (CDT)

Revision as of 18:52, 1 September 2016

Ordering

The Backpack is categorized a powerup in Doom tables, while the Bag of Holding is considered a collection of ammo in Heretic tables. I have a mild preference for the latter approach. What's odd here is that the Bag of Holding is a powerup in Heretic (it's one of the items that are counted for collection in the end of level statistics) but not in Doom. --Gez (talk) 17:44, 5 August 2016 (CDT)

Ah, good point. So you suggest to put the Backpack with the Ammo class, and the BoH with the Items? Or both with Items?
That also invalidates a separate Health/Armor class, I suppose, since some of those are Items too.
Any other suggestions? --Xymph (talk) 03:00, 6 August 2016 (CDT)
I'd say put both in Items. The Bag definitely is one, and the backpack doesn't behave exactly like an ammo pickup (for example you can pick up backpacks even if your ammo is already fully maxed out). Health and armor would include things such as medikit, stimpack, crystal vial, silver shield, amulet of warding, etc. but health bonus, armor bonus, berserk pack, quartz flask, and dragonskin bracers are items.
Basically my "item" litmus test is this: if it's counted up as an item on the intermission, goes in your inventory in Heretic or Hexen*, and/or is always picked up when you run over it, it's an item. (Unless it's a key.) [*In Strife pretty much everything goes into your inventory, so this criteria is only for the Raven games.] --Gez (talk) 03:13, 19 August 2016 (CDT)
Alright, it still feels a bit unnatural to me that some health/armor would go into another class, but the intermission count is a stronger argument. See the updated tables. Rad suit also isn't countable, but it makes no sense to put it anywhere else either.
That brings me to another detail; what should the class header be: Items, Artifacts, Powerups, or even Power-ups? Currently Doom and Strife use Powerups, Heretic and Hexen use Items. But in the latter, that's (too?) close in naming to the next class 'Puzzle items', and Strife has 'Quest items'. The Item page also mixes all those terms including dash/no dash in Powerups. Thoughts? --Xymph (talk) 08:58, 19 August 2016 (CDT)
Items is generic enough IMO. Puzzle/quest items I would actually fold into keys ("Keys and puzzle/quest items"), since that's basically the purpose they serve. --Gez (talk) 17:20, 24 August 2016 (CDT)
Good, but for Strife I'd move the various coins pickup out of K&QI and into the generic items. I'm not sure it makes sense to refer of gold as quest items in the first place since I don't believe there are any Strife quests that require you to have money. --Gez (talk) 06:52, 25 August 2016 (CDT)
Re: merging puzzle/quest items with keys, good idea, see the updated tables and sample maps. And Strife gold was classified that way because of this list but I'm fine with moving them.
So, if there are no further suggestions, then I'm considering the classes and their entries final, apart from Strife's minor character problem I outlined at the end of my update today. Any feedback on that? --Xymph (talk) 09:37, 25 August 2016 (CDT)
The minor characters could possibly be handled with templates, so that the spaghetti code would be handled on the wiki's side. I'm thinking of something kind of like this, which could switch on the {{PAGENAME}}, so for example {{Peasant133}} would appear as [[Worner]] on MAP04: Power Station (Strife), and just as Peasant Red 3 on every other page; or for another example {{Peasant130}} would appear as [[Strife minor characters - Hub 1#Arion|Arion]] on MAP02: Town (Strife), as Technician on MAP04, and as Peasant Tan 2 on any other page. Technically it's possible on the wiki's side, so the question is whether the other admins are okay with me creating 22 switching peasant templates and if your program is okay with having some thing types use curly braces instead of square brackets. First thing first, though, we'll need a recap table summarizing which peasant appear on which map and which name they have there. --Gez (talk) 10:54, 25 August 2016 (CDT)
Very interesting idea. DMMPST can easily output something different for the character names, see the table update. Currently I've spaced out the curly braces to avoid dead template links, but it's trivial to unspace them. The only (minor) downside is that when a Const template displays a thing as Peasant XYZ, it cannot conditionally wikilink only the first such entry – it would have to be all or none. I think none is acceptable here.
A table of minor characters for each Peasant is available on their page. I'm barely familiar with Strife so I'm not sure it's completely accurate, and cross-checking with the relevant (or all) map pages may be prudent. Also, in SLADE3's things_strife.cfg file one Rebel and one Beggar are also listed with alternate minor characters, so for consistency I've parameterized them all – 33 in total. And I moved the Kneeling guy and Zombie (spawner) to the end of that class. If you can attain sufficient admin consensus and then create those Const templates, that would be most helpful. --Xymph (talk) 14:32, 25 August 2016 (CDT)
I think we need to deindent a bit...

Okay, deindenting. The peasant table is a good starting point, but it's not complete unfortunately. (E.g. Ulaine isn't on it.) Also we're running into a secondary issue -- how to identify peasant types consistently? If you look at this for example, you'll see them identified as type 6 and type 15 -- those are the conversation IDs. There are also the editor numbers, and the ZDoom actor classes (which is Peasant with a number suffix based on their order in the executable, which means it's the same as the conversation ID minus 5). And there's what you've been using so far which is yet again different, based on their color and a count for this color in particular. --Gez (talk) 14:50, 25 August 2016 (CDT)

I wasn't really aware of conversation IDs, but I see your point. I found this list that may help but still have no idea how to find those IDs in the source code, and relate them to Things. I'm not sure what you mean by me using colors though; the tool counts by Thing IDs (DoomEdNums). The comments next to these actor lists provide another list of maps they appear on.   Anyway, you are probably far more familiar with those links and this entire subject matter than me. Having been mostly out of DOOM-land for nearly two decades (and knowing Strife least of all four main titles) means that I can use all the help you (and others familiar with Strife) can provide. I've learned a lot in the past few months of wiki contributing, but by no means pretend to now be able to solve long-standing issues single-handedly. So, how would you propose to move forward? --Xymph (talk) 15:36, 29 August 2016 (CDT)
The conversation ID is simply the mobj type's index in the mobj type table. It's the same thing as the dehacked number for Doom classes. That's also why some things have different conversation IDs depending on the version (first teaser, second teaser, full game), as some classes were added or removed. For the color thing, I'm just referring to how you had named them such as "Peasant Red 1" and so on. --Gez (talk) 20:05, 29 August 2016 (CDT)

Tables

Five tables side-by-side for Hexen is perhaps a bit much, so maybe something should be made collapsible, or the multiplayer tables should be below the singleplayer ones? It might be possible to adapt the maptab template to put each table in a different tab? --Gez (talk) 11:37, 14 August 2016 (CDT)

Do you want me to give it a try? I think I know what failed. Look below for the hoop I'm jumping through:

Tab with tableOther tab
This table should work
I guess I hope

As you can see, since everything is in a template, all the pipes (|) are interpreted as argument separators for the template. The solution is to use {{!}} for every pipe character that isn't an argument separator for tab2. It's a special magic word. (It used to be a common template before that, but I discovered when trying to use {{tl}} to link it that it wasn't one anymore.) Anyway, I think I can make it work. --Gez (talk) 15:49, 14 August 2016 (CDT)

That's an interesting suggestion, but then with its parent Tab2 template. Unfortunately, my first two attempts failed miserably – Quasar wasn't kidding that this tab stuff takes a lot of effort to get right. That was before I saw your response above, so I copied this one to a new edit window so as not to overwrite that. :)
My initial approach would be to put Hexen's three single-player tables in the first tab, and the two multiplayer ones in the other. There are no Tab3 and Tab5 templates, and since three tables do fit well enough within reasonably sized browser windows, it seems overkill to put each table in a tab. Especially if this is to be applied consistently to all games and vanilla Doom/Heretic maps use just two tables. How this works out on mobile devices is another matter though.
So, with your timely reminder about the |->! escape, this might work as yet, though the whole thing would become pretty unreadable and difficult to edit manually – but still easy to generate via the tool. I'll give it a go.
However, DMMPST so far is able to process all games in a generic way with a single Things template and some decision logic in the code. Breaking up Hexen's tables into two groups would make that much harder, if not require a separate processing branch – which I really would like to avoid.
PS. Your offer of tab-help is appreciated, but I would be helped even more by a response in the main discussion topic. --Xymph (talk) 16:18, 14 August 2016 (CDT)
I'm not sure exactly what is the main topic here, since this has all been spread about everywhere, as you noticed. On central processing? --Gez (talk) 18:04, 14 August 2016 (CDT)
The most recent and all-encompassing one you initiated, yes. --Xymph (talk) 01:41, 15 August 2016 (CDT)
Unfortunately I cannot endorse this idea of using maptabs for important article content because of the fact they do not work on mobile, at all, nor can they be made to do so. When a maptab template expands on mobile, only the tab marked as the default tab (this is, by default, the first tab defined) will be written to the article and the rest are discarded by necessity of it being impossible to redefine a flowed layout for an arbitrary number of floating elements where the use of JavaScript is supposed to be minimized. The justification for this with regard to the maptabs in particular is that having the unmarked non-walkthrough version of the map image is in no way critical to end-user experience when reading a map article. On the other hand, hiding four whole tables worth of information from mobile users is unacceptable. --Quasar (talk) 15:26, 25 August 2016 (CDT)
I agree that 80% invisible tables would be unacceptable, but there may be a little misunderstanding: my approach is to put the three single-player tables in one tab and the two multiplayer ones in the other, and I already covered the mobile issue in my discussion of that. The question remains whether invisible multiplayer tables only (40%) may as yet be acceptable? There are also two formatting complications (the params to col-break and prettytable not working), maybe you can find a solution for them? Alternatively, if tabs are still unacceptable, what do you guys think of the two-row approach? --Xymph (talk) 16:45, 25 August 2016 (CDT)
← unindenting ←

The two-row approach seems fine, though I don't actually mind a single row either if it doesn't cause layout issues in some cases (I imagine it might be too unwieldy on mobiles). --Gez (talk) 18:52, 1 September 2016 (CDT)

List of things

Since you've added the stealth monsters, you should probably add also the MBF dog (888) -- it's used at least in Valiant (where is is dehacked into an arachnorb). --Gez (talk) 17:15, 18 August 2016 (CDT)

Soitenly. And while you're here again, could you answer my question above? Otherwise I'll assume that the current classification of both items is fine. --Xymph (talk) 02:09, 19 August 2016 (CDT)