Currently choose which spread only shows cells with spread name, spreads should have either art assets to reflect how the spread looks or the number of cards. So, it should have info like number of cards, a string field to describe what the spread can be used for, and maybe an image to reflect what the spread actually looks like on a table or something?

When dragging the cards in the carousel, occasionally the inertia state won't switch to the proper state, and even though I have released touch, the carousel continues to follow the movement of the mouse, instead of moving based on inertia. After clicking again, the carousel returns to normal behavior.

Steps to reproduce:

1. Run main.tscn
2. Go to draw scene
3. drag the carousel either direction until you see it happen

The carousel position values run opposite what you might think, and it may cause issues showing the correct
cards consistently. This needs testing, and confirmation.

Confirm it does/doesn't have an effect on:

Choose your cards(hidden chosen order vs display order)
see your cards(chosen order vs displayed order)
the deck(original deck order)
user history(loading)

Figure out if I need to redesign just the way the carousel_position is calculated, or if I can just do some quick array ordering
to fix this.

This is at the research stage - Currently I have no known method of testing implementation until I can get xcode on the computer.

App Lifecycle Solutions - (Needs Research)

• Can Godot save states?
• Can Godot access iOS lifecycle API?
• Do I need to restructure anything to make it work?

With some answers to this I should be able to start testing how this will operate once it's launched.

Currently I had the heart image as an indicator, but now I need to consider the best way to
indicate that a card has been chosen.

• research shaders for user experience events(reward, confirmation, negation, etc)
• look at animations for the same
• consider an icon
• consider the animation involving sliding the card out of the carousel vertically(difficult, complex, but tactile and realistic)

Must wait for #12 to finish as well as some progress on #5 before deciding on this.

I suspect it has to do with how the scene is prepared when leaving from either show your cards or
user history, but it needs more digging.

To reproduce:

choose a spread, choose cards, get to the show your cards scene
go to user history via menu, load a scene
repeat until error occurs.

Deck Core Features:

Deck Order Persistency (From shuffled to shuffle, the deck order is copied and behaves like a physical deck of cards)
True Random Number Generation(User generated RNGs via hashing of raw image data)
RNG Saves (Save a special RNG for regular use/manifestation)

How it works:

1. Main Scene has :

• Use a previously generated seed(history)
• Generate a seed from a photo
• Use a pseudorandom number generator(stock RNG class)

2. Previously Generated Seed Menu has:

• Load a previously generated seed(history)
• Delete an old seed

3. Generate a seed from a photo Scene has:

• Take a new photo(camera access request)
• Use a photo from library

4. Use a pseudorandom number generator Scene has:

• Select from more than one option? (It's unknown if I can create options, but I'd like there to be)

I expect to be able to access the core scene as a sort of singleton, hopefully this way I can allow a user to change their seed
on a whim.

This would be so I can provide a 'clarifier' card when the user is unable to interpret the current spread clearly, simply by:

1. Selecting the 'clarifier' button
2. Choosing whether or not to change the seed for this question (then the deck core scene is instanced)
3. Drawing a card

Requirements for this feature:

Persistent Data Storage(user generated seed history, photos? maybe)
Photo Processing (input is raw photo data, output is a small RNG seed)
RNG classes (Maybe I need to expand the current class?)
UI stuff(animation for 'number crunching stuff')

For the moment, I'm holding off on developing this, mostly because I still have my hands full developing the main features, and because my plan was originally to just launch this on iOS. Now that I know a bit more, I'm realizing it may be much more advantageous(and fast) to develop for android as well due to simplicity of the export process in Godot, so it's now possible that I could implement this feature for an android version first if I suffer any iOS issues.

cardnotecell needs to update as the user navigates the deck, so I will need to keep at least one blank cardnotecell at all times, and clear current user notes from the container each time the user changes which card they're looking at.

This requires:

• An animation to fade/transition the cardnotecells disappearing whenever a swipe to the L/R is detected
• Reset the state of the containers children (cardnotecell blank + cardnotecell users notes)
• Load user notes back into the container(if any)
• An animation to fade in the cardnotecells

This can be reused in seeyourcards.tscn if it's done properly, so make it flexible, pay attention to how info is provided in both scenes

I'm pretty sure I need a new carousel for seeyourcards.tscn.

Build one.

It has different requirements, so just remember:

• It has a small set of cards(It's got a start and a finish)
• It needs to respond to the button and to swipes
• It also needs a container to instance in cardnotecell.tscn cells to display users notes
• It likely needs to scroll in the same manner as DeckCarousel.tscn

I might be able to design this using an hbox container inside of a scrollcontainer, but it would require learning a new way to
get inertia.

Currently the card will show up, and the text is correct, but it's not centered and sized correctly. Please finish the UI for this feature so that we can begin to work on the user notes functions for this section.

There are several components that you removed and are no longer required for the app to function. This has left some functions, methods, variables, etc behind that are cluttering scripts as well as the autoload.

You will need to go through starting with the autoload, and compare variables in there with what you actually use in the carousel scenes, journal save/load functions, and anything else you spot.

It's time to begin building out a settings menu, so I need to think of what style of menu I'd like to make.

left loading, top loading, bottom loading, centered with margins, animated/rotating icons etc.

I'll need to make an autoload most likely to support most settings.

I'll also need to have persistent data set up for this autoload as well.

Features:

• App settings (autosave, password protect/fingerprint, accessibility features?, Saving/Loading settings?, sharing settings?)
• Deck Settings(Deck Core, continuity, pick cards for me, user notes locked/unlocked)
• Sound settings(music, UI feedback, etc)

Should just be a simple gear icon, and make it modal in some way regardless of the direction

needs research

I haven't even thought to build for this, but I need to start thinking of it now, so here's the issue for it.

I need to have it so the user can pull cards, leave the scene to look at the guide or something else, and then be able
to go back to the scene without anything changing. I'll need something that can break the process down into stages,
with the ability to continue where one has left off. This will mean likely a rewrite of the current api for all scenes in the
draw cards process.

Features:

• As soon as a spread is chosen, begin saving the progress. Once a spread has been chosen, create an autosave file and give it
  a name that is auto generated
• Allow the user to navigate to other sections of the app without losing their spot - This may or may not mean saving and loading
  the scene each time they do this, but I should expect to have at least one function doing this, so I might as well write for longevity.
• Note when a reading was incomplete or unfinished in the save file itself, so the system knows the difference
• Write better api for populating incomplete reading data into scenes
  • This means working out a better way to modify the database to change what cards are in global.carousel_choice, any other
    global vars related to current focus/center card info etc, and how many cards are currently displayed as chosen in accumulative
    layout tscn.

This could open an opportunity for me to build in the undo button for chosen cards, so I might as well do it while I'm at it.

Just (a minute ago) added spread position text boxes and connected spread position dictionary from global
so that when the user is asked to choose the current card, they will be presented with information about the current
position in the spread (position 1 is 'your partner' vs position 2 is 'you' vs position 3 is 'your compatibility' etc)

Seeing as there are:

number of cards in the spread
spread description
spread position names
spread position description/interpretation

and then possibly an interpretation guide for each spread,

I need to think ahead here to what the best way to present this info is, and to add these features.

Reply to this post when you have added any feature related to spreads in the draw cards process

In order to make this feasibly maintainable, I need to refactor and reorganize all existing scripts.

This includes:

• Renaming variables and functions for legibility and consistency across the app
• Tidying up all _ready(): setup and instantiation lines into relevantly named functions for legibility(see finitecarousel.tscn)
• reordering all functions in chronological order in the script
• Research techniques for simplification, organization, and coherency in programming(modularity, single responsibility principle, etc)
• Code Comments !!! Explain what you're doing, not just for you now, but future you who hasn't looked in months, and for other coders, too.

Start small, by addressing the main scene needs, and then moving forward in UX flow.