- ‹ Older
-
7 years ago
-
I can't open it to general access as it has no spam filter and the spam was unbelievable. More than happy to give access to anyone who wants it though - just send me your email address and I'll add you.
-
Deleted 7 years ago by Docbuck
-
ty @Friznit t. I got in. No edit privileges, if you can make that change. other than that all is well.
-
Edited 7 years ago by Friznit
Irritatingly the only approach seems to be full admin or I manually select pages for you to edit. Is there any bit in particular you want to work on?
Trying to figure out which server it's installed on so I can fix the user group rights. Has to be done in the bloody file itself.
-
Edited 7 years ago by Docbuck
@Friznit my plan was to go through and fix old module names, replace old module photos. First. So... lots of pages. Here, I admin a few wikis. Noticed you have bureaucrat access, so if you care to fix privileges these are the links to glance at:
How
https://www.mediawiki.org/wiki/Manual:User_rightsWhere
http://alivemod.com/wiki/index.php/Special:UserRightsI would suggest giving the user group edit access, then utilizing this extension (if you guys will be on enough to approve changes, otherwise leave that task to someone active on there, or trust the community to manage their own edits):
-
SINCE we are on the topic... ALiVE is a wiki that could extensively use Semantic MediaWiki. See Semantic Bundle .
-
I've read all those guides but it seems the only way to change the user group rights is to edit the actual files - you can't do it via the UI that I can find. I'm the admin on the wiki, but can't for the life of me remember which box we installed it on (or the login details) so bear with my while I poke around some.
-
Edited 7 years ago by Friznit
@Docbuck should be sorted now. Please confirm.
Not going to bother with approved revs, I trust people to be sensible :)
Appreciate the help with the updates - if you want to do anything particularly radical let me know but otherwise go nuts!
-
Looks to be working. Thanks @Friznit you may close out this customer support ticket.
-
@Friznit and other devs, here's an example of my intent for each module.
-
Edited 7 years ago by HeroesandvillainsOS
Looks good! Thanks for doing this.
One request. The II dividing yes and no options looks a little confusing.
(yes || default no)
I'm not entirely sure how I'd replace it though.
-
Edited 7 years ago by Docbuck
Sorry it means OR in nerd. Will fix.
-
Yeah I've used it in missions too when setting up triggers but it just feels wrong. :)
Much better. But how about writing
yes or no. Default: no
or something like that?
-
Works for me.
-
Edited 7 years ago by Friznit
Or just default: no (it's pretty obvious that the alternative is 'yes')! But as long as it is logical and clear that's fine.
As a general principle when writing the wiki, I've always assumed that people will have the editor open so there's no need to describe what is in the module in detail, as you can just place it down and see for yourself. The aim is to describe the why and the how. Why do I need this module, what can I do with it, how do I use it, what should I sync it to, are there any special things I can do with it?
The wiki should also complement and refer to the tooltips you see for each field in the module.
And I generally avoid phrases like "click the link to see more" - in a quest to keep the words to as few as possible, it's important that every phrase adds value. There's already a shit load to read as it is!
Also bear in mind readability - a big block of text is quite off putting I find. The wiki is a pain when it comes to white space, but I go to some effort to open it up a bit so it's easier on the eye.
Also need to go through and anywhere it says "OPCOM" change to "Military AI Commander"! I keep catching a few of those.
-
But that's the problem is that there really isn't a clear definition of "what" anywhere. For example, without looking through at least two pages on the wiki, and messing with the modules, I'd have no idea "what" the numbers and colors on debug mean, which isn't the best example now that a lot of that has been discussed several times here and on the wiki (still not centralized though).
Better example is... Player Combat Logistics. One would assume that Player Combat Logistics is what you see in the editor...
But then if I go look at what most assume is it on the wiki...
http://alivemod.com/wiki/index.php/Logistics_Support
I'm still very much at a loss as to "what" it is. Until I've been around for a bit with the stuff and I find the blurb about it over on...
http://alivemod.com/wiki/index.php/Command_%26_Control
But then I'm trying to figure out what to do with the C2ISTAR Module itself, lol. I hope that kinda makes the point without being brash. Point is, WHAT everything is and does should probably be clearly defined before you start talking about the why's and hows. Yes, people can probably figure it out with some effort looking at it all in the editor. But eventually or, sooner than eventually, they'll turn to google, and you definitely want the right thing coming up to answer them. I would hope.
Go google Alivemod player combat logistics, tell me the first article that comes up lol.
-
I get quite a few PM's on BIS forums and friend requests on Steam from new users asking basic questions because the wiki wasn't completely clear. Regardless of how you guys go about it, it's cool to see it getting some love.
-
Edited 7 years ago by Friznit
Don't get me wrong, I'm all in favour of making it clearer! It's easy for me cos I know ALiVE inside out so it's super useful to have input from a second pair of eyes (and hands).
I agree on the Logistics thing - personally I didn't want to called the ability to lift & shift objects "logistics" anyway, since it has nothing to do with battlefield logistics....but every other mod (ACE / R3F / etc) calls it "logistics,"so it kinda got stuck that way. Obviously it confuses things when you implement an actual battlefield logistics system with convoys, battlefield casualty replacements and replen demands...
-
As someone who used to write "helpcenter" articles for a customer support I really like the example you posted, I like when you get as much (relevant) info as possible. And listing the parameters with a detailed explanation of what the different options do is great!
A minor aesthetic change however would be to change sub-lists to bullet points instead if having them numbered as well. But yea, as I said minor =)