The aceccibility for this mod is quite bad.
This is even more unfortunate since this is such a great mod!

Expected Behavior:
- Just drop a Book into Config/Books lo let it load at next startup

Current Behavior:
1. You have to find out at first where to put the books.
2. You have to create the config/books folder
3. You have to know what a .json file is in the first place even if you are not a programmer/developer
4. You have to create a books.json file at the right place
5. Just drop a Book into config/books/books
6. You have to find our what to put into the books.json file
7. You have to edit the books.json file evry time you add or delete a book

Solution:
- Load all xml's of the config/books folder automatically at startup.
- Put the guidebook.xml into the config/books folder

It is not clear where to put the books and what to type into the config. I think it is a bad practice for any modpack developer (or anyone else) to put books in the jar file as this gets overridden with new versions.

I got it to work after quite a bit of fiddleing by putting books into config/books/books and creating a books.json file in config/books

I would suggest to just create the guidbook example in the config folder instead inside the jar. This way anyone who loads this mod and tries to create a book can instantly see where to put the books.

Also I would (if possible) rather just scan the config/books folder and automatically load all xml's at startup instead of manually editing a .json file. Most users are not that technican and this would massively improve the acessibility of this mod.

Hey, thanks for the feedback,

The wiki here in github has a more accessible version of the documentation. The ingame book (source) is just an example of the capabilities of the mod.

I am planning on making improvements to the system, so maybe I will make it possible to load the books from the config without having to explicitly list them. I just have limited time so I chose to implement it in a way that would require the least effort for me, and that was to pretend that the folder is a resource pack, so that the internal loading logic only need to know about resource packs. In order to make it able to load the books straight from the folder, I will have to add logic to the mod, so that it is able to load books in more than one way.

That said, I do agree that it would be nice for users to have some example(s), and I plan on creating some in the near future.

I have implemented a change in the logic (unreleased), that lets the mod load book files from the config folder.

However, this comes at a cost: with this change, it is not possible to load non-book files such as images for use in the cover or in the <image> tags.

To work around that, you would have to use a mod like Resource Loader, to achieve the same result.

I'm undecided.

There are two possible Solutions:

1. To have a folder Guidebook/Books for book files and Guidebook/Resources for Covers, Images and so on

[Config]
|
[Guidebook]
|-------------------¬
[Books]            [Resources]

2. Use wildcards for loading

import java.io.File;

File Book = new File("PATH"); // create file object
FileFilter fileFilter = new WildcardFileFilter("*.xml"); //create filter EVERYTHING.xml
File[] files = dir.listFiles(fileFilter); //create array with all files

// print out all files to console (represents application logic)
for (int i = 0; i < files.length; i++) {
   System.out.println(files[i]);
}

I'm already filtering by extension ;P

https://github.com/gigaherz/Guidebook/blob/master/src/main/java/gigaherz/guidebook/guidebook/client/BookRegistry.java#L126

I guess I could activate both the resource loading and book loading on the same folder, but i'm concerned that may cause issues. I could have a config setting to toggle the two modes on and off separately, to help people work around issues, or yeah, have separate folders. Although I feel like separate folders may confuse people more than requiring the books.json file?

I believe 2 separate folders are the way to go. It gets too messy if you just flush everything in the same folder.
Personally I would even go a step further and say that you have one folder per book
This wold open up a lot of ways for Book creation:

• Just create a folder and put your .xml in
• Just put a cover into the folder if you have one
• if you want an image in the book (dont know if you can put images into books?) just put the image into images folder of your book and in the book write

Also I think if the mod is provided with one or two examples everyone can understand quickly how to create a book.

I know, this is quite a lot of work. Maybe I can help developing but I have not developed a minecraft mod yet.

Yes you can put images in books, there's a cover attribute, and the tags.

However, due to limitations in the Minecraft resource loading process, the images NEED to be in a resource pack (or something that looks like a resource pack from the point of view of Minecraft).

I suppose I could "resourcify" the folders, make a fully custom resource loader that rewrites the paths so that Minecraft sees something that looks like a resourcepack, even if the paths and filenames don't follow the resourcepack rules. It will take some time, though, since my free time is rather limited (currently writing from work).

:D same here

I'm not entirely sure how you are doing things right now. I don't see anything that looks like a Pack.Mcmeta file and the structure with books in config is odd but . . . perhaps we could simplify things without making your life a living hell.

1. Add the Config/books folder by default so we can just go there rather than making it ourselves.
2. Get rid of the weird Books.Json file which nobody knows where to put for a mod pack. Instead just have us list books in the Gbook.cfg file. With this change I'm not making a new file, I'm just adding an entry to an existing array.
3. It seems like you are adding flexibility that isn't being used. If Gbook or Minecraft are examples of tags in the object file for an asset couldn't you just set your books to Gbook automatically? Similarly why am I specifying a file path? If you want all of my files in "Config/books" this is another thing you could use an automatic pointer for right?

I don't know if that makes sense. but I hope it helps.

Eventhough it is a bit complicated to read what you mean, I agree with winddbourne that there is atm too much flexibility which makes stuff complicated. It has to be easy to use why I thought an outomatic read og config/books would be nice

Hey :)

About #1, I'd rather not create a folder that may never be used for most people. It takes half a second to rightclick on the config folder and create a "books" folder inside it, so I don't understand why everyone is so concerned about creating folders...

About #2, the books.json file is needed for resourcepacks to be able to list the books they contains, since it's not possible to enumerate the contents of a resourcepack file in Minecraft. You can only request a concrete resource, and it will either succeed or fail. Also, adding books through the config file has been supported since day 1, the books.json is mostly for resourcepack use. This reminds me, though, that I never explained this in the wiki or the ingame book.

About #3, the only flexibility I'm adding is the config folder and resource pack support. the "gbook:" part of resource names is something integral to minecraft resources. Just like how the full name of the coal item is "minecraft:coal", mod resources look like "modid:path". For use in resourcepacks, this means that "gbook:textures/covers/default.png" is the text we have to use to refer to a file that would be located in "assets/gbook/textures/covers/default.png" in a resource pack. I didn't make this up.

(I wrote a whole lot here, but I decided to delete it, because it was more of a rant, than useful information)

Why are you assuming the books folder won't be used by most people? There seems to be only three scenarios where you would want to add such a book:

1. you are the author of a mod pack. This need has mostly been filled by enchirdion, and guide.api though many mods also use the book system from Botania. We can only hope that things standardize here. Right now my pack has guide.api for blood magic, and Guidebook for ender-rift. I would also have enchirdion taking up space if mariculture had updated. OUCH.

2. Adventure packs where the author wants to include lore. As these are likely uploaded to curse they probably are using the books folder to avoid having to also upload a resource pack.

3. A mod pack that wants to provide more lore and/or some in game documentation. This is where I am. Many players have asked for help with some of the less familiar mods, plus I have a lot of lore I want to add in.

Ironically I did make a resource pack for the skyblock I'm working on. But the sky textures I'm using could be downloaded and used by anyone who likes the feel of my skies. If I were to add books relating directly to my world and it's lore then the pack needs to become proprietary rather than just another something I threw out onto curse for mod pack makers.

So for mod packs again you are probably going to want to go the book path if you can so that the pack specific resources are downloaded with the pack and updated with it. It's just cleaner.

So two out of three potential users could be using the books folder in config? I hope I'm making sense. :)

Okay decided. I won't bother worrying about this any more time right now. My #1 priority for the mod is to implement <span> tags, and have <link> tags work as spans, so that you can mix different formattings, including links, inside a <p> -- like in HTML.

I was wrong in saying that most people won't be using the folder at all. Since most people play in modpacks, where it is the most likely to find ingame books, chances are they WILL be using the folder. However, this folder will come pre-created inside the modpack data, so most of them won't have to create it by hand, either.

Given that, the only group of people that would really benefit from having the folder created automatically on first run, are modpack and adventure map authors. Hence why I still think that creating it automatically is sortof pointless. I can (and will) do it -- it's just a single line of code -- I just don't see the need for it.

Well - I too am a modpack author 👍 we may be a less amount compared to minecraft players but we are (mostly) the only ones touching the mod itsef so we bring out the mod to the people. regarding this i think it makes sence. Anways, thank you :)

Thanks. For me accessibility is a big deal. I started working on my latest mod pack in 1.7.10 and I have a folder called "needed configs" . . . the number of different files I've edited to make things work together and run nicely is over 100. Then I've got three folders of custom recipes using minetweaker and I made a custom resource pack that alters the garden of glass sky box rather than just vanilla stuff.

Now I'm updating the whole project to 1.10.2 and that's a ton of stuff I have to do. When I sit down to make lore it's something extra I'm taking on because I don't just throw mods together, I try to make worlds. If I go ahead and make documentation for someone else's mod(s) it's because my testers asked for the help and it's extra work for me.

The last thing I want is for it to be a huge hassle. I want to sit down and write my thing using whatever formatting I need to, and then go in and look at the results; edit it a dozen times, and get it out to players who will take it for granted. lol

This project is exciting because it's resource based nature looks like it could really let me step up my game and make some really exciting and deep worlds. :)

Again thanks for all the hard work. :)

v1.5.0 is out. Enjoy. :)

A working example can be found in the examples folder at the root of the source repository.

So, I have been thinking about it, and this is what I did:

1. The books folder will be a drop-in location for books, they will be loaded automatically without having to register them in the config or in books.json
2. Inside the books folder, there will be a resources folder. This folder acts like a resourcepack, in a way similar to how Resource Loader handles it: writing cover="gbook:something" will be loaded from "config/books/resources/something.png".
3. Because of point 1, the books list in the config file is unnecessary, and hence, gone.

I'm testing that everything works, and then I'll do a release.