You have my sympathy, @Markil3. And thank you for your honesty.
Unfortunately, I don’t expect I’ll be much help. When it comes to reviewing and updating the Wiki, I’ve got zero traction these days. While I have the necessary time and know-how, I’ve developed an aversion to even looking at the Wiki.
And since the Wiki has become the “long pole” of the v3.4 release, it’s an awkward situation. Either I snap out of it, or more help shows up, or we release v3.4 without adequate documentation, or v3.4 is delayed indefinitely.
My advice would be to remove everything that is considered outdated. Nifty gui, the old animation page (and in place add a work in progress page for the new animation system) and other stuff that is no longer relevant for the engine. Soms serious deletions on the wiki, to make it clean and good again. And from there start building the wiki. It will be fresh, people will possibly have more motivation to add bits here and there. Would that help for you @sgold ?
I would be able to write about certain topics if help is needed, for instance the new animation system.
I a bit disagree on this one. It is still very much there, and usable. If you like to steer users to i.e. Lemur. Then do that, but Nifty GUI is still valid on its own. And it doesn’t even change. So there should be no outdated documentation.
Building the Animations using AnimComposer, TransformTracks, keyFrames (done), & AnimClips.
Running the Animation Clips using ClipActions in layers.
Styling the clipactions runtime sequence using BlendActions & Tweens.
I am still organizing for other parts, when I have them, I will ping you or do a pull request, but I just want to see a feedback of the style that I am writing in, before continuing or doing a PR.
This.
Please, don’t remove the Nifty docs, they are still very useful and Nifty works just fine with 3.4.0.
I like lemur but I still prefer Nifty for some things (the documentation is one of the reasons).
The wiki should say that Lemur is the recommended GUI library, currently Nifty is the only one documented under “Graphical User Interface”. Lumur is relegated as a third option after tonegodui in a small note (and the link directs to an old post with dead links in it).
The only way of knowing about lemur is reading the forum and looking for it in github to find the wiki.
Deleting things is relatively easy, and I’m fine with deleting things when it’s good for the Project. But as the discussion about Nifty has shown, more thoughtful changes are often required.
And I can’t even delete files until I overcome my aversion to looking at them.
Kinda a conundrum as nifty is an official part of the engine, yet not maintained by the team as far as I know. It is the only link under GUI because of this official designation.
Lemur is recommended by users and its maintained by an engine leader, but not an official part of engine. I would follow Pauls advice and leave that situation as it is now. However, it is under User Contributions in the wiki where it belongs. I know lemur has extensive documentation under its repo and in the forum.
A Tonegodgui fork is maintained by another engine leader, but not an official part of engine. No idea how current it is myself or if it has separate documentation. Tonegodgui is documented in the wiki, under User Contributions, but does link to the original creators code, not the fork. It is most likely outdated info I would suspect.
I could add a page under the GUI topic stating what I just wrote and move the links from User Contributions. If the TonegodGUI fork has documentation and is recommended, provide links for it.
Links are easy to add, move around or delete. Just need a consensus on what people want to do with this situation.
I have to ask. When did this new policy of the wiki preventing a releases occur?
I must also quote directly from the engines own contribution page.
If your code is committed and it introduces new functionality, please edit the wiki accordingly. We can easily roll back to previous revisions, so just do your best; point us to it and we’ll see if it sticks!
As I recall, the decision was made by the engine team to not enforce this based on the belief its better to have the commits/features than the documentation. As no one knows the code changes and reasons for it better than the contributor making the changes, I would suggest otherwise, but its not up to me. Writing the code is only 50% of the job. The team has decided half is better than none.
The engine has dozens of contributors whereas the wiki, not so much. It can take as many as 8 hours or more just to rewrite a single page properly. When it comes to adding a new feature, it can take weeks to get it right and only the bravest of souls step up for that.
I respectfully suggest that if a new release is ready, release it. The wiki will eventually catch up. As its versioned now, it should not hold a release back ever.
As far as I know, there’s no such policy. However, I stated early on that
I don’t want to issue another release with out-of-date documentation. It’s unkind to our users, and it places unnecessary load on the troubleshooters here at the Forum.
Who made that decision and when? If I thought I could change the decision and make it stick, I would.
Thank you for that suggestion. I’m seriously considering doing what you suggest.
Its buried somewhere in a forum post. I do not remember the verbiage used to get it to show in a search. Doesn’t matter though because if you start enforcing the policy the problem will then be solved. Bring it up with other engine leaders.
This is a perfect example of something simple not being so simple. Took 3 hrs because one you pull a thread, you never know what your in for. You may find many other things need to be done in the process, which I did.
The problem with forcing enhancements to come with documentation is that you end up with no enhancements.
The theory is that it is better to have the new features than to not have the features as many users will be able to figure it out anyway.
After all, if JME implemented that policy from the beginning, there would be no JME. Sometimes for the community to get involved, there has to be many roles to fill. A documentation person can’t document things unless they exist.
The problem we suffer from now is few contributors in general. That’s all.
I don’t disagree. As that is the case though, the wiki should not be allowed to slow down things. I am trying my best to participate but its really, really tough right now. Today’s changes caused considerable trouble for me time wise but I don’t want you guys to think I am not interested in contributing or losing interest in the engine.
I am involved in some really important things that must be done right now is all.
If there’s a feature but no documentation, would it be feasible to put a placeholder and point to the relevant forum thread? Usually features are discussed here, and the forum is the best place for getting up to date information.
Not really imo. That’s just not very user friendly and could lead to more loose ends and confusion on the users part. Another issue is whats in a thread cannot be controlled.
Many topics have varying opinions on how to do things. Sometimes wrong ones. as has been pointed out in my own replies on occasion.
