Talk:ZDaemon editing


Possible VFD[edit]

Edit-paste.svgThe content associated with this talk page was considered for deletion, and either was deleted, or was kept after a period of discussion. This page has been retained for historical reference regarding the deletion process, or in case of future restoration of any deleted content.
(Note: although this says "possible", DooMAD did in fact tag the article.    Ryan W 15:05, 18 August 2013 (UTC))

Although currently marked for cleanup, I'm not really sure if this falls within the scope of the Doom Wiki. As far as I know, we're not covering port specific editing for any of the other executables out there (and we'd have to duplicate a hell of a lot of content from other wikis if we started to do so). Page is also "orphaned" and not linked from any current articles. - DooMAD 18:36, 28 September 2011 (UTC)

In its current state, it's pretty much useless if you were looking for info about ZDaemon-specific editing. Or general editing. Or legible English, for that matter. It is indeed out of scope for the wiki and furthermore it's rather obvious nobody is ever going to bother trying to salvage it. If there's a vote for deletion, I vote "for". --Gez 20:54, 28 September 2011 (UTC)
There used to be a few other articles.  IIRC they were deleted for very similar reasons.  That said, are all those other wikis still active?  Port-specific mapping is one of the most popular activities in the Doom community, so if we don't allow people to write about it here, we need to send them somewhere that is actually open for editing (by people other than the founder's friends).    Ryan W 00:18, 30 September 2011 (UTC)
There isn't a ZDaemon specific wiki currently online as far as I'm aware, but much of the editing material would be covered under the ZDoom one anyway. - DooMAD 13:49, 30 September 2011 (UTC)
I'm not opposed to opening up the scope of the wiki to cover port-specific stuff... But it should be done, in my opinion, in a feature-centric way. Not "how to map for ZDoom", but maybe "how to use UDMF". The advantage of a feature-centric approach is that it is easier to update as ports evolve and it doesn't make it look like, for example, you have to use feature X when mapping for port Y. Instead, it's more logical (and more neutral) to say that you have to use port Y or Z when you want to use feature X. Such articles could use the main page detailing the feature as their portal (e.g., "Creating 3D floors" would be in the "See also" part of the 3D floor article); rather than being linked to from the port's page. --Gez 16:36, 30 September 2011 (UTC)
Now that you mention it, someone's already created an article to cover FraggleScript functions, so yeah, that would be fine I guess. But as I noted above, there are some pretty big gaps in content that will need filling in if we're opening that door. Being a comprehensive source, we'll have to cover every feature in every port, heh. - DooMAD 16:58, 30 September 2011 (UTC)
<--- (de-indenting a bit)

(deindented) Well, for a start, only features that are shared (even if in incompatible ways) by many ports really need to be covered. Examples: MAPINFO, MUSINFO, Slopes, Portals, 3D floor, ACS, FraggleScript, DeHackEd, BEX, UDMF, content definition language... Also the wording should generally imply that the article may not be exhaustive: "source ports implementing this include X, Y and Z" rather than "the source ports implementing this are X, Y and Z". --Gez 17:35, 30 September 2011 (UTC)

The Boom reference would be an important one to fully document, as most ports use those features. Actually, scratch that, already covered under Linedef type - DooMAD 18:09, 30 September 2011 (UTC)

Deleted.  The article as written really isn't useful as a starting point for expansion.  Although none of the posts above make a boldface "vote", none argue for keeping either, including mine which would apply only to a clear, coherent stub (or even an bulleted outline with a bunch of red links).    Ryan W 15:05, 18 August 2013 (UTC)