Open Lilylicious opened 9 years ago
Perhaps a way to read from an online resource such as a git repo (so we can make live edits)
Maybe some way to incorporate the current wiki (which i should get back to work on)
I dont see the need for online reading simply because any text is going to be specific to the version of the mod and what it includes.
Online reading adds another layer of complexity that is frankly unnecessary. The main question for me is the approach: Menu or text heavy.
Botania is an example of a menu-heavy book, where you click a category that contains pages that you click to open. It makes the guide less limited into a traditional book structure and unlocks more freedom in what type of pages you add, whether it be text or big pictures or recipe pages and whatnot.
RFTools on the other hand follows a much more text-heavy structure and is more akin to a real book, where page 2 follows page 1 etc. With a table of contents with links and a searchable index, this can be as easy to navigate as the menu based system while allowing for a more natural book feel.
I would like to see the index be like: Category Name Link Link Link
This may result in the index being multiple pages, but I dont feel that each category needs to link to its own page of links.
Also if the index is 2 pages like a open book that will help.
Do we want to keep pages linked together traditional book style? Turning pages in other words. Could be useful for misclicks, simply turn the page to the right one.
Yea the index just linking to a page number would be nice so you can flip through, but you could always click "return to index" at any time.
@williewillus, regarding the location for the files: If we want to keep it gathered, it can all go in gameObjs.items.manual or something to that nature. Another option is to divide up the code for the manual (previously mentioned package) and put pages somewhere else, perhaps even in assets depending on how I implement things.
Just do whatever for now, I find it easier to reorganize as it develops than trying to factor it all in at the beginning before anythings written :)
After doing research and thinking, I've decided on how to proceed (for now) in regards to the page infrastructure.
There will be a directory of txt files from which the mod will grab and fill arrays. These will then assign their index to a series of constant ints to make the code more readable and fluid.
The details will come, that's the gist of it. Don't have an ETA, but I'm working on it.
Make sure to keep localizability in mind It probably will have to be in the lang file (or something like it, see how Vazkii localizes his Botania book)
Noted.
Yeah, I don't think you can look up lang keys out side of the lang files, so Botania just sticks all of the lexicon text in there (https://github.com/Vazkii/Botania/blob/master/src/main/resources/assets/botania/lang/en_US.lang)
Dislike the system, but if no other options exist for localization we'll have to make do.
The text will be in the lang files, found a way to make it neat still.
@williewillus @sinkillerj I'm making great progress, wanted some input before I went ahead with this:
Each page needs to be registered somehow. One good option is to do it at the same time as registering the item/block itself to the gameregistry through a function that does both.
Doing it that way would ensure that future blocks added to the gameregistry through the function will automatically get a page added to the guide book.
Another way that has a lower impact on the current code is to do a class for registering all the blocks we want in the guide as pages. Thoughts?
I'd prefer the second one - just one kinda "PageHandler" class that takes stuff to register. I want to minimize how closely tied this will be to the existing codebase (modularization -> good)
Also, is this just the framework or will it have the entries too? I want to loreify all the entries ;p
The text content will be in lang files, the item/block icon is auto-added as is the name. Further picture support is not yet present.
kk! I have quite a few of the wiki pages written already so after you're done I'll go ahead and import content and work on writing the rest (since I'm apparently Lore Lord or something like according to sin lol)
After I get everything working I'll push to my forked branch so you can start working on the lang file entries. The table of contents still needs a while before it'll be ready, so won't pull for another day or two.
First pushed commit is now in my branch. Link to the commit: https://github.com/Lilylicious/ProjectE/commit/69a531baf191b563cd83917817582ce87a755399
It's lacking a ToC and searchable index, but basic functionality is there. I'm sure there's cleanup I've missed too, but it's in a pretty stable state.
The gui is something I mocked up, basically a placeholder. The guide book doesn't have an icon yet.
The recipe is something I put in just to get one in, it's not final (shapeless book+dark matter). @sinkillerj , thoughts on that recipe/alternates?
As it stands, using the book doesn't pause the game in singleplayer, though it can (config?).
Adding pages to the manual is done in two steps: 1) Add the item/block to the addPages funciton in ManualPageHandler.java. I've used the variables in ObjHandler to do it. 2) Add text in a lang file where the key is help.unlocalizedName.info, example is present at the bottom of en_US.lang
Adding the item to ManualPageHandler.java makes a page appear with the items/blocks icon and localized name. If the lang file lacks the text, it will simply print the help.unlocalizedName.info key.
To sum up: 1) ToC/Index is missing in this version 2) GUI is a placeholder, guide book icon is missing 3) Recipe is a placeholder, book+dark matter 4) Maybe add a config for game pausing when reading book in singleplayer? 5) Thoughts on the page adding process?
eh I feel like DM is really really expensive for what's supposed to be an entry-level guide, idk.
Agreed, but I just threw it in there for placeholder sake. It's meant to change with input.
I will be changing the recipe, atm just make a placeholder. I will also be giving new players to the server a copy.
Yup, placeholder for now is Book + Dark Matter.
To document things said in IRC: Some minor issues arose in regards to items in the PR from willie, the feature is not yet code-complete and in the near future will be added upon to make it do everything we want to (index, non-item bound pages, images etc)
Non-item pages are done. Index next, then picture support.
Question: Pictures can either be on the same page or on the next page in line. What're your thoughts on that? Having a separate page would allow bigger pictures. Maybe have both as options?
Given the small size of the spread, I vote next page. Same page is really pressuring on the amount of text you can put, and I write quite a bit :p Though some entries are quite brief, so maybe having both options is wise. Add support for a little caption under the pic, too
I'll do next page as the default option, then see if I can't put in support for an optional same page version.
Caption request noted.
Can we make it possible that Items are displayed in a way the NEI R and U key work?
No promises, but I'll look into it. Would require actually putting the itemstack there rather than just rendering the icon, I think.
Basic image support: https://github.com/Lilylicious/ProjectE/commit/84e40da353bbd22f2623a69d6e1d4f9da50810f1
Allows for imagepages with a title and image. Images need to be 256x256.
Support for in-page images for other pagetypes will be looked at.
@sinkillerj @williewillus @MaPePeR I'm considering generating files manually. https://github.com/Lilylicious/ProjectE/blob/manual/src/main/java/moze_intel/projecte/manual/ManualPageHandler.java#L42 is the current implementation for registering pages, a for loop containing all pages of that type being generated and added to the list of pages.
Instead, I'm considering doing each manually. Something like
pages.add(new PEManualPage(ObjHandler.blackHole));
pages.add(new PEManualPage(ObjHandler.voidRing));
This would allow for much higher fine control regarding page ordering, as well as allowing me to easily register the page number for index purposes.
I'm going to go ahead and start on this implementation, if anyone has any protests shout at me.
+1 for manual
Items/Blocks are now added by using
addItems(ObjHandler.repairTalisman);
It handles both blocks and items, takes in Item/Block, passes that to PEManualPage constructor that makes it into itemstacks and everyone's happy.
Meta-items on the other hand is uglier but functional. Example below.
new MatterBlock().getSubBlocks(ObjHandler.matterBlock, null, subItems);
addSubItems(subItems);
addSubItems clears it after each call, so calling it the same way over and over works fine.
The index is harder to do than I anticipated. Researching options now.
I have the pages done, and the ability to order them as you want, as well as a HashMap of the unlocalized name (pe_mercurial_eye for example) as a key with the page index as the value.
The problem is how to add them to the index page. I could do "button" invisible rectangles over text, could potentially work. We'll see, research time.
Cheat off botania :p
It's a pain in the bum to sort through, but it's a good idea.
Okay. Okay. I did it. Sort of. The index works. Kind of.
The problem lies in the openGL scaling. As it stands, the size works visually, but the links are offset. I'm pushing the code to my repo, any thoughts and suggestions are welcome. I'll go to sleep now, get back on it tomorrow with fresh eyes and fix it.
Never, ever, code, when tired. https://github.com/Lilylicious/ProjectE/commit/8172e12f28159699a9223854553cf1fde0dc8536
The positioning looks a bit weird, but I'll take it. Fix tomorrow.
Before that commit: http://i.imgur.com/Zrsv0n9.png After: http://i.imgur.com/7MsgwlP.png
Due to my late night coding shenanigans, I'm in no shape to write halfway decent code today, so taking the day off.
I want to add in categories to the index screen, or at least a way to put them in. Also want to take a look at the scaling, I might be able to multiply some things to make the pixels actually make sense.
After that I'll need more input from y'all in regards to what categories are wanted and/or content for the pages. Do you want to take care of that before the book is merged into the main project? You can do pull requests to my manual branch for that, if you wish, then pull into the main project when we're happy with the end result.
I have most of the articles written (from the wiki), I'll throw up a google docs here in a bit so we can do the rest as we go
@Lilylicious I can categorize after its merged.
@sinkillerj @williewillus The latest commit is up on my branch and it's a doozy, 282 additions and 221 deletions. (Refactored a bit, that's the reason for the deletions).
I expect the index to "break" when we have all the categories in, so there's surely more work to be done there. Adding categories is as simple as adding a case to a switch statement with it. Now that I look at it, I forgot to do localization there, but that's a quick fix.
Some example pictures here: http://imgur.com/a/f87ph The Death category looks a bit out of place, which is fixed by altering the category structure or by adjusting the yOffset cutoff for new line (at https://github.com/Lilylicious/ProjectE/blob/98a8f5f0b15158ebda49a007fb0ddab8445f1227/src/main/java/moze_intel/projecte/gameObjs/gui/GUIManual.java#L275)
I'm waiting on @williewillus to give it a lookover for feedback/refactoring, but we're rapidly approaching a pull request.
@sinkillerj, do you want to finalize it before we merge, or merge when we're just missing the content? Could do work on my branch and pull request into that until it's ready, then move to the main project. We could use willie's google doc for deciding and cementing the categories/page order, which I can then do in the code. Or willie/you PR that. Or we PR then merge then fix in main project.
Whatever you do. Don't try to fix this code on master
Of course not.
@Lilylicious Remind me next time I am on IRC and I will give it a look over.
Opening the issue to keep track of guidelines/requests/thoughts.