ICBM-2
ICBM-2 copied to clipboard
BuiltBrokenModding
In game documention
I think it would help users if we had some kind of in game documentation abilities. Might be best to have it mainly in VE and have mods be able to call it and add their documentation to the manual (what ever we chose).
We want to limit our dependency on external mods so dark and i were talking about putting something in voltzengine that would help with that.
Sent from my iPhone
On Jan 20, 2016, at 5:54 AM, Blue64 [email protected] wrote:
In Game Wiki mod is fairly stable if you're looking for suggestions
― Reply to this email directly or view it on GitHub.
It can be a soft dependence, PneumaticCraft doesn't require IGW Mod, but it has the info available for IGW Mod to use if it is installed. I do see your point though, Self Sufficient, right?
exactly. We do have things planned. We are just waiting for us to code up all the content before we document it in the game.
Just don't do what MineTweaker did with their documentation (they don't even cover how to remove from an OreDict in their wiki, yet they've already moved on to building the groundwork for very advanced arrays in the Mod) People love the "Document as you go" method, because
- It lets people keep up with the latest additions
- It teaches people to play with their new toys
- It really showcases the progress
- It offers a break from the monotonous behavior of endless coding (mod authors enjoy this perk lol)
You may code it up slower that way, but it offers a very high quality look and feel.
We do have stuff on our website that is being documented. But as far as in game stuff that we would need to lay some base work before we do.
Sent from my iPhone
On Jan 20, 2016, at 9:02 AM, Blue64 [email protected] wrote:
Just don't do what MineTweaker did with their documentation (they don't even cover how to remove from an OreDict in their wiki, yet they've already moved on to building the groundwork for very advanced arrays in the Mod) People love the "Document as you go" method, because
- It lets people keep up with the latest additions
- It teaches people to play with their new toys
- It really showcases the progress
- It offers a break from the monotonous behavior of endless coding (mod authors enjoy this perk lol)
You may code it up slower that way, but it offers a very high quality look and feel.
― Reply to this email directly or view it on GitHub.
Ah, see, that's why IGW Mod was made lol the mod author got tired of needing to go back & forth between the wiki and the game lol if I wasn't making a mod pack (hasn't been easy, and it's not quite done getting tweaked) I'd probably be available to just type it all up lol
@DarkGuardsman and i could look into how to integrate with IGW but I will leave that up to him if he wants me to add it to the gradle scripts or not.
The plan is to do an in-house version of IGW for all mods extending VoltzEngine. The reason for this is that the website wiki and in game version will use the same data files. That way everything is updated and we kill two birds with one stone.
So a CoreLib Soft Dependency on the Wiki Files basically? Because you'd need them available for offline use as well.
In theory there would be a wiki folder in the user's MC folder. This would would contain something like json or xml files. Each file would be an entry in the wiki and would be used to generate a page inside MC. These pages will be included with the mod.jar and update automaticly as needed. Configs for disabling the downloading will be provided as well injecting custom wiki files. This way modpacks can add to, modify, or override what is contained in the wiki. For example if they change the recipe of the machines to be RF suppported. Then they could go in and change the expenation of how to create the machines in the wiki. Though recipes most likely will be automatcily updated.
this is similar to how IGW Mod works already, but yeah, I'd release it as a separate Mod, that way y'all can have dependencies on the version it was built for (and include a message in the Log about potentially needing to update Mods when an incorrect version is returned), and you're capable of better limiting the File Size of the rest of the Mods, while still keeping the Wiki Optional (for those who don't want it). Just have it set it so that it works on Server Side without needing it Client Side, and if it's not there Client Side, then the Recipes obviously shouldn't work either, so I'd get that set up as well for it, but all in all a very sound Idea. :+1:
Obviously You'll want a Hard Dependency for your Wiki Mod to rely on at least 1 mod which it is built for (perhaps some kind of Core Mod).
someone recently also suggested to MineTweaker the ability to add the Text Pages to NEI, and another person requested a complete printout to the log from "/mt names" which I piped up should also include the Localized Name as well as the Un-Localized Name, since not all Mods like to use multiple IDs for their Blocks/Items.
Most likely it will be built as a lib.jar that will be downloaded by VoltzEngine. This way the non VoltzEngine mods can use the system. Though it is possible that early versions will be included inside VoltzEngine until it is done. Similiar to how VoltzEngine's current plugin permission system works. Which is planned to be seperated due to complexity of making VoltzEngine work server side only.
As for disabling the wiki, that will be done threw configs with the default being to always install. As the idea behind an ingame wiki is to reduce the number of questions of "How do I use Xxxx machine".
Most likely all wiki data will be created using unlocalized names, short names, and a backup data file for name changes. As well translation systems will be implemented later on to load localized wiki files.
Question. Hypothetically, could someone write the documentation and then send it to you?
Yes, we currently have a web based wiki on github. You can pull request changes in to the wiki.