Hello, Hadova-M! My name is SlyCooperFan1 (call me Sly!) and I'm the new Wiki Manager for your wiki, replacing Technobliterator who can no longer continue the position. I act as a liaison between this community and Fandom Staff and I'm here to provide assistance wherever needed, so please feel free to reach out if you have any questions!
Hey SiamJai! I'm Technobliterator, and I'm the Fandom Wiki Manager for Elona Wiki. I'm here to help your community, and I'm a liaison to full-time Fandom Staff. If you have any questions relating to the wiki, whether it's code-related, policy related, or otherwise, I'm your first point of contact.
I notice you're the most recently active admin here, though you haven't edited a lot lately-- but I figured I'd reach out to you either way to let you know I'm around in case you do return to activity. Feel free to let me know if you need anything! I'll check your RecentChanges every so often, but for the quickest replies, drop me a message on my talk page here!
Hi Technobliterator, and welcome to Elona Wiki! Thanks for joining us - the wiki can always use another experienced coder, and I'm sure our community will benefit from a direct line to the Fandom staff.
As you have probably noticed, this is a user-driven wiki, I'm mostly a maintenance-type admin. We have awesome members that bring official game updates, develop mods and expand wiki functionality to fit Elona better.
With that said, I do keep an eye on Fandom features and official development affecting the wiki, and keep the wiki updated accordingly. I do have some questions regarding some of these (especially the now defunct map function), but I'll bother you with that later on your talk page, to keep this one tidy. :)
I check the wiki daily - in fact it's the browser's homepage - so feel free to get in touch as well.
Since Elona+ v1.83 brought about the dungeon change, I'd like to make seperate pages for the types of dungeons. I believe the dungeon types are different enough to warrant their own pages, anyway. Each page would include a sprite of the dungeon, the kind of material harvest that is more likely to be found, links to the races of monster inside each type, and what one can find from digging the walls of the dungeon. I would also like to make a personal project of adding a location subheading to each monster npc page. Before I undertake this project, I'd like your thoughts, if maybe it's not worthwhile.
Info on the new dungeon types could definitely be made more accessible, as it's something that would probably be referenced more often. From the way you describe it, looks like it's gonna be great!
As for individual pages for each type, that would make the info easily findable through Search, but less easily comparable. OTOH, if they'd be listed on a single "Dungeon Types" page, they'd be easier to compare, but would be less likely to turn up on a specific search. :) Each way has its pros and cons, so it depends only on how you'd like to start out.
Location subheadings would also be a useful thing to have imo. One thing that we tend to be more careful about nowadays is the separation of variant-specific info on a vanilla page, or at least a clear indication that it's a feature of E+/omake/etc.
Also, probably you know this already, but here is a tip before doing many small edits in bulk: there is a "mark all edits as minor by default" in Preferences, which will make it easier for others to filter out edits of that nature in Recent Changes.
It's great to see fresh ideas on improving the wiki, and thanks for asking my thoughts on it. Glad to give my opinion as another editor. Best luck and have fun! :)
I have Noa's source code and was thinking about adding some of the more technical details to the wiki. What's your suggestion for pathing pages for technical info? Or just include on the relevant page?
For example, if I were to put how shop/arena/etc rank work (they're all based on similar function) should it be on their relevant pages or on a technical page with a different title?
Either way works. As a rule of thumb, extensive technical info is best published as a full article, a subpage branching off the main namespace (e.g. Food/Technical), while brief technical info usually goes into the main article, either as a one-liner or as a relevant sub-section.
In my opinion, info that is relevant to different pages would probably be best written as its own article, say, "Ranking mechanics", in the Technical information category, and then linked from all relevant pages (e.g. Shop rank and Arena rank).
Welcome to the wiki, and thanks for sharing your expertise!
I see what you mean. Usually the NPC gets the suffix when there is naming conflict with a class/race. However, until now this happened only within vanilla or the same variant, afaik.
If we followed this now, it would create confusion, since a default namespace would be occupied by variant content, with vanilla content moved to a suffixed name. This would go against the guiding principle that vanilla content is treated as default, with variant content listed as additional matter.
With that in mind, I would recommend keeping the default names for vanilla content (NPCs in this case), and the suffix for the variant content, whether it is class, race or anything else.
But this is not an "admin" opinion, just that of another editor. I think this topic would be best discussed on the forum - let's see what others think.
This category does not show subcategories, as having any kind of population. It also does not show up in the parser when adding categories to pages. This is odd, also, on some pages it is impossible to add things to categories at least for me. For example on the Electric Cloud and Chaos Cloud pages I can't add them to cResFear tag or the cFloat either.
I'm working on these categories because finding NPCs by bitflag is a very useful thing to do if making pet teams. It also removes the disparity between wiki pages that includes lines about a bitflag, but due to their wording, does not show in the same search results, i.e; "It self-inflicts Fury" would show on pages with cTemper bitflag, and in another page, "it has the cTemper bit", would give results, but it means you would need to do multiple different searches for the same thing.
Just checked that category, and I see 21 subcategories listed, with the number of pages shown next to each subcategory. In other words, nothing out of the ordinary. Do you see it void of subcategories? Or do you mean it doesn't show a mixture of individual items and subcategories, like it shows in, say, the Items category? For individual pages to show up in a category, they have to be directly in that category afaik. Also, sometimes it takes a while for the server to update certain changes (e.g. after I deleted the three "marked for deletion" pages, they still showed up on the list for a while).
Regarding the parser not listing categories, I'm curious about the type of editor you use (visual/rich-text/source). Editing the Chaos cloud page in source editor mode, I typed "[[Category:Cr" and it listed all the cRes category options.
Thanks for the useful contributions; I think the new categories make these pages more easily accessible. Hopefully we can figure out the solutions to these issues as well.
p.s. it's also helpful to mark category additions as minor edits, both because they don't cause substantial changes to the articles, and also because this makes it easier for users to filter their Recent Changes feed. :)
I use the categories tab at the bottom of the page to add categories which doesn't enable me to make it a minor edit. Also the Chaos cloud page wouldn't save the categories themselves, nor do some of the others. For me, specifically, another user could change those pages.
Edit; nevermind this is resolved using the edit button instead.
Glad to see it worked out! Not sure why the tab behaves that way though.
For minor edits, you can set your Preferences, under the Editing tab, to make edits "minor" by default. Useful when doing a bunch of minor edits at the same time - just need to remember to switch it back afterwards. :)