At the ending of 2022 and beginning of 2023 I had enough of a Veridissimilitude build for a release, but the scope increased.

The previous build was one for all of the obvious scope increases and the next build will be one for all of the non obvious scope increases and the previous and next builds, through such, are of the same size. What are these two builds' scope increases? Modeling Power, my programme and game engine, which Veridissimilitude and all of my other projects will eventually move to. I had the options of releasing two builds (One for the work side and one for the play side) or one build (One for the work and play sides) and opted against two and for one. Why? So I'm able to continue releasing builds with a balance.

I am spending 2023 at ordering, organising, and documenting Power, Veridissimilitude, and all of my other projects and their past (What I'd done), present (What I'm doing), and future (What I'll do) and at analysing and designing Power and Veridissimilitude, so I may, eventually, begin Power - 0.0.6.0, 0.0.7.0, 0.0.8.0, and 0.1.0.0 and end Veridissimilitude - 0.2.1.0.

So, at 2024, build releases will eventuate again.

And my bad, the worst, health and too many disasters for me to be able to count continues through all of such, such being what's making my abilities to make things as they are also.

It's time for me to say all of what I will have to say.

The bad: Through the years bad health, the worst, has, is, and will be making the difficulty of working extremely hard and it continues turning harder, harder, and harder to the hardest. Which, as of a year or so backwards, I know the reason for it. I'm dying and I'm doing my best not to. Between then and now I've been ordering and organising things, reflecting my work to people who mirror them so, if I die, they're able to turn the private parts of it public. And I'm trying to move from a house which isn't a home to one which is, with an amount of time of being houseless between such, as it's one of the things I'm have to do for my health (The stressfulness of being where and when I am is a part of what's bringing me to death) also.

The good: Veridissimilitude (Which, through the thinking and feeling I've been doing, had its name changed) has a part build, the largest one I've done at (It's worth about four average size ones), being released. The point of it is doing all of the many new things (The list is a length of 352) so I'm able to return to redoing all of the few old things (Which will be through one part build and one whole build) and have it be good enough. And as always, if you wish to support the continuing of these things, I have a Patreon at The Leviathan Eternal also.

The subtractions, changes, and additions are:

Input.
Reordered the Veridissimilitude core's useage and naming of keyboard and mouse released and pressed events.

Keyboard input.
Reordered the keyboard input core. Added storage for the keyboard input's key typed event's state, which was the only event between the keyboard and mouse inputs which didn't have one. Fixed some of the keyboard input's count types, which weren't stating if they hadn't/had a maximum. Added H to the keyboard inputs. Changed some of the keyboard inputs (The ones which are for neutral behaviours, not negative or positive ones) from using Right - Alternate to using Right or Left - Alternate. Added keyboard inputs for changing action timer's size from 0 seconds to 10 seconds, Left (Downward) or Right (Upward) - Alternate and B. Changed keyboard input for changing action timer's act state's input off or on, from Alternate and B to Alternate and C. Changed keyboard input for changing action timer's act state's output off or on, from Alternate and C to Alternate and E. Changed keyboard inputs for changing action timer's size action count's output type from 1 to 2, from Alternate and E and Standard - 1 (For the present size) or 2 (For the present action) to Alternate and F and Standard - 1 (For the present size) or 2 (For the present action). Changed keyboard input for changing audio's state off or on, from Alternate and F to Alternate and G. Changed menu and encounter state's keyboard inputs for changing user's action's alter try type negative and neutral or neutral and positive, from Alternate, G, and Standard - 0 (For the action's side or sides and user or users), 1 (For a single side and single user), 2 (For a single side and multiple users), or 3 (For multiple sides and multiple users) to Alternate, H, and Standard - 0 (For the action's side or sides and user or users), 1 (For a single side and single user), 2 (For a single side and multiple users), or 3 (For multiple sides and multiple users). Added and changed the timings for all of the added and changed keyboard inputs. Fixed the game state's option page's Left and Right timing, when entering on to an option which is meant to have abnormal timing (Of which 4 exist: Action timer - Size and Second action count - In and User power - Ours and Theirs). Fixed the game state's option page's keyboard input's timing, which would do so wrongly when pressing an input (Left or Right) with specialised timing (The time between the first and second triggers being 0.2 seconds and time between the second, third, and all others being 0.1 seconds), entering in to the option's page, and entering on to an option which has the same specialised timing, making the time between the second, third, and all others triggers being 0.2 seconds. Fixed the transversion state to alter A, C, and E's timings when Left - Alternate is pressed. Fixed the transversion state's Left - Alternate and A timing, which was undone when Right - Alternate was depressed. Fixed the transversion state's movement inputs to deny movement when Left - Alternate and A, C, or E are pressed. Changed the keyboard (Enter) input which triggers (When the user opts the game state's game page's general or specific runs' save or load options) the second window's creation's (When the first window is unfocused and the second window is focused) state to off, if it's on, so it's not on, when the second window's destruction (When the first window is focused and the second window is unfocused) is triggered, and don't trigger the second window's creation again.

Mouse input.
Reordered the mouse input core. Changed the mouse input's move event to undo a drag event, if one does exist. Changed the mouse input's drag event to undo a move event, if one does exist. Changed the mouse input's exit event to undo an enter event, if one does exist. Changed the mouse input's enter event to undo an exit event, if one does exist. These are behaviours shared by the keyboard and mouse inputs' release and press events and exist so the last of a collection of opposite events is what's prioritised as eventuating. Added storage for mouse input's released and pressed event's states, times, count types (If they haven't/have a maximum), counts, and count maximums. Added the mouse input's future times (The point for the present times to reach for an additional count), count types, and count maximums, per game state. Added the mouse input's future times' altering logic (So the second repeat and forwards are shorter), per game state. Added mouse input move and drag state and translation values to the Veridissimilitude core, to have a permanent storage of such, not only the temporary storage of the events themselves (Which only exists when they eventuate). Added the mouse input's storage's memory management (Creating them, altering their values (To neutralise them), and destroying them). Added the ability of remapping the mouse input's translation from external values (Dependent of the dynamically sized window) to internal ones (Dependent of the staticly sized video for said window), so it will succeed if the window's size is altered. Added mouse input: Did so for the Left key for the keyboard input's Escape key (Did so for the game, transversion, menu, and encounter states), the translation for the keyboard input's Arrow keys, altering the option to where the mouse is translated to (Did so for the game, transversion, menu, and encounter states), the Right key for the keyboard input's Enter key (Did so for the game, transversion, menu, encounter, encounter ending, and game ending states), the Middle key on the game state's interface's arrows for option altering, when the ability to alter an option is what they exist for (Did so for the game state), the Middle key on the game and encounter states' interface's arrows for scrolling, when the ability to scroll is what they exist for (Did so for the game and encounter states), and the Middle key at the transversion state for the user's movement, using the mouse's translation to determine the user's movement's direction. Changed the mouse (Right button) input which triggers (When the user opts the game state's game page's general or specific runs' save or load options) the second window's creation's (When the first window is unfocused and the second window is focused) state to off, if it's on, so it's not on, when the second window's destruction (When the first window is focused and the second window is unfocused) is triggered, and don't trigger the second window's creation again.

Video output.
Changed the game and game ending states' video from static to dynamic. Changed the game state's planet's sea video to better, its edge was too rough. Changed the game state's planet's darkening video to better, it had empty spaces. Changed the game state's knowledge's input page's text, reordering some of it, the transversion state's 'To Menu' and 'Movement' parts of it. Added 'Action timer -' to the action timer interface and the game state's options page's texts. All of which are to make the texts align to the code and be easier to know the meaning of. Added action timer's size to the action timer interface and the game state's options page. Changed the game state's option page's text from 'Action Timer:' to 'Action timer:'. Changed the action timer interface and the game state's option page's texts from 'Act - In state:' to 'Act state - In:', from 'Action count for the present second - In:' to 'Second action count - In:', from 'Act - Out state:' to 'Act state - Out:', from 'Action count for the present second - Out:' to 'Second action count - Out:', from 'Action count for the present second - Out type:' to 'Second action count - Out type:', from 'For the present second' to 'For the present size', from 'Action time - Length in:' to 'Action size - In:', from 'Action time - Sleep in:' to 'Sleep size - In:', from 'Action time - Length out:' to 'Action size - Out:', and from 'Action time - Wake out:' to 'Wake size - Out:'. Changed the action timer interface's translation and texts' translation transformation, to centre it. Changed the action timer interface's and interface's texts' visibility, by making it less so, so it hides less of the other video outputs. Changed the game state's option page's video and translation transformation to be enough for the changed texts and aligned with said texts. Changed the game state's knowledge's creation page's texts from 'David Mold - RealJ - Version 3.6' to 'David Mold or DM Interactive - RealJ - Version 3.6', from 'Xinox Software - JCreator - Version 4.50.010' to 'Xinox Software - JCreator - Version 4.50.010 - LE (Lite Edition)', from 'Oracle - Java' to 'Oracle - Java - SE (Standard Edition) - 7 Dolphin - Microsoft Windows - 32 Bit', from 'Adobe - Photoshop - Version 7.0 and CS6 (Creative Suite 6) Version 13.0.1 - Extended - 32 Bit' to 'Adobe - Photoshop - Version 7.0 - Microsoft Windows and CS6 (Creative Suite 6) Version 13.0.1 - Extended - Microsoft Windows - 32 Bit', from 'Adobe - Flash Professional - CS3 (Creative Suite 3) Version 9.0' to 'Adobe - Flash Professional - CS3 (Creative Suite 3) Version 9.0 - Microsoft Windows', from 'SWF (Shockwave Flash or Small Web Format)' to 'Adobe - SWF (Shockwave Flash or Small Web Format)', and from 'MIDI (Musical Instrument Digital Interface)' to 'MIDI (Musical Instrument Digital Interface) Manufacturers Association - MIDI (Standard MIDI (Musical Instrument Digital Interface) File)'. Changed the game state's knowledge's creation page's video and translation transformation to be enough for the changed texts and aligned with said texts. Changed the game state's knowledge's need page's text from 'Oracle - Java - 7 Update 80 Dolphin' to 'Oracle - Java - SE (Standard Edition) - 7 Dolphin'. Changed the game state's knowledge's need page's video and translation transformation to be enough for the changed texts and aligned with said texts. Changed some of the game state's knowledge's input page's texts (The ones which were changed from using Right - Alternate to using Right or Left - Alternate) from 'Right - Alternate' to 'Alternate'. Added and changed the texts for all of the added and changed keyboard inputs at the game state's knowledge's input page. Changed the game state's knowledge's input page's texts from 'selection' to 'option', from 'To' to 'Move to', and from 'Keyboard - Alternate and E and - 1 (For the present second) or 2 (For the present action)' to 'Keyboard - Alternate and E and Standard - 1 (For the present second) or 2 (For the present action)'. Changed the game state's knowledge's input page's 'Game and Menu' state's text from 'Mouse - Move' to 'Mouse - Middle Button (Invisible) or Move (Visible)'. Changed the game state's knowledge's input page's 'Transversion' state's text from 'Keyboard - A, C, D, E, Q, W, X, and Z' to 'Keyboard - A, C, D, E, Q, W, X, or Z'. Changed the game state's knowledge's input page's 'Menu and Encounter' state's text from 'Alternate, G, and 0 (For the action's side or sides and user or users), 1 (For a single side and single user), 2 (For a single side and multiple users), or 3 (For multiple sides and multiple users)' to 'Keyboard - Alternate, G, and Standard - 0 (For the action's side or sides and user or users), 1 (For a single side and single user), 2 (For a single side and multiple users), or 3 (For multiple sides and multiple users)'. Changed the game state's knowledge's input page's 'Encounter' state's text from 'Keyboard - Left, Right, Down, or Up or Mouse - Move' to 'Keyboard - Left, Right, Down, or Up or Mouse - Middle Button (Invisible) or Move (Visible)'. Changed the game state's knowledge's input page's video and translation transformation to be enough for the changed texts and aligned with said texts. Changed the menu state's master, status, abilities, and equipment page's user's/users experience gauges from wholy visible to partly visible (50%). Changed the menu state's master, status, abilities, and equipment page's user's/users experience gauges from red to white. Changed the encounter ending state's user's/users experience gauges from wholy visible to partly visible (50%). Changed the encounter ending state's user's/users experience gauges from red to white. Changed the encounter state's user's/users action gauges from red to white. Changed the encounter state's user's/users' action option video's width part of the size to better, continuing its alignment with action's video. Changed the encounter state's user's/users' sub action video's width part of the size to better. Fixed the encounter state's user's/users' sub action transformation's width part of the translation. Changed the encounter state's user's/users' non 'Item' sub action's cost and 'Item' sub action's count video's width part of the size to better, continuing its alignment with sub action's video. Changed the encounter state's user's/users' non 'Item' sub action's cost and 'Item' sub action's count transformation's width part of the translation to better, continuing its alignment with sub action's video. Fixed the encounter state's user's/users' action's and sub action's downward and upward arrows videos' layering, which had it as farther than the option video and text when it's meant to be nearer than such. Changed the encounter state's user's/users' sub action's upward arrow transformation's height part of the translation to better, to align with the option video and text.

Audio output.
Changed audio from Game Ending - Bad to Transversion - 2. Changed Game, Transversion - 1, and Transversion - 2 audio to better. Added Game Ending - Bad audio. Changed when the user opts the game state's game page's general runs' load options to turning the audio's state off or on when what it's loading is different.

External - Saving and loading.
Added the game state's game page's general run save/load game options and specific run old/new game options. Changed the general run cheat state to false when a general run is loaded. Changed the specific run cheat state to false when a specific run is loaded. Created the second window, when the user opts the game state's game page's general or specific runs' save or load options. Destroyed the second window, when the user opts the folder or/and file which they wish to save to or load from. Changed when the user opts the game state's game page's general or specific runs' save options to saving project name (Veridissimilitude), project number (0.2.1.0), and element (General or specific) values. Changed when the user opts the game state's game page's general or specific runs' load options to loading project name (Veridissimilitude), project number (0.2.1.0, 0.2.1.? (The fourth value: 1 or higher), 0.2.?.? (The third value: 2 or higher. And the fourth value: 0 or higher), 0.?.?.? (The second value: 3 or higher. And from the third to the fourth values: 0 or higher), or ?.?.?.? (The first value: 1 or higher. And from the second to the fourth values: 0 or higher) (The ranges are so it knows)), and element (General or specific) values and determine through such if loading is unable or able to continue. These values are for identifying compatible folders and files and what's different between the project number value's saving and loading (If I do know a past version is compatible: It'll be inside of the range. And I don't know if a future version is compatible, so it'll be inside of the range also) behaviours is for backwards and forwards compatibility.

External - Other.
Fixed the menu state's determining of if it has to change to the game ending state, when a user action eventuates, which was checking a user's/users' health and wasn't including the user's/users' power (The difficulty option which alters all of the user's/users' values) with such a determination. Fixed the menu state's equipment page's alter from item to user action behaviours, when subtracting an item from an equipment slot and adding it to an inventory slot (Filling an empty one), which wasn't making a user action for each user of our side. Fixed the menu state's inventory page's item's use option's origin randomisation and the encounter state's animation determining at the state's beginning (Death, low health, or stand), life timers running, their side's/sides' user action's destination randomisation, emptying/randomising of a user's/users' action gauge/action gauges, when a user action eventuates and it brings a user's/users' health from negative to positive or from positive to negative, and determining of if it has to change to the encounter ending or game ending state, when a user action eventuates, which was checking a user's/users' health and wasn't including the user's/users' power (The difficulty option which alters all of the user's/users' values) with such determinations. The reason these user power fixes are required? If it's checking for a threshold of a user's health, to know when to do a thing, a user's power isn't 1 (So it's a value which makes a user's health lower or higher than normal) and a user's power isn't being used through the checking: The threshold triggers lower or higher than it's meant to. Fixed the encounter ending state's alter from item to user action behaviours, when adding inventory item awards one is rewarded with to an inventory item slot (Filling an empty one), which wasn't making a user action for each user of our side. Changed the 'Attack', 'Magic - Destruction', 'Magic - Restoration', 'Skill - Donation', 'Item - Health Restore', 'Item - Mana Restore', and 'Item - Combo Restore' user action to fail at their destination/destinations if their destination/destinations is a user with the flee condition. Some of the user actions require this behaviour, as nothing makes it so friends or enemies are unable to try at such and some enemies will try at such (Dependent of an enemy's intelligence (How stupid or smart they are), an enemy may have an action which requires time and is unable to change what it's targeting, when inside of the middle of such (So the friend/friends is/are able to temporarily be put in to the safety of the flee condition, for a turn or so), or an enemy may have an action which is targeting a length, area, or volume versus the user/users inside of it (A bombing)). Changed the 'Flee' user action to acting as if users who have the flee condition and are outside of the events are a part of the user action, such a change means a partly fled team has an easier difficulty at changing to a wholy fled team. Fixed the 'Flee' user action, which was determining the origin side's flee count as 0, for all of the cases (It was only cycling through the user action's origin specific list (Which normally only has users who have the criteria to be an origin (Having positive health, not having the flee condition, having a full action gauge (Which is impossible if they have the flee condition), and being a part of the action queue (Which is impossible if they have the flee condition))) to check, not the origin side itself (All of the users)). So it was acting as if users who have the flee condition and are outside of the events are not having the flee condition and are inside of the events and, if such eventuates, balancing each user's part of the flee action with the wrong (A larger) team size and making them perform worse than they're meant to. Added health, mana, and origin/destination powers (The trust values) degeneration and generation to the game state, if a specific run does exist. Changed the game state's option page's user power's theirs option to be applied to an infinite amount of their sides. Fixed the game state's option page's user power options, which were only being applied to a user at their creation (Okay for theirs, as the user power option wasn't changeable whilst they existed, but not ours, as the user power option was). Fixed the game state's option page's user powers' options' alterations (Which were moving the smallest amount outside of with enough alterations), to keep their values inside of their ranges. Added a slot to the game state's collection's audio page for the Transversion - Leviathan audio, but not the audio itself, so it's an empty slot. Changed the game state's collection's audio page's input and output code, text, video, and translation transformation for the added Transversion - Leviathan slot. Changed the game state's collection's audio page's audio triggering to only end old audio if the slot has beginnable new audio. Fixed one of the play state slots (The storage for play events. It was the transversion state's level 1.6's which was broken), which wasn't defaulting (A loop failure). Changed Transversion - Leviathan to unlock when the transversion state's level 1.6 has been reached. Changed the encounter state's user translation transformations to be smarter and dynamic (1 dimension, centred, and able to manage all amounts of users (Inside and outside of the maximum of 4)) for our side. Changed the encounter state's user translation transformations to be smarter and dynamic (2 dimensions (With a 1st dimension maximum of 2), centred, and able to manage all amounts of users (Inside and outside of the maximum of 4)), when it's a normal encounter, or static, when it's a Leviathan encounter, for their side. Change the encounter state's users with the flee condition to be invisible. The encounter state will, when the subtracted user action's video and text parts (Which are triggered when a user action eventuates) have been readded, have buffers for health, mana, origin/destination powers (The trust values), and the flee condition, so I'm able to synchronise how things are shown to the user. What it will mean is users with the flee condition added to them will wait through the user action's video and text parts to begin and end running to turn the user invisible. As it is, the invisibility is instantaneous. Changed the encounter state's life timers to not run for your side's users with the flee condition. Changed the encounter state's action gauge speed calculations (Which is through the highest user's speed and the ratio between such and all other users' speed) to exclude users with the flee condition. Changed the encounter state's action gauges to begin as empty for users with the flee condition (A user may have the flee condition when an encounter begins (A more surprising encounter than normal, so surprising as to exclude some of the users out from it), so this is to have the behaviour for such). Changed the encounter state's action gauges to not run for users with the flee condition. Changed the encounter state to empty a user's action gauge if they haven't the flee condition (What's different, so it doesn't collide with other behaviour) and their health changes from positive to negative or neutral (Through a user action). Changed the encounter state to randomise a user's action gauge if they haven't the flee condition (What's different, so it doesn't collide with other behaviour) and their health changes from negative or neutral to positive (Through a user action). Changed the encounter state to subtract a user from the action queue if they haven't the flee condition (What's different, so it doesn't collide with other behaviour), they have a full action gauge, and their health changes from positive to negative or neutral (Through a user action). Changed the encounter state to add a user to the action queue if they haven't the flee condition (What's different, so it doesn't collide with other behaviour), they have a full action gauge, and their health changes from negative or neutral to positive (Through a user action). Changed the encounter state to empty a user's action gauge if they have positive health and the flee condition is added to them (Through a user action). Changed the encounter state to randomise a user's action gauge if they have positive health and the flee condition is subtracted from them (Through a user action). Changed the encounter state to subtract a user from the action queue if they have positive health and a full action gauge and the flee condition is added to them (Through a user action). Changed the encounter state to add a user to the action queue if they have positive health and a full action gauge and the flee condition is subtracted from them (Through a user action). Changed the encounter state's their side's/sides' user action's destination trying to exclude users with the flee condition. Changed the encounter state's their side's/sides' user action's destination trying to cycle their side's/sides' user action queue when failing. Changed the encounter state's their side's/sides' user action queue's cycling to do so finitely (One time, for each of the users who are queued). Changed the encounter state's movement to the encounter ending state to eventuating if all of the users of our side have negative or neutral health or have the flee condition. Changed the encounter state's movement to the encounter ending state to eventuating if all of the users of their side/sides have negative or neutral health or have the flee condition.

Internal.
Changed the error handler to make messages for all of the errors which may eventuate (The Veridissimilitude, Action Timer, and Out Audio Synthesis Object cores were only doing so for some of them). Renamed some of the values when outputting them from the master core and inputting them to the non master cores, which makes things more self documenting. Added the Power core. Added a value for the Power core's state. Changed the Power core's action behaviour to do so if its state value is true. Added a value or values for the Power core's Action Timer, In, and Out core child or children. Added inputs and outputs for all of the Power core's values. Added a value or values for the Action Timer core's Power core parent or parents. Added inputs and outputs for the Action Timer core's parent or parents value or values. Added a value for the In core's state. Changed the In core's action behaviour to do so if its state value is true. Added a value or values for the In core's Power core parent or parents. Changed the In core's In Keyboard and In Mouse core child or children value or values to be a dynamic storage. Added inputs and outputs for the In core's state and parent values. Added a value for the In Keyboard core's state. Changed the In Keyboard core's action behaviour to do so if its state value is true. Added a value or values for the In Keyboard core's In core parent or parents. Added inputs and outputs for the In Keyboard core's state and parent values. Added a value for the In Mouse core's state. Changed the In Mouse core's action behaviour to do so if its state value is true. Added a value or values for the In Mouse core's In core parent or parents. Added inputs and outputs for the In Mouse core's state and parent values. Added a value for the Out core's state. Changed the Out core's action behaviour to do so if its state value is true. Added a value or values for the Out core's Power core parent or parents. Changed the Out core's Out Audio core child or children value or values to be a dynamic storage. Added inputs and outputs for the Out core's state and parent values. Added a value for the Out Audio core's state. Changed the Out Audio core's action behaviour to do so if its state value is true. Added a value or values for the Out Audio core's Out core parent or parents. Changed the Out Audio core's Out Audio Synthesis core child or children value or values to be a dynamic storage. Added inputs and outputs for the Out Audio core's state and parent values. Added the Out Audio Synthesis Object core's general state and general power to the Out Audio Synthesis core to be its state and power. Added the Out Audio Synthesis Object core's general state and general power behaviours to the Out Audio Synthesis core. Added a value or values for the Out Audio Synthesis core's Out Audio core parent or parents. Changed the Out Audio Synthesis core's Out Audio Synthesis Object core child or children value or values to be a dynamic storage. Added inputs and outputs for the Out Audio Synthesis core's state, parent, and power values. Subtracted the Out Audio Synthesis Object core's general state and general power. Subtracted the Out Audio Synthesis Object core's general state and general power behaviours. Changed the Out Audio Synthesis Object core's specific state and specific power to be its state and power. Changed the Out Audio Synthesis Object core's specific state and specific power behaviours to be its state and power behaviours. Added a value or values for the Out Audio Synthesis Object core's Out Audio Synthesis core parent or parents. Subtracted inputs and outputs for the Out Audio Synthesis Object core's general state and general power values. Changed inputs and outputs for the Out Audio Synthesis Object core's specific state and specific power values to be for its state and power values. Added an input and output for the Out Audio Synthesis Object core's parent value or values. Transformation Static core, changed it to be the Transformation Static 2 Dimension core. Transformation Dynamic core, changed it to be the Transformation Dynamic 2 Dimension core. Transformation Dynamic 2 Dimension core, subtracted its action behaviour. Added the Physic 2 Dimension core. Added the Transformation Dynamic 2 Dimension core's action behaviour to the Physic 2 Dimension core to be its action behaviour. Added all of these cores' storage's memory management, creating them, altering their values (To neutralise them), and destroying them. These are to align it with Power, a project which is for the creation of programmes and games. Changed the names of the value cores to align them with the naming of all of the other cores and values. Merged the Action Timer core's values from act in and out states to act state, from action count second in and out to action count second, and action time length in and out to action time length. Added a value for the Action Timer core's size, which is the amount of time between determining the action count out, if the action count out types type is 1 (For the present size). Renamed the Action Timer core's values from action count second to second action count, from action time length to action size, from sleep time length in to sleep size in, from wake time length out to wake size out, from action count second out type to second action count out type, and from action count second out alter time to second action count out alter time. Changed the Action Timer core's second action count out type's type 1 from for the present second to for the present size. Moved the Action Timer core's second action count values to before action size, wake size in, and sleep size out. Changed the Action Timer core's sleep size in to 0, if act state in is false, which was keeping its value from when act state in was true. Changed the Action Timer core's wake size out to act size out, if act state in is false, which was being determined by act size out and sleep size in when sleep size in is meant to be 0. Changed the Action Timer core's sleep size in to not be altered to 0, if lower than 0 or action size in, or action size in, if higher than action size in, which was being determined as wrong and was making other determinations which were using the wrong sleep size in wrong also. Changed the Action Timer core's wake size out to be altered to action size out, not action size out minus sleep size in, if sleep size in is lower than or equal to 0, which was being determined as wrong and was making other determinations which were using the wrong wake size out wrong also. Changed the Action Timer core's sleep size in to be altered to action size in, not action size in minus wake size out, if wake size out is lower than or equal to 0, which was being determined as wrong and was making other determinations which were using the wrong sleep size in wrong also. Changed the Action Timer core's ability of sleeping to do so for sleep size in values higher than action size in, which balances when the game's past action under slept at such an extreme (Which is the randomness of computer behaviour). Changed the Action Timer core's second action count out type's type 1 (for the present size) from altering second action count out each second to altering it each size. Changed the Action Timer core's second action count out alter time from being altered to the present time (Which may not be equal to action time present) to being altered to action time present, to synchronise it with all of the other code. Changed the Action Timer core's act state's input to check for differences between the old and new act state. Changed the Action Timer core's act state's input to make sleep size in be altered to 0, if act state in is false. Changed the Action Timer core's act state's input to make second action count out be determined and second action count alter time be altered to action time present, if act state out is false and second action count out type is for the present size, to synchronise it with all of the other code. Changed the Action Timer core's act state's input to make second action count out be determined and second action count alter time be altered to action time present, if act state out is false and second action count out type is for the present action, to synchronise it with all of the other code. Changed the Action Timer core's act state's input to make second action count alter time be altered to action time present, if act state out is true and second action count out type is for the present size, to synchronise it with all of the other code. Changed the Action Timer core's second action count out type's input to check for differences between the old and new act state. Changed the Action Timer core's second action count out type's input to make second action count out alter time be altered to action time present, if act state out is true, the old second action count out type is not for the present size and is not for the present action, and the new second action count out type is for the present size or for the present action, to synchronise it with all of the other code. Changed the Action Timer core's second action count out type's input to make second action count out alter time be altered to action time present, determine second action count out, and make action count be altered to 0, if act state out is true, the old second action count out type is for the present size, and the new second action count out type is not for the present size, to synchronise it with all of the other code. Changed the Action Timer core's second action count out type's input to make second action count out alter time be altered to action time present and determine second action count out, if act state out is true, the old second action count out type is for the present action, and the new second action count out type is not for the present action, to synchronise it with all of the other code. Changed some of the Action Timer, Out Audio Synthesis Object, User, and User Action General cores' external code useage to be more explicit. Changed the Out Audio Synthesis core's power and Out Audio Synthesis Object core's power from an 8 bit whole number to a 64 bit part number. Cleaned the Out Audio Synthesis Object core's action event handling. Changed the Out Audio Synthesis Object core's timing to better. Fixed the Out Audio Synthesis Object core's timing type conversions, which meant it wasn't stepping to the right point at a loop. Changed the Out Audio Synthesis Object core's use translation transformation to return to 0 when the use count reaches the use count maximum and returns to 0. Changed the Out Audio Synthesis Object core's audio use count versus use count maximum to stop the audio if above, not only equal to. Changed the Out Audio Synthesis Object core's use translation transformation input to loop use translation transformation and use count when it puts use translation transformation outside of the useable range (Less than 0 or equal to or more than size). Changed the Out Audio Synthesis Object core's use translation transformation input to return the use translation transformation and use count to 0 and stop the audio when it puts the use count outside of the useable range (Less than 0 or equal to or more than use count maximum (When use count type says to use use count maximum)). Changed the Out Audio Synthesis Object core's use count type input to return the use translation transformation and use count to 0 and stop the audio when it puts the use count outside of the useable range (Equal to or more than use count maximum (When use count type says to use use count maximum)). Changed the Out Audio Synthesis Object core's use count input to return the use translation transformation and use count to 0 and stop the audio when it puts the use count outside of the useable range (Less than 0 or equal to or more than use count maximum (When use count type says to use use count maximum)). Changed the Out Audio Synthesis Object core's use count maximum input to return the use translation transformation and use count to 0 and stop the audio when it puts the use count outside of the useable range (Equal to or more than use count maximum (When use count type says to use use count maximum)). Changed the Out Audio Synthesis Object core to have smarter behaviour for all of its values' inputs (Checking if its values' memories are the same or different as the ones' memories being inputted, to know if a behaviour isn't or is meant to eventuate. It was only doing so for some of them). Generalised the Menu core's determining of value and dimension value, to have the negative and positive cases use similar enough equations. Fixed the Menu core's determine value behaviour to subtract one value count less, if value is equal to or more than value count. Fixed the Menu core's determine dimension value behaviour to subtract one dimension value count less, if dimension value is equal to or more than dimension value count. These were making bounding break (To the point of crashing) when changing from a too high value (Outside of the range) to inside of the range. Changed the Menu core's determine value behaviour to run the alter from value to dimension value behaviour, if a change eventuates. Changed the Menu core's determine dimension value behaviour to run the alter from dimension value to value behaviour, if a change or changes eventuates. Changed the Menu core's alter from value to dimension value behaviour to run the determine value behaviour. Changed the Menu core's alter from dimension value to value behaviour to run the determine dimension value behaviour. These are to make it so value (Used internally, for the behaviours) and dimension value (Used externally, for the user's inputs and outputs) are synchronised all of the time. Changed the Menu core's determine dimension value out beginning and ending behaviour, which alters beginning or/and ending, if ending - beginning doesn't equal count - 1: To do so a second (50%) of the value beginning and ending are to be altered through, if they are to be altered through an even value, to do so a second (50%) of the value beginning is to be altered through and ceiling (Round upwards) its altering, if it or/and ending are to be altered through an odd value, and to do so a second (50%) of the value ending is to be altered through and floor (Round downwards) its altering, if it or/and beginning are to be altered through an odd value. These are to balance the behaviours, from stepping beginning and ending at different (Beginning first and, if beginning doesn't have enough of a range to move, ending second) times to the same times. Changed the Menu core to have smarter behaviour for all of its values' inputs (Checking if its values' memories are the same or different as the ones' memories being inputted, to know if a behaviour isn't or is meant to eventuate. It was only doing so for some of them). Changed the Menu core's value count input to run the determine value and determine dimension value out beginning and ending behaviours. Changed the Menu core's dimension value count input to run the determine dimension value and determine dimension value out beginning and ending behaviours. These are to make the Menu core resizeable. Fixed the Menu core's value input, which was failing at bounding value, breaking the determine value (Which is meant to bound value) behaviour, and making it crash. Fixed the Menu core's dimension value input, which was failing at bounding dimension value, breaking the determine dimension value (Which is meant to bound dimension value) behaviour, and making it crash. Changed the Menu core's dimension value out type and dimension value out count inputs to run the determine dimension value out beginning and ending behaviour. This is to make the Menu core's range of what's inputtable and outputtable resizeable. Added the Menu core's inputs for some of the values (Dimension value out beginning and dimension value out ending, which are for knowing the range of what's inputtable and outputtable). Changed the Menu core's dimension value out beginning input to alter ending to be beginning + count - 1 and run the determine dimension value out beginning and ending behaviour. Changed the Menu core's dimension value out ending input to alter beginning to be ending - count - 1 and run the determine dimension value out beginning and ending behaviour. These are for some of the mouse input behaviours (The ones which change the range of what's inputtable and outputtable). Changed the User core to have smarter behaviour for all of its values' inputs (Checking if its values' memories are the same or different as the ones' memories being inputted, to know if a behaviour isn't or is meant to eventuate. It was only doing so for some of them). Changed the User core to have inputs and outputs for some (All of the ones which didn't have them) of its values, so they're able to be a part of what's saved and loaded, when the user opts the game state's game page's general or specific runs' save or load options. Changed the user level alter cheat to check if the user storage is full, not if a specific run exists, as it's the more direct check for what it's trying to do. Subtracted the Action Specific core's parent and child states, knowing its parent's and child's (The storage itself) state is enough. Optimised the Action General core's useage of the Action Specific core's parent and child when searching through the tree to know if it's a useable action. Specialised the timers for the game and game ending states' videos and transformations, which makes things more self documenting. Cleaned some of the game state's option page's code. Added some of the game state's collection's audio page's code documentation. Optimised some of the encounter state's input and output code. Fixed the encounter state's user video layering (Which is doubled, to have two way relationships. Layers' videos and videos' layers), which was mishapening one way of its relationships (Videos' layers) and making it unuseable. Added some of the encounter state's user life timers' (A part of what's used for determining the experience rewards) code documentation. Subtracted the encounter ending state's checks for some of the awards (Score, currency, and item), to continue counting through them, which were checking too many times. Fixed a memory management failure with each of the action timer's act state's input's and output's inputs. Fixed a memory management destruction failure, when destroying the user actions' (All of them) origin and destination specific lists. Fixed a memory management failure with the user destination power try type (The flag which says if the user's/users're trying for a negative (The enemies' normal) or positive (The friends' normal) action), which had no memory management for destruction (As it was only doing creation, each creation amounted to multiplying the memory being used (Each useage of the game state's game page's new and load options and each encounter would add to such)). Fixed a memory management destruction failure, when closing Veridissimilitude and destroying the user action destination powers (Trust values). Fixed a game state memory management destruction failure, when closing Veridissimilitude and destroying the user/users. Fixed a transversion state memory management destruction failure, when closing Veridissimilitude and destroying some of the transversion state's memory. Change when the user opts the game state's game page's specific runs' load options and a specific run exists to managing the specific run's memory's emptying and refilling the same way as when the user opts the game state's game page's specific runs' new options and a specific run exists.

I'm extremely hopeful the wait between builds is worth it for all of the people here and now.

The server and everything on it, including the site, have been returned to life, through 20 days of being otherwise. The server's software was changed, heavily, enough so to break things, and was done without my knowledge, so I didn't realise what eventuated before now.

Verisimilitude: Prototype is continuing, extremely slowly, it's at 63.938% done (If the things on the list are of an equal size, which they're not, the audio part unbalances things) or, at least, 25% (If the audio part is balanced). I plan on having a part release this year, late within it, and will continue releasing its audio on the way to such, for my Patreon supporters.

A part of why the slowness is I'm spending the majority of my time on organising, documenting, and mirroring all of my creations, so, when it's time to do more for them, they're ready for such, and are kept safe, between now and then. It's a lot to do and may eventually amount to non Verisimilitude: Prototype releases this year. I'm hoping for a whole release of the site (Which will bring it wholy up and all of my creations to the public side, not only Verisimilitude: Prototype) and a part release of Power (Which will be made publically useable, for the first time). Again, these are hopes, which may not eventuate this year. The things I'm doing, which lead to them, will be enough, to put me within a good position, for the future.

I have years' worth of events destroying me to try at undoing some of. And, whilst I'm not stopping work, I'm doing less, to make time for my health.

I've finished another build of Verisimilitude: Prototype, this one a public one. It may be a while to the next one, as I may be moving to a new house, so this will have to do for now.

Rasterised and changed the game and game ending screens and the Land And Air part of levels 1.4-1.6 to better. Created interface video files for the game state's main, option, knowledge, creator, creation, need, want, input, collection, audio, and highest scores pages and replaced black boxes with them. Created leftward and rightward video files for the game state's option page, using an arrow/arrows to show which direction/directions an option can be changed. Resized the game state's option page at the width axis and the creator, creation, need, want, and input pages at the height axis. Changed the game state's interfaces, exploration state's map and interface, and the encounter state's to 66.6% visible. Changed game screen's information to better, did so by subtracting "Developed By ..." and "Website ..." from the main page and adding the same information, done better, to the knowledge's creator's page, and did the same for the version, date, and time to the knowledge's creation's page. Centred the game state's "Press Enter" text at the width axis and the game ending state's "Over" part of the "Game Over" text at the height axis. Realigned the game state's game page's text and option page's everything at the width axis. At the game screen's knowledge's creator's page, changed name from The Leviathan Eternal to Leviathan Eternal and added web name (http://leviathan-eternal.com). At the game screen's knowledge's creation's page, added specific hardware, more specific software, and the types of things created with them. Doubled the exploration state's Land And Air part of levels 1.4-1.6's area elements, to match all other whole screen things. Centred encounter state's side/user text (It can't be exact, as different user types have different name lengths, but it's better). Moved the game ending state's Leviathan layer from under the lightening layer to over it. Subtracted the exploration state's visibility volume, the Land And Air part of levels 1.4-1.6, and maps, the encounter state's level and interfaces (Excluding the side/user selection arrows), and the encounter ending and the game ending states' everything's deformation transformation type useage (But not the values, them being a part of the transformation, other parts of which being needed), it being unneeded (Their deformations are 1, so useage of them does nothing).

Partly redid the Encounter - Leviathan audio, which is roughly half its planned length. Disabled the highest scores system if one of the cheat states is true.

A new build of Verisimlitude: Prototype, a small part release, for my supporters on Patreon only. So, if you wish to have it: This is the way. Now, on to the report. Changed the naming of some data, to be more consistent, changed the order of some data (The game state's), to be more consistent, and changed the casting of some data (The part number types), to be more consistent. Fixed the memory management of the audio collection data, which was failing at destruction and fixed a keyboard input thing, in which it did text events wrong, storing them as numbers representing the text, versus the text itself. Double buffered keyboard input, so its data can be safely accessed at any point, changed the mouse input's mouse wheel moved type from a 32 bits whole number to 8 bits whole number, undid a mouse input optimisation, an extreme one which made things too hard to read. It was a part of something I tried years ago, this part being the only part which wasn't undone, and double buffered mouse input, so its data can be safely accessed at any point. Fixed the blackening of the areas outside of the video output area, which are visible only when the window is non uniformly resized, for the application port (It was wrongly determining the existence of a resize event at each action, so was doing the blackening when it didn't need to).

Partly did the game state's menus, everything but the visual content specific to it (A background layer (A black area is temporarily used) and arrows to show what's doable), specifically: The game page, which has general run save/load game options (Which don't function) and logic to allow save functionality exclusively if a general run does exist and change save text to grey if a general run doesn't exist and which has specific run old/new and save/load (Which don't function) game options and logic to allow old functionality exclusively if a general run does exist, change the old text to grey if a specific run doesn't exist, allow save functionality exclusively if a general run does exist, change the save text to grey if a specific run doesn't exist, have the selection begin at "Specific - Old" if a specific run does exist, and have the selection begin at "Specific - New" if a specific run doesn't exist. The option page, which has action timer options: Its state, input state, output state, input count (Which should have a range of 1-999 per second), output type (Which should be "Per second" or "Per action"). An audio option: Its state. Difficulty options which have a range of 100-200% for your and their sides and storage for such. And a map option: Its state. The knowledge page, which has knowledge about the creator, the creation, the needs, the wants, and the inputs. The collection page, which has the audio player (For the 5 used and 3 unused songs) and highest scores page.

Changed the left and right key's timing for the game state. Changed highest scores so new highest scores equal to old highest scores will be under them, not over them. Added a general run identifying number, added a specific run identifying number, added a user identifying number, and used the specific run and user identifying numbers for the highest scores, to stop the same specific run and user's score's multiplying through multiple endings. Added a user name, added an interface on the game state's option page for the user name (It takes back spaces, spaces, lower and higher case letters, and numbers as inputs. It has a maximum length of 30 characters), and used the user name when altering the highest scores. Changed the specific run timer to time things in any state, whilst a specific run exists (The difference being it wouldn't do so at the game state (As, at the time I did so, the game state wasn't reachable through anything but the game ending state, at which point the specific run stops existing)). Changed level altering cheat to be doable in all of the game's states (If a specific run exists), added a general run cheat state, added a specific run cheat state, changed the cheat states to true when the level altering cheat is used, disabled saving the general run if the cheat state for it is true and changed the text to grey, changed the general run cheat state to false when a new general run begins, disabled saving the specific run if the cheat state for it is true and changed the text to grey, and changed the specific run cheat state to false when a new specific run begins. Changed map toggle from being doable in the game's exploration state to all of the game's states. In the menu system: Added the "Game" option to the list of first level options, which will lead to the game screen, if selected.

I had a hospital visit, for surgery, and, through complications, maybe wholy undoing said surgery, have been extremely unwell for a handful of days, and believe I'll continue to be for a while. I'll do my best to bring a public build to you, but can't promise when, as I truly need the rest. I'll let you know how everything goes, but, for now, at the very least I have a good amount of the work for it done. The remaining parts are video and audio, versus the code focus of this one.

It's been a long year so far, one of bringing many side priorities forward, which I've been waiting until now to do, many of which are for my work, but too qualitative to quantify, and too many of which for me to remember all of them so I can list them. I am through enough of them to be able to return to doing the next build of Versimilitude: Prototype (For which I've done a good amount of analysis, design, and audio (But none of the code) for so far), which is my highest priority at present, but will be repeating this pattern through the few builds after it, as I have many other things I need to do.

I may be moving to a different house, so a large amount of my time may be spent on it, for the next few months, trying to organise such. It's the only thing which will be decelerating Versimilitude: Prototype's progress, for a while, at this point.

It's time for another build of Verisimilitude: Prototype to be released, a smaller one, as some things are happening in my life which may cause slowness for a while, so I wanted to round the year with something more.

Cleaned comments (Some of which weren't up to my standard). Made more + (The act of positive signing values) cases within the code explicit. Made more floor (The act of flooring values) cases within the code explicit. Changed the timing of pressing the keyboard's left/right shift and D keys (Changes the action speed to try for) and left/right shift and L keys (Changes the user's characters levels) from 0 to 0.02 between repeats, so they'd be balanced if the game ran faster than normal. Added a general timer storage, for keeping track of the rate some things should be repeated, specifically: Events which happen per action, randomised ones more so (The encounter state trigger being a good example), as differences in game speed would otherwise mean they'll be tried less/more, despite the game otherwise running in real time. And continuing counters, only randomised ones (The encounter state's action gauges being a good example), as differences in game speed will otherwise affect the degree of how far from/near to the average they go at. I've fixed 2 errors now. Crashes were caused some of the time, when interacting with things. The timing of the animations, in the same instance crashes could be caused, was wrong, so it would stop for a short while. And the crash itself was cause of a single piece of code running for the wrong case, it was checking if the animation queue was equal to/more than the size of 1, to add more to the queue, when it should've only been doing it for equal to. What it amounted to was the queues growing insanely large, the different data structure's sizes desynchronising eventually (Which'd be caused by how some of the code empties the memory, and is normal behaviour (Cause, in only a single instance, it's assuming specific sizes for things, emptying selectively based on such information, so not emptying everything, as some of it needs to be kept to continue with)), and at this point it'd crash.

Added Encounter - Hard, a new song, unused, which will be a bonus for users who can go far enough to unlock it. The music I've done through the last few builds, whilst sizeable, should be kept in mind as only partly done (All of them being near enough to half of the way through, as far as their length goes, which is why they stop when they do).

Have fun and happy holidays.

Well, it's been a long wait, one which you'll know, if you've been following everything here, I was very busy through, putting life priorities first. As they wound down, my work was able to wind up, which has lead to today. Yes, a new part release of Verisimilitude: Prototype, and the knowledge the wait won't be as long for the next one, as I don't have so many things I need to derail to. Now, on to the progress report.

Rounded the values used for the application variant's default size. Rounded the values used for the application variant's default translation (It being centred). Rounded the values used for the deforming of the outputted video, when the window is resized. And rounded the values used for the centreing of the outputted video, as it deforms, when the window is resized. Clear the parts of the screen outside of the rendering area (Drawing black to them), when the window is non uniformly resized, to stop the rendering area from causing trails, and round the values used for the size, translation, and deformation, of such cleared parts. Cleaned code, adding explicit signage to the small amount of data which didn't have it. Cleaned the conversions from whole number types to part, needed for the right experience outputs in the menu and encounter ending states and the right experience reward, score and score reward, currency and currency reward, and inventory and inventory reward in the encounter ending state.

Changed the black over layer for showing what the user's person or people can see to better, from a circular area (Coloured for 2 dimensions) to a spherical volume (Coloured for 3 dimensions). Fixed level 1.3's lighting, which was using level 1.4's, not a simple rectangle shape. Fixed level 1.5's lighting, which was using level 1.4's, not its own (Mirrored). Changed the exploration systems' layers' level OutVideoObject data's name, to make more sense. Changed the encounter systems' layers' user OutVideoObject data's name, to make more sense. Exploration and encounter states: Changed level video object layering to have the first layer be the nearest and the last layer be the farthest, reversing the output order. Exploration state: Changed level video object layering to store layers as 2 dimensions. Exploration and encounter states: Changed level video object layering to store a layer's objects, not only an object's layers (Both way referencing).

Exploration and Encounter: Upgraded the animation systems, heavily. Added a flag for which direction an alter type (Absolute or relative) slot's datum can be run, backward, backward and forward, or forward. Added a flag for if the value changes are to be handled as discrete or continuous (The former will jump between states and the latter will have smooth transition between them, which is normally known as "interpolation"), storage for alter time types. Added a flag for which direction an alter time type (Discrete or continuous) slot's datum can be run, backward, backward and forward, or forward. Added storage for a state, to know if animations should be running. Added a time adjustment for when an animation begins and when it ends, allowing for it to either begin early/end late (Which is a delay adding measure, delaying the wait until the current/next animation is run) or begin late/end early (With everything beyond this point being applied in an instant). Added a flag to say whether or not the beginning late/ending early cases should apply the stuff beyond the time line in an instant (As, in the partial walking to standing cases: I wouldn't want to inefficiently run the unneeded remainder of the walking animation in an instant, to reach standing). Added time scaling, so animations can happen over shorter/longer periods, and negative periods too (Which would mean the animations can run in reverse). And added a flag for which direction the animation will run, backward or forward. The old animation system code had a flag for if the animation was static/dynamic. Static animations wouldn't run any logic for timing and counting (Static animations should've been using the count variable, whether looping finitely or infinitely, but weren't). All of the cases I was using static animations had no count maximum, so would loop infinitely. It was to knowingly keep their state, thus a history, to base future building of the queue on. Doing such a thing blocked the queues from continuing to their ending, and the memory from emptying when their ending was reached. I've subtracted the storage for the static/dynamic flag, as such information can be taken from the animation's size (0 being static, everything above 0 being dynamic), so no need to double up. And the lines between them would be blurred, if deforming an animation from dynamic to static (A size above 0, having 0 multiplied to it). I've changed all of the cases I was using static animations to have a count maximum of 1, as none of the current cases need such information to continue queueing from. Which does mean the static animations won't be looping infinitely, wasting resources, queues will eventually end, and their memory will be emptied. The static animations are 4 directions of standing, low health, and death. The encounter system, when effect displaying is functional again, will have extra storage for the health, mana, and maybe trust values, of all of the users. Specifically to hold the old state of everything, so when a user action runs and character statistics are altered, they can have a visible transition, synchronised with the effect displaying, versus the current jump. Such storage will also be useful for handling the standing, low health, and death cases (Knowing what a character was at before an action, to know what to queue up to them being the origin/destination of said action). As for the 4 directions of standing in the exploration system? It was checking for if one animation was in the queue and if it was one of them, to know whether or not to queue a walking animation at a button press, but now just checks if the queue has zero animations. The static and dynamic animation logic have been merged, bringing maximum consistency with it. Static animations do now use the count variable, whether looping finitely or infinitely. The same goes for the time data and logic. What's important about this detail? Static animations, being of a 0 size, shouldn't use any of the passing time, so they shouldn't delay animations queued for after them. Everything of them should be handled instantaneously and then allow for a time based stepping through of the following dynamic animation, with exactly how much overlap should exist. The combination of these things means static animations don't have special treatment in the infinite case (An infinitely looping static animation would have the special treatment of forcing it to only run once per action, to avoid locking up). Building a queue which tells it to do such will mean the game freezes, cause it's never able to go beyond the instant of said animation. It could be argued as a break, but I think it's a realistic simulation and is very much user error if it ever happens (The user being the game creator, in this case). Fixed a memory error, in which some memory, specifically the specific animation data structures (Which are, of course, the specific animations, to be queued for running in the general animal data structures), which should've been emptying when exiting the exploration state, were only being emptied when entering the game ending state. This treatment is the difference between memory which is for a specific state and memory which is for a specific run through the game (Stuff which needs to be kept between states, for the current run). Now, some of the memory falls in to the latter category, the general animation data, which stores the queue, so what it's up to, and a specific animation variable, for identifying the slot it's on, so the only part of the "What it's up to" data which isn't on the general animation side, and as such this should only be emptied when entering the game ending state, which it is. But all of the other specific animation data, which, as the name suggests, is the animations themselves, should've been emptied when exiting the exploration state, and I've changed to do so now. To itemise, it caused 2 problems: More memory was used than was needed in the menu, exploration, and exploration ending states, and a leak happened when entering the exploration state again, as it reloads all of the specific animation data (Which it should), but, in doing so, loses its connection to the old version, which shouldn't exist at this point. Java's automatic memory system would handle it, eventually, but the memory would be doubled up temporarily. Fixed a long time error, in which the last frame of an animation will run repeatedly, at each action, if the time the event is supposed to happen is less than the animation's size. And fixed a memory error for the "From normal to low health" animation, which had 1 slot too many, for the alter type. Tightened the memory management of animations, in the exploration system (Standing, walking, and the transitions between), which were doubling up on emptying, manually emptying after an automatic emptying would've happened. And now it doesn't empty all of the slots, only the ones it doesn't need, replacing the values in the others for continued use. Lastly, some short cutting was done for speed ups. Minor stuff, but done for consistency with everything else. In the exploration system's animation triggering logic (Deciding on a "Walking" or "From Walking To Standing" animation): A crash would be caused if an animation wasn't in the queue to check, cause it wouldn't check if the queue had at least 1 occupied slot before trying to do logic on said slot, which has now been fixed. In the exploration system's animation triggering logic (Deciding on a "Walking" or "From Walking To Standing" animation): It was handling all of that for the video animations, but not the translation animations. Meaning: It was forever running the originally set standing animation in an infinite loop. It didn't have a noticeable affect, cause the translations don't change for these animations. But in a future version, with different video? It would've been a problem. Logic existed to run the from walking to standing animation when triggering an interaction with something (A sign the character should stop moving, if they were doing so), which I found was only doing its job for the video part of things, not the translation one, which has been fixed.

Subtracted the old Encounter - Leviathan audio, replacing it with my own music (A friend's had been used up to this point), an old version of it, which I did a short while after the last whole release, so unheard before now, and will have more progress done for it in the near future (I wanted to have something of it in place, whilst waiting for more). Added Exploration - 3, a new song, unused, which will be a bonus for users who can go far enough to unlock it (More on this in a short while). And changed Encounter - Normal, rewriting all of it, growing its length from 21 seconds to a minute and 20 seconds in the process. The plan is to have 8 songs by the next whole release, which I'll be putting pieces of in to the next few part releases, 5 of which will be used and 3 of which will be unused (Again, more on this in a short while). Of the 2 of these 3 songs, the ones which are new material (Exploration - 3 and Encounter - Normal), what exists in this part release is perfect, but not the whole of the length. Exploration - 3 is at least 50% of its planned length and Encounter - Normal is at least 25%, all of which will have extensions in future part releases. I've added an audio player (For the 5 used and 3 unused songs), which has a temporary interface. It begin with all pieces as locked. It unlocks when first heard: Game, Exploration - 1, Encounter - Normal, Encounter - Leviathan, and Game Ending - Bad. And it unlocks when the exploration state's level 1.6 has been reached: Exploration - 2, Exploration - 3, and Encounter - Hard. Exploration - 2 and Encounter - Hard's slots are presently empty, so place holders. I plan on moving Game Ending - Bad to Exploration - 2, eventually, when I have something more fitting to replace the former with, so know this when hearing them.

In the user core: When changing attack's/defence's temporary modifiers (The values equipment changes, and eventually conditions, of which flee is currently the only type): It's supposed to undo the application of them and redo the application with the new versions (Adjusted based on what the equipment changing changed). One of its criteria is a check of if the additive modifier is non 0, for its case, and if the multiplicative modifier is non 1, for its case. Doing so for both the old and new values, which is exactly as it should be. But it was also checking if a difference existed between each old and new value, to try and be efficient about it. If multiple equipments were equipped for the same statistic (Only doable for the defence statistic, an armour and a shield) and one only had an additive multiplier and the other only had a multiplicative multiplier: It wouldn't undo the first equipment's alterations before redoing it and doing the second equipment's alterations, combined. It would amount to equipment page estimates of such changes being wrong, and a permanent stepping of the defence statistic slowly downward/upward, if repeatedly unequipping and reequipping, and doing so without reversing the order at the unequipping step.

In the menu system's abilities page: Default target selection to the user starting the action, as it's a good neutral position. And in the encounter system: Default target selection of your side to the user starting the action, as it's a good neutral position. In the menu system's equipment page: Fixed the <, =, and > symbolism, which was showing the wrong symbol for some small differences, cause of rounding and the user's power multiplier (What's used as a difficulty option). And in the menu system's equipment page, if unequipping something by selecting an inventory slot occupied with a different type of item: It'd only unequip if both the item type and name in that slot doesn't match what you're trying to unequip. What's wrong with that? It should only care if one of those things doesn't match, to know it's a different item there. It makes logical sense, hopefully obviously. But a practical use of such a thing would be: If I want to group similar items of different strengths. Think: Many items named Health Restore, which have different types to internally differentiate, and different powers (With probably some indication, like in the information shown when selected).

I hope people are happy with what I've done, do please let me know, it's a very motivating thing. Now, on to the next part release I go.

Outside of the sicknesses coming and going, from I believe stress breaking me down, which at this point hasn't happened for at least few weeks, probably cause so many side priorities are done so I'm less over powered by thoughts of them, I have been knowingly sick for the last 2 years, but it may go back a lot longer. I've danced around the subject on rare occasions in the past, of this I'm certain, but it would've been too vague to make much of an impression. I won't go in to specific details about it, as I think it would be a "I wish I didn't know that" thing for you, if I did. Simply know they are body wide problems, which may've been life threatening in the long term (Years, if I hadn't known what was happening and done something about it). They can be thought of as cancer-like, but are relatively far from as difficult to treat. I've been trying multiple treatments for them, which have at worst kept things from going worse. It's very highly possible they've been a part of compromising my immune system, outside of the stress factors (Which have, as I said, recently been better), so could be a part of causing the other sicknesses coming and going. My point being they may be a part of my worse times, work progression-wise, through bringing other sicknesses. They in themselves haven't been a factor in anything but said treatments taking a sizeable amount of time and energy daily. I bring this up now, not cause I'm at a risk of going permanently (Deathly) worse, but cause my most recent treatments have been doing more than using up my time, they've been fucking up my metabolism too. What it means is: I spend all of my days so uncomfortably cold as to take the majority of the energy I'd normally have, making everything feel too difficult in my daily priorities, able to do very little more than idle and try to rest. I know it may appear as if I'm making excuses at this point, but I'm basically trying to give explanation for my slowness, opening up about something uncomfortable personal, which I've kept private before now. I can't promise I'll be moving faster in the near future, as I really don't know. I have to experiment through these treatments, to find something which will work all of the way, and never stop what I'm currently on, as I risk undoing the progress in growing better and make it harder to go all of the way. Don't fear, I'm safe, but am in difficult times for the present and what I can predict of the future. I'll continue as best I can, but don't expect good speed for a long while.

It's been long, too long, but I've been very productive through all of it. I had 4 priorities, which are now done, so I can return to the normality of continuing Verisimilitude: Prototype's creation. Keep reading, if you wish to know what I've been up to.

Firstly: The house. The house I'm was in the state of trying to be sold, off and on, through all of 2017 and up to now. As I never knew whether or not I had to move, or when I'd have to do such a thing, I took the opportunity to sort everything I own, something I've been waiting until, all through college and university, but were unable to prioritise, cause of school. It amounted to about 2 decades worth of stuff to clean up, so in the case I'd have to pack it up: I wouldn't be taking a mess to the new place. I was systematic about it, so I'd only have to sort newly bought things in the future, and nothing else. It took a lot of time, time I think was worth it, with the state things are in now.

Secondly: The computer. My old computer was 12-14 years of age (Depending on the part), running Microsoft Windows XP. So, as the years went by, it'd run less and less, too many programs denying support, and many more being poorly coded, as to use way more resources than is needed. The hardware was starting to break down, after so long of heavy useage, and the software which would run was decreasing in range. It meant I was being locked out from living, more and more, with work fast growing increasingly difficult. The hardware for the new computer was bought in late 2017, and I should've been able to use it then, but a long list of problems (Which I'll go in to, in a while) kept pushing it later and later, plus trying to split my time between multiple priorities meant nothing was moving forward at a good enough speed. The idea was to build something which could handle as many years, if not more, of heavy use, not needing a replacement for a long while, to replace everything old (My keyboard and mouse were from the middle of the 1990s and my monitor and speakers were from the early 2000s, for example, and were very limiting), and transfer everything on my old computer to the new, in a way which would allow me to continue working/playing as if nothing had changed (But the far better performance of the hardware supporting it). To do the last point, I needed to: Turn the old computer in to a virtual machine, running in the new one. For which: I'm now running Linux Fedora, with Microsoft Windows XP within it, and don't plan on shifting to newer Microsoft operating systems in the near future. I'll wait until I've done a good enough amount of progress for Verisimilitude: Prototype and any other projects which come up as significant priorities (The Leviathan Eternal site being one such), before making such a move.

Now, for a ramble/rant of everything which went wrong. The case came in a bad state, wiring wise, so needed everything carefully rerouted. The computer wouldn't start up, cause of a broken BIOS, which didn't support the specific short term memory I'd bought, so I had to borrow lesser hardware, to get it to go as far as the BIOS, so I could upgrade the BIOS for increased range of support. The RAID card had a similar problem, but was far harder to handle, as it kept locking up in the process of making it better and building the arrangement of long term memory. I had a specific version of Linux Fedora lined up as the operating system (24), the last for which support had ended (So it was as upgradeable as it was ever going to be, and, thusly, stable), but found the recommended tool was failing to make a live USB drive I could install it from. I eventualy found a replacement, which, while it worked, made the USB drive unuseable for anything else, so its partition structure had to be fixed (It was my largest, and thus, the most useful for further things). Version 24 of the operating system failed to install, which made me try the knowingly less stable 25, repeat for 26. The software was too old for the new hardware. It probably would've been okay, with all of the updates, but without being to install it in the first place: Updating it to support the hardware wasn't an option. So I got stuck with a significantly worse version than intended, okay, at least I had something vaguely functioning at this point. I installed WINE, to run as much as possible on the Fedora side which would normally only run in Microsoft Windows, and VirtualBox, for everything WINE couldn't do, to have my old computer as a virtual machine in the new. The imaging of the old and transferring to the new was initially intended to be done through shared folders, but neither computer could view the other, after too many attempts, so I resorted to transferring to and fro between relatively slow external drives, adding extra steps to the move through such. Conversions between image formats too, as the only software which would generate the images live would only do so to a competing format of VirtualBox. Backing them up, to keep a safe state of the old computer in its final moments, which needed to be repeated as the ending kept shifting, with a need to manually synchronise the data between the machines, so nothing would be lost at the real transition. The images originally didn't work, a bad configuration, which had to be figured through. Then trying to get all of the external devices to function, so I could continue working/playing to the same degree. Video hardware drivers were an eventual need, for much the same reasons, but doing so for Linux was very far from intuitive. All of this took place through too many months, an extreme learning curve, as I kept hitting walls, and was still trying to continue with the other priorities I've talked about/will talk about, too much work. Rounding things up: I found version 26 to be as unstable as all reports suggested, having a crash or/and freeze from it (Simple things like the screen saver being activated and in turn the sign in screen were known causes of such, logged for this version (So if the screen saver going out didn't kill it: The sign in screen coming in had an equal chance to)), the RAID card would hit one of many walls and kill performance to a crawl, so I had to wait for updates to become available for it (They did nothing for a month or so, then a single large update, the log of changes listing many things of which I could've been hitting at any one time), VirtualBox having trouble with all of the above, made worse when updating the Linux kernel (The video hardware would stop functioning, needing its driver to be reinstalled, each time. A tool is installed, specifically to deal with this, customising the driver in to every newly installed Linux kernel. Or at least: It's supposed to. It says the job was a success, but the results prove otherwise). The computer was dying 5+ times a day, at the most painful of times, too unreliable to trust. I held off upgrading to version 27, which came out during all of this, as reports stated it had continued the decline from 24's high point (As I knew the wait for 28, which I was gambling on finally being an up turn, was 2 months away (Now a month, at this point), but eventually chanced it. Surprisingly it stabilised a lot of the completely disasterous crashes, as I can now run it for at least 3 days before such, but it still has many smaller flaws which break the experience. I know this part of my report has been extensive, but wished to communicate, in detail, the troubles I've had, to make it clear I've been meaningfully busy, even if not so much on the front of the projects all of you are here for.

Thirdly: The desk. My old desk was as old as the oldest computer parts, very small, with no space for anything on or in it, so a permanent mess layering it, with no other place to put things. The new computer, and all of the parts coming with it, gave me a good enough reason to do something about the desk. So I designed one, perfectly measured for all of my needs, and had it custom built. It arrived around the same time as the computer parts, but it was a wait of 2 months more, before I could completely use it. They made errors in cutting the materials, so significant parts didn't fit, which had to go back multiple times for fixes, but was, of course, eventually handled right (Or else I wouldn't be able to use it now).

Fourthly: I've done everything needed to make The Leviathan Eternal in to a seriously real business/company, nothing more to say about it, other than it giving me more intellectual property protection and security trading planet wide.

Now, on to Verisimilitude: Prototype. I've been doing a lot of planning, for the short and long term, designing everything, and plot, a lot of plot. It's been about a year from the last public part release, but shorter from the last private (Which largely existed to fix a handful of stability things, making it run right), at about 5 and a half months. A further private and public build are planned, which may need few months, each. I won't go in to specifics about them now, but hopefully the wait will be worth it. As of now: I can continue creating Verisimilitude: Prototype, normally, with nothing else to block my path. I'm very thankful for the patience of all of the people here. Stay tuned, as I pay it back.

It's been a while, but worth the time spent. The hardware side of the new computer is wholy done and the software side partly so. I am having difficulties with Linux drivers and transferring everything from the old computer to the new (As an image I can import in to a virtual machine. The virtual machine itself is ready). The new computer desk has been in use for months, far better than what came before. A lot more house sorting has been done. But that's probably not what you're here for, as important as such progress is (The more of it I do, the more I can return to the work which is most meaningful to you).

So, Verisimilitude: Prototype. It may appear as if little has been happening, but I've done a surprisingly large amount of side stuff with it, future proofing it. Plot is the most significant, as I've spent months on both its and Verisimilitude's (Can't do one without the other, as they're so tightly tied). A good amount of code and the beginnings of the audio changes I have planned, largely learning and experimenting at this point, but some real progress has been made on it. A private build happened few months back. Why private? Cause of one regression (From a system I'm rewriting some upgrades in to, which were and still are only partially done), which meant I couldn't release it in good faith as a replacement for the latest public. A second private build is planned, for early next year (Playable by supporters on Patreon only), but hopefully the third, which will be public, won't be much longer after (A handful of months at most, the audio being the most challenging part of what I'll have to do).

This has been a simple check in, to let you know what I'm up to, and how things are slowly winding in to place for my further adventures in game making. Stay tuned.

The plan for the year was largely to go through the long list of life needs which had been waiting for over a decade, through college and university. The house, computer, computer desk, and business/company sorting were all a part of it. As were the intentions to do the first house move, and finish one of the site's and Verisimilitude: Prototype's whole releases (The second beginning the year as a good way through).

At this point: The house sorting is half done (Emptying of everything which I don't want, but isn't worth trying to sell, which can wait until after the first house move), everything for the computer and computer desk have been bought (Constructing the first (The hardware side) and waiting until the second arrives and is constructed), the business/company sorting is near to done (I need to handle reporting my earnings and taxes with the government, international taxes, and continuing to carefully invest (I have to change it in the near future, to keep it going forward) the part of my survival's support which is driven by me (So the part of my earnings which isn't people helping through donations and other such things)). The first house move is extremely unlikely to happen before next year. Similarly the first of the site's and Verisimilitude: Prototype's whole releases, cause of how much time has been lost to all of the other priorities recently.

I'd like to believe one more part release of Verisimilitude: Prototype will be done through the year, but don't know for certain. Doing all of the audio arts I need to do will be a difficult thing, one I can't estimate the time needed for (If I'm to do it right and thus never need to return to it). If such a thing happens: I'll split my priorities between continuing Verisimilitude: Prototype and doing the site's next whole release, the latter of which should be fast to finish, so may happen within the year (Again: Only if a part release of Verisimilitude: PrototypeVerisimilitude: Prototype happens). Keep in mind: It was a bit less than 10 months between the second and first most recent part releases of Verisimilitude: Prototype, in which an extremely large amount of changes happened, so it's not like Verisimilitude: Prototype has been in a state of death this year.

Hopefully it's understandable why things have been going the way they have. I'll of course need to continue all of this, to truly finish it, as it sets me up for life, and means I continue normally later, but in a far better place.

In the middle of doing something about making The Leviathan Eternal in to a seriously real business/company, whilst organising a new computer (The one I'm using being at an age of 12 years) and desk (Far too small). All of which will set me up for many years to come.

Practising visual and aural arts, the latter of which will be a heavy focus for Verisimilitude: Prototype's next part release, a large reason why the slowness now, as I want it to be perfect.

Will talk a lot more about the things I've done the last few months, at a later date (Most likely the same time Verisimilitude: Prototype's next part release happens), but keep patient for now, everything is moving forward.

At long last the newest build of Verisimiiltude: Prototype is done, and with it: 9 months' worth of changes, so much to document, which is amongst the many reasons for the slowness. As anybody who continues reading, through the list of changes in this build, will discover: I've done a lot. I have a long list of other priorities to focus on, in the coming months, and as such: I've decided to split what was going to be 2-3 builds in to 4-5, leading to the next whole release of Verisimilitude: Prototype. So, hopefully, the time between releases won't be too long, whilst I'm shuffling other things forward. Now, on to the painfully large text walls of changes, or straight to playing the new build, which ever is most fun for you (I'm betting the latter, for obvious reasons).

A lot of cleaning, including documentation. Hunted down a lot of data which was using an inconsistent naming scheme, which had begun confusing things (As I made the accident of doing it wrong once, copied/pasted the code and adjusted it in to different contexts, thus duplicating the unnoticed mistake), fixing all of them. Fixed a large commenting regression from a year or so ago, which only went unnoticed cause it's in a part of the code deemed complete even further back. Did a lot of code summarisation, by creating temporary storage to avoid the repeated inputs needed for multiple accesses of things, which largely affects the creation/destruction of memory and such. The rule is: I apply it, near to exclusively, to data construction/destruction, but only if the code is acting on all of the data and doing so uniformly (So, as User cores are created/destroyed, a side at a time, depending on which system is causing them to do so: They'd be excluded, as it's not "all at once". But the destruction code as VP closes, which acts on the User data structure as a whole: Will have its code summarised). The only exception being cases of code which nearly mirror those which are a part of the rule (A good example is code which resets all data to a default, something the input cores do all of the time). I saved a bit of memory in something the video does called "double buffering", storing 2 buffers, 1 for inputting and 1 for outputting, swapping the purpose of them when they've finished being inputted/outputted. I draw to the input buffer and the output buffer draws to the screen. The input buffer was incorrectly sized. I included the size of the window's interface bits, and translated everything I was inputting to not be hidden behind any of this. Now I'm only translating when the input buffer's data is copied to the output buffer, so it's only the output buffer which needs to store that extra bit of space. If the window size ever changed: It'd destroy and recreate the input buffer (Which is something which should only happen to the output buffer). It was making the input buffer the same size as the output buffer, when doing so, wasting a lot of memory (And meaning, if the window's size changed, which was doable in the applet variant by zooming the web page: You'd be able to see beyond where you should, cause of the lack of clipping). Which has been fixed. It'd also reset the clipping area each time, which is something new to 0.2.1.0 (0.2.0.0 didn't clip stuff outside of the area it was showing). Fixed the application variant, which wasn't adjusting the video's translation correctly to have everything within view (It wasn't calculating its coordinates with the sizes of the windows interface bits (The bars at its edges) right). Changed the applet and application variants to allow for window resizing, centreing the outputted video as it deforms uniformly to fit the space given to it. Deformed the outputted video uniformly, so no distortion happens if the window is resized to a ratio which doesn't match the intended output. Centred the outputted video as it deforms, to fit the space given to it. Added two sets of window size storage, one for the internal size (The window's virtual size, which is the space I'm generating the video output to) and one for the external size (The window's real size, which is what the internal size is deformed to, for outputting to the screen). Originally it would only store the latter, but in a far dirtier way than it does now, outputting directly to it, with less/more visible based on the window size (Cause the output wasn't deforming to fit the window). Fixed an error in the mouse input core, which was only registering the first mouse button. It would store the first mouse button's events in the slots for all 3, so it would appear as if the second and third are being pressed/released/clicked at the same time. Fixed a memory leak when toggling audio. Added the ability to pause at the game, exploration, menu, encounter ending, and game ending screens. It was originally only doable at the encounter screen. Changed the pause ability from "Paused [][]" text to transitioning to/from a black screen, to turn off audio through its transitions and while in a paused state, to turn off the timers, and, at the encounter screen, to stop the animation of action effects.

Changed from 4 users to 1, on your side, so Verisimilitude: Prototype players nearer to how I intend it to (And avoids the confusion of having 4 of the same character in all battles). Before the last build: A character would level down if the experience change pushed the experience to less than the level down threshold and level up if it did so to equal or more than the level up threshold. In the last build: I made a change which was supposed to make the level down behaviour also happen if the experience change brings it equal to the threshold. I bring it up as I found errors. I had made the changes in the encounter ending system, as it counts the rewards and applies them. But I hadn't made the changes in the user core, so it could get stuck at the level down threshold. Similarly I hadn't changed the ending part of the encounter system (The point it's closing down everything encounter system specific and transferring what data is needed to the encounter ending system, the important thing being the experience reward, in this case). Both of which are now fixed. 0.2.0.0 would nullify experience rewards if at the maximum level (Which would have you stuck at the bottom threshold). 0.2.1.0 was doing that if the experience was at the threshold the experience reward would push it in the direction of (So if at the level down threshold and losing experience). The problem with that is: It's a bad assumption, which would mean it's impossible to go in a specific direction, if beginning at the direction's experience threshold. If you won enough experience to level up, but no more? You'd be at the level down threshold for the next level. If you lost experience? You wouldn't level down. The reverse is true too. VP no longer nullifies the amount of experience lost/won at the beginning of the encounter ending system, which means it'll show the experience a character earnt, whether or not they're at the minimum/maximum level. If you're at the maximum level and are at the level up threshold? It will now show you what you earnt, but it'd disappear after the round of counting (It won't change through counting, as it has no direction it can count. So it'll say what you've earnt, staticly, then turn to 0). All cores which had behaviour triggering inputs, like the User core's experience input, would only do said behaviour if the input is different from the original data, partly for efficiency reasons and partly cause some logic will do strange things if trying to act on unchanging data. Cause I handle the experience input a level's worth at a time, to match what's being shown to the user (And so in a future version of VP: I can show the character's changing powers per level), if at a level changing threshold and experience is earnt in the direction which pushes in to said threshold: The old and new experience had no difference between them, so a change wasn't triggered. To fix that: It'll now step the old experience 1 point from the threshold, to force a difference. It does so in a way which doesn't affect the output (As it's done an infinitely small amount of time before the User core's experience input) and doesn't cause a loss or gain of experience (The adjustment happening after the experience reward has been applied to the new experience the User core is going to compare to). I did a kind of code summarisation to the User core. It has 6 methods around the leveling system: InLevel, InLevelType (Whether or not it should pay attention to the maximum limit), InLevelMaximum, InExperience, InExperienceAlter (The growth value), InExperienceAlterAlter (The growth's growth value). InLevelType and InLevelMaximum had duplicates of InLevel's code. If InLevelType's input said to pay attention to the maximum limit and the maximum limit was below the current level: It'd do leveling logic. If InLevelMaximum's input was below the current level and the level type said to pay attention to the maximum limit: It'd do leveling logic. I deleted the duplicated logic in both methods and made them call InLevel instead. The user has 3 sets of experience data: The obvious one, an alter value, and an alter alter value. At every level change: The alter value is applied to the past/future level thresholds. And the alter alter value is applied to the alter value. The alter alter value exists for growth, it's currently set at 101, so the alter between level 1 and 2 is 101, between level 2 and 3 is 202, and so on. If either the alter or alter alter values are manually changed: It'll reset the experience values to level 0 and recount with the new alter or alter alter values. Once done: It's possible the present experience will now be beyond the level down/up thresholds. That's a design choice. The alternative would be to simply set the alter or alter alter values to the new value, without all of that level recounting, so the character progresses differently going forward, versus that adjustment. The problem? When I changed the level down/up need to simply being on the thresholds, not beyond them (But experience movement to have happened), for changing experience? I was comparing the new present against the new past and future level thresholds. For changing the alter or alter alter values? I was comparing against the original values to know if a difference happened, doing all of that recounting adjustment as said, and then testing the past/present/future experience. The character begins at level 0, has their alter alter value set to 101, and has their level set to 1, randomising their statistics a bit and setting things like their experience data in motion, which has all values as 0 until the alter and alter alter values are applied by the first level up. The act of setting their alter alter value was causing them to go through an insane levelling loop, as they were at the level down threshold, but levelling down from level 0 subtracts the new alter alter value from the alter value, so the experience needed to level up is 0 and level up is negative the alter value (Which is negative 101, so the level down threshold is above the level up threshold). Now, on to the fix: InExperienceAlter and InExperienceAlterAlter had their InExperience duplicate code deleted, calling InExperience itself instead. Why? If the alter or alter alter values change: It needs to check in which direction the change happened. If they go downward: The present experience is potentially brought nearer to the level up threshold, so only the possibility of levelling up should be checked. If going upward: The reverse. So it'll never need to check in a direction the spread between the present experience and level down/up thresholds haven't changed. I needed to make temporary storage of the user's experience, whilst InExperienceAlter or InExperienceAlterAlter are running, to do the comparisons with, in the same way InExperience already does them. So since it needs a duplicate of InExperience's code: It'll just call the InExperience method, so will be summarised in this way, like I said InLevelType and InLevelMaximum were. The InExperienceAlter and InExperienceAlterAlter methods, when originally using the experience storage directly (Versus the new way of simply calling InExperience to handle the duplicatable part): Were resetting past and future experience to 0, before counting up. So no counting down for them was happening. Why the change? Cause now I can manually set the past and future experiences and not lose this information cause of InExperienceAlter or InExperienceAlterAlter being called. It allows an extra layer of experience growth. Now, to try and give an example: If only alter is set? Experience thresholds will go up the same amount every time, a straight line: 100, 200, and 300 (Alter begins at 100). If only alter alter is set? Experience thresholds will go up as a curve: 100, 300, and 600 (Alter alter begins at 100). If both alter and alter alter are set? Experience thresholds will go up as a curve, but will have a bit of a boost (I can have the thresholds increase by large amounts, but the difference at every level is small): 1100, 2300, and 3600 (Alter begins at 1000 and alter alter begins at 100). That's what I could do before, okay. Manually setting the past and future experience will move the thresholds so they can begin at a different point, then applying alter and alter alter from this point. Also, I made another fix. When the experience alter/experience alter alter inputs were ran: The count down step's loop was okay, decrementing its counter which was being tested against being above 0 (The loop ending once it reached 0). The count up's step on the other hand was supposed to go upward, comparing against the level it should be at and stopping once it's reached (Then doing all of the experience testing to know if the level should change), but it was accidentally counting downward instead. So it was looping thousands of times until the counter would flip from the largest negative value it could store to the largest positive (Something which happens to numbers, in Java, at the extremes), suddenly fulfilling the check of having counted up to or beyond the level it should be at. It explained some of the oddness I was receiving when this build's level down fix was done, as the characters statistics appeared as if they'd leveled back and forth about thousands of times and stopped. I have no idea why it didn't show up as a problem until now, but it's been one for ages. Changed the user experience alter alter value from 16 to 8 bits, as 8 is enough. Experience alter alter is a static amount, which alters experience alter when a user's level changes. And experience alter alters the previous/next level boundaries. Otherwise experience needed per level would be linear. Changed the user inventory item count from 8 bits to 64, to give a higher range.

For positive mana generation: Was incorrectly rounding present health when comparing it to maximum health to know whether or not generation should continue. Fixed an action gauge error. It wasn't applying a user's power (The modifier which should be applied to all user statistics, when in use. What will be used by the difficulty option to allow for balancing adjustments) to their health when checking whether or not to generate a bit of the action gauge, which meant: A small amount of health, too small normally for the character to be considered living (Between 0 and 0.5, as rounding brings it down to 0), but high enough when multiplied by the power modifier (The highest of which can be 200%. 200% of 0.5 is 1, so definitely enough to be thought of as alive), wouldn't generate anything for the action gauge, keeping the character stuck until their health changes outside of this very small range. The action gauge adjustment to the speed it fills, in which the fastest character needs roughly 3 seconds (A bit of randomisation at every step, so 3 seconds is an average), and all others go at a relative speed (So somebody with half the agility as the fastest will need 6 seconds), is broken. If a character was at negative or neutral health (Unconscious) and has an extremely high agility, high enough for it to be the highest, with the fractional health crippling it: They'd still be treated as the fastest character, with all others going at a speed relative to somebody who is practically immobilised. It now works exclusively with mobile characters, so a super fast character dying will mean the others speed up, as they no longer have this super fast character to be relative to. I've plugged a bit of a memory hole, for the sake of future logic. This is going to be a fun one to try and explain (Sarcasm, I won't be surprised if it makes no sense). The action chain sent to a character's ActionGeneral instance, which is comprised of ActionSpecific instances, only points to said instances in the character's action tree. I was originally thinking I'd need to manipulate that, to get to the main core the fact a node has gone (Item depletion), but realised: The chain needs to be completely intact, for the sake of artificial intelligence eventually needing to know exactly what was used. Fine, so I can't touch that. I have to manipulate the action tree though, of course, which I've done, so a depleted item is no longer available to any characters. The problem? Cause the action chain just points to ActionSpecific instances in the action tree: The destruction of any instances means the action chain now has a crash causing hole (It'll seem like the chain is full, but attempting to read from the dead node will make it crash). The fix for this has been: Making the action chain store duplicates of what's used from the action tree, so the data can persist beyond what the character keeps storage of. Lots of memory management around that too, as it's a significant change of the way the code works, for this part of the functionality. A memory problem which'd cause a crash if an action was attempted which you couldn't fulfill the cost of. Normally origin data (Who made the action) would be cleaned when attempting another action, based on a flag saying whether or not an action happened before. But in the case an action wasn't running completely (As it'd stop if the cost wasn't met), the flag would never be set (Which is correct), and thus the next action would think the origin data shouldn't be emptied (Which is potentially incorrect). Fixed crashes in the donation skill, when handling origin data, when generating destination data to speed up selecting slots of other data, and when generating effect displaying data for both the origin and destination sides' trust values, but only for the mana damage portion (Mana damage only happening if health damage knocks them in to negative health). An oddity of donation targetting, if aimed at yourself. Actions normally apply a ratio of the origin's present and maximum health to all other equations happening, so if you have less than maximum health: You're crippled. If you had a team of 4 and the 2nd user used donation: They'd hit the 1st-2nd users normally, but the 3rd-4th less so, due to the origin having crippled themself. The logic treated it as if they were being hit in turn. In a very extreme scenario, in which you're at a high level and have lots of currency (Ignoring the randomisation factor, and the target defending against it: Damage is currency thrown (Agility) multiplied by unequipped attack (Unequipped cause it makes no sense for swords and such to impact how well you throw things)): Users 1-2 would be completely dead and users 3-4 wouldn't've been touched. That's been fixed to safely put aside the origin user's health data, to remember their state prior to the action, applying it through the whole action. So now it acts less as if each target is hit one at a time and more like they're all hit at once. Readded the item and flee action functionalities (Which haven't been a thing for the last many builds' worth of system rewrites). Degenerated/generated ActionSpecific instances in all cases Item instances are subtracted from/added to the item storage and said Item instances are usable as actions. This includes cases like the menu system's equipment page (Why? Cause what if an item is both useable and equippable. Maybe, at a later date (A different whole release than this one, as it'd be content changing, something which is outside this one's scope), Knive and Dagger weapons will be throwable things. If you equip the last one in a slot, emptying the slot: It should no longer be listed as a usable action. If you unequip the first one in a slot, filling the slot: The reverse should happen. Made many changes to the user action search algorithms, specifically: In the menu system: The creation of menu cores (The interface cores, remember the difference) wouldn't count disabled user action folder nodes, but the arrow and enter inputs would, which meant, if any folder nodes were disabled: The menu cores would have disassociative problems, and possibly cause a crash (As Verisimilitude: Prototype would either have what's needed or less than). And the arrow inputs didn't have an early algorithm exit for if the beginning state was all which is needed (So, if you're at the 1st level of selections, which is the root folder: It would keep searching through the whole tree, literally the whole tree, wastefully). Both of these things have been fixed. Deleted some redundant code from the menu/encounter systems' cases of enter and G key useage. The search algorithm checks every node's state when building up an action chain, but I had a check of the last node in the chain's state, after the search algorithm has been run, which was of course pointless. In all of the algorithms which are supposed to build up a chain of action or menu instances (Excluding the menu system's cases, cause the menu instance for targetting is the last in a list, after all of the menu instances for the action folders. So it needs to count up how many menu instances are dedicated to action folders, to find the last in the list, in the case said menu instance is needed in such an occasion. The reason I didn't have to do the same for the encounter system? The menu core exists as a general purpose thing for uniformly gridded interfaces, which target selection in the encounter system isn't (The "rows" (Your and their sides) can be different sizes. While the characters of the "rows" have a uniformity to their placement for their side (Your side being 1 dimensional and their side being 2 dimensional), the fact your and their sides have difficult placement rules breaks any chance for a higher level uniformity. And each character has a per "row" memory). Basically: The encounter system has its own advanced hard coded behaviour for target selection, so it's not using a menu instance for this step, and thus the search algorithm doesn't have to go through the entire tree to find it, as it's already separated in to its own data.): I've added some logic which will exit early, if a partial chain is ever built, but the algorithm is about to step back a level (Which implies the remainder of the chain wasn't found, it's as complete as it should be, and thus no searching should continue. It's based on the fact no node duplicates should exist (If they do: It's a failure on the content side of things), so it shouldn't bother attempting else where). Fixed a minor memory leak with all of the user action tree search algorithms too. Added data for the user flee condition's state, with memory management constructing and destructing it and defaulting its values (Which is how it'll handle the flee event, versus the old way, which was more directly an event). Changed the destination user flee condition state to true, if false, if a flee action succeeds. The flee action's origin and destination are the same, so the characters trying the flee action are the characters who will receive the flee condition. Changed the user flee condition state to false, if true, when an encounter ends. Added data for the user flee condition's effect origin/destination powers, which are defaulted to 1. Changed the friend side's user flee condition's effect origin power to 0 (For causing an unfleeable state), if an encounter has the Leviathan as an enemy (Which is how it'll deny the ability to flee when encountering hard enemies), and to 1, when the encounter ends. Subtracted characters who have the flee condition from the origin (All characters on the side doing the action who have full action gauges and consciousness (Positive health))/destination (All characters on the side the action is being done to (Which is the same side as the origin, in the flee action's case) who have consciousness (Positive health)) lists used for the flee action's calculations. Why? Cause they aren't near enough to either be in the way (The need for the characters to cooperate with their movements) or be a dead weight (Which unconscious characters are). The same couldn't happen for characters on the other sides. Why not? Cause they aren't far enough to not be in the way (They're outside of what's visible in the encounter, so realistically impossible to know where they are and not run in to them, for the characters trying the flee action). This's all for a future version, in which single characters will be able to have their flee condition toggled (Versus a whole side's worth of them), either of their own volition or being forcefully ejected. Multiplied the user flee condition's effect origin/destination powers with the flee action's effect. The memory emptying for the origin flee alter alter type's displayable effect data was incorrectly emptying the origin flee alter state data, which would've caused leaks if people ever fled. The flee action was wasn't generating enough data for the enemy's side and was accidentally using a friend index, not an enemy index, for one of the enemies' sides' calculations. Fixed memory leaks when depleting action gauges/queues and when tallying health altering amounts caused by an action, which could trigger depleting action gauges/queues.

Changed the counting of rewards at the encounter ending state to be manually triggered, so the user has all of the time they need to read what was lost/won. Fixed the experience and score rewards, which was a break in logic. It was checking against positive maximum health, to double each reward (The most extreme), when it should've been checking against negative maximum health (Literally an accidental "+" where there should've been a "-"). So it was an error which would only happen if fleeing from an enemy team who's members are all at full health. When an encounter ends, the currency and items received are now be based on the enemies' present health versus their maximum health, like the experiences and score are. Using the same calculation as flee, the agilities of your side versus theirs, to determine what currency and items are taken if an encounter ends early, through fleeing or otherwise (So an encounter which ends with not all characters of a side being below or at 0 present health). This is done per digit of currency and per item, your accuracy versus their evasion, both for what they've dropped and what you're able to steal from them when fleeing. For items dropped, if the ratio of health they have between their present and maximum values isn't at a point to be directly divisible of the amount of items they have, for example if they have 50% health and 3 items: They'll drop a rounded amount of items. Changed the way the encounter system's currency reward data is stored, from a single slot for the whole of the enemy side to having a slot for every character of the enemy side (So they have their own currency, for knowing who specifically has what when determining what is dropped if an encounter ends early through the flee condition or otherwise). Changed the way the encounter system's item reward data is stored, from staticly having 4 slots for the whole of the enemy side to dynamically having as few/many slots as is needed for every character of the enemy side (So they have their own inventories, for knowing who specifically has what when determining what is dropped if an encounter ends early through the flee condition or otherwise). Changed the encounter system's item reward data to store an item count, so multiples of an item don't need multiple slots. Split encounter currency and item reward data in to encounter system (What the enemies have) and encounter ending system (What you've taken from the enemies) data. Added data to store an item count, so multiples of an item don't need multiple slots, at the encounter system. Added data to store the indices of inventory slots which item rewards are going to be counted in to (Positive reward)/out from (Negative reward) at the encounter ending system, counting down said rewards whilst counting up your inventory. Changed the output of item rewards in the encounter ending system to make space for (The inventory reward information being dynamically moved as far as it needs to for this) and show: The inventory slots the items are going in to (Whether they begin as empty (Showing as such, before the counting happens) or not) and both the inventory slots' item counts and the inventory reward slots' item counts. Add the ability to visibly count down/up negative/positive item rewards in the encounter ending system. Fixed the logic for applying a negative experience reward. Did some shuffling to make positive experience reward's thresholds more efficient and to avoid a potential break, if losing experience and at the lowest level's level down threshold. Fixed experience rewards. You were supposed to receive a ratio of experience from an enemy, depending on their present health when an encounter ends, with 0 health being 100% experience, and negative health giving more, up to 200% at negative maximum. At negative maximum though: It was still giving you 100% experience. Any negative amount between negative maximum and 0 though was giving the right amount. Fixed currency and currency reward output, which would count incorrectly if a loss would cause currency to go below 0. The problem was: Currency would count down to a negative, jumping to 0 when the counting is done, and currency reward would count down to 0. The first part of that was really the only problem, but the second part should've been synchronised, so they're not counting out from step. Fixed inventory rewards, which wouldn't allow negative rewards. Fixed an impossible error. If for some reason multiple slots worth of the same item existed amongst the item rewards when an encounter ends (Which would mean a failure of summarising such data) and the user has an item slot with the same item type: The flag for having found said slot won't flip at its discovery, for the second reward forward, so it'd then try to find an empty slot to confusingly count in to. Deleted some redundant code with experience rewards, code which circumstances never can exist for it to be reached (I'm not saying it's unutilised, I'm saying it's a logical impossibility for it to ever be needed). Did some more deletion of the same type of stuff, this time in the user action tree search algorithms. Changed the user experience reward from 16 to 32 bits. It was 32 bits back in 0.2.0.0, but decreased in 0.2.1.0, as I thought I didn't need this much, which I've now calculated as wrong.

Made a minor fix to level 1.3's video. The part of 1.3 which changes depending on if you've encountered Leviathan has been split in to its own files (It originally had the "before" case in the same file as the normal background and showed the "after" case as a layer hiding the "before" case under it). I made this part of the original video completely transparent, with the "before" Leviathan case being its own file. As the lighting of the "after" Leviathan case is a background layer, not a foreground layer: I have merged with the other part. Made a minor fix to level 1.4's and 1.5's video. The foreground fence was shown twice (I accidentally saved it to the under layer, but it is invisible cause the over layer is the exact same art). The layering of the door from level 1.3 to 1.6 was fixed. It was above your character, hiding your character. Changed the lighting of the door from level 1.3 to 1.6, which is seen after the Leviathan interaction has happened, to be under the character, not over (So it's not going through you). Split the interfaces' video in to multiple files, to only show what's needed. Specifically: In the menu system's main page: Split the main file in to a main file, an origin file (For the main interface's video), and 3 multiple origins files (One for the first, one for the last, and one to repeat for all between. To be used in the case of multiple origins possibility). In the menu system's abilities page: Split the main file in to a main file, an action file, an action information file, a sub-action file, and a sub-action information file. In the menu system's equipment page: Split the main file in to a main file, an equipment item information file, and an inventory item information file. In the menu system's inventory page: Split the main file in to a main file, a first inventory item information file, and a second inventory item information file. In the menu system's abilities and inventory pages: Split the destination file in to a destination file (For the main interface's video) and 3 multiple destinations files (One for the first, one for the last, and one to repeat for all between. To be used in the case of multiple destinations possibility). In the encounter system: Split the user file in to 5 user files (One for the main interface's video and one for all of the users from the first to the fourth). In the encounter ending system: Split the main file in to a main file and 3 multiple users files (One for the first, one for the last, and one to repeat for all between. To be used in the case of a multiple users possibility). In the menu system's main page: Added a single origin file (To be used in the case of a single origin possibility). In the menu system's abilities page: Added a "Cost" text file (To be used only if a non-"Item" folder type action (One which can have sub-action children) is selected) and a "Count" text file (To be used only if the "Item" folder type action (One which can have sub-action children) is selected). In the menu system's abilities and inventory pages: Added a single destination file (To be used in the case of a single origin possibility). In the encounter system: Added a "Cost" text file (To be used only if a non-"Item" folder type action (One which can have sub-action children) is selected) and a "Count" text file (To be used only if the "Item" folder type action (One which can have sub-action children) is selected). In the encounter ending system: Added a single user file (To be used in the case of a single user possibility). In the encounter ending system: Added 3 inventory/inventory reward files (One for the "Name" and "Count" texts, one to repeat for all item slots from the first to the second last (If more than 1 item exists), and one for the first (If exactly 1 item exists)/last (If more than 1 item exists) item slot). In the menu system's main page: Showed the single origin file or multiple origins files (One for the first, one for the last, and one to repeat for all between), depending on if a single or multiple origins are possible. In the menu system's abilities page: Showed the "Cost" text file, only if a non-"Item" folder type action (One which can have sub-action children) is selected. In the menu system's abilities page: Showed the "Count" text file, only if the "Item" folder type action (One which can have sub-action children) is selected. In the menu system's abilities and inventory pages: Showed the single destination file or multiple destinationss files (One for the first, one for the last, and one to repeat for all between), depending on if a single or multiple origins are possible. In the encounter system: Showed the user files (One for all of the users from the first to the fourth). In the encounter system: Showed the "Cost" text file, only if a non-"Item" folder type action (One which can have sub-action children) is selected. In the encounter system: Showed the "Count" text file, only if the "Item" folder type action (One which can have sub-action children) is selected. In the encounter ending system: Showed the single user file or multiple users files (One for the first, one for the last, and one to repeat for all between), depending on if a single or multiple origins are possible. In the encounter ending system: Showed the inventory/inventory reward files (One for the "Name" and "Count" texts, one to repeat for all item slots from the first to the second last (If more than 1 item exists), and one for the first (If exactly 1 item exists)/last (If more than 1 item exists) item slot). Showed future steps of the interface, only if the future steps don't depend on the present step or if the present selection would lead to anything. In the menu system's abilities page: Showed the action information interface, only if an action is selected. In the menu system's abilities page: Showed the sub-action interface, only if a folder type action (One which can have sub-action children) is selected. In the menu system's abilities page: Showed the "Cost" text, only if a non-"Item" folder type action (One which can have sub-action children) is selected. In the menu system's abilities page: Showed the "Count" text, only if the "Item" folder type action (One which can have sub-action children) is selected. In the menu system's abilities page: Showed the sub-action information interface, only if a sub-action is selected. In the menu system's equipment page: Showed the equipment item information interface, only if an equipment item is selected. In the menu system's equipment page: Showed the inventory item information interface, only if an inventory item is selected. In the menu system's inventory page: Showed the first inventory item information interface, only if a first inventory item is selected. In the menu system's inventory page: Showed the second inventory item information interface, only if a second inventory item is selected. In the encounter system: Showed the sub-action interface, only if a folder type action (One which can have sub-action children) is selected. In the menu system's main page: Showed the user interface, only if any users exist. In the menu system's abilities page: Showed the action interface, only if the selected character has any actions. In the encounter system: Showed the action interface, only if the selected character has any actions. In the menu and encounter systems: Showed past selections of the interface as half transparent/opaque, to make it more obvious which selection is the present selection. In the menu system's main , status, abilities, equipment, and inventory pages and the encounter ending system: Shrinked the main video file's width and height by 2 arxels, to subtract empty space from the outer part. In the menu system's abilities and inventory pages: Shrinked the main destination video file's width and height by 2 arxels, to subtract empty space from the outer part. In the menu system's main , status, abilities, equipment, and inventory pages and the encounter ending system: Subtracted the black spaces which are supposed to be empty from the main video file, by changing them to be wholy transparent. In the menu system's abilities page: Added "Action" text to the action interface and "Sub-Action" text to the sub-action interface. In the encounter system: Changed the user interface's "Player Name", "Health", "Mana", and "Turn Gauge" text to better (More aligned with the other parts of the interface, sharper, and more coloured to match the shapes, not their lines), the user action interface's "Action" text to better (More aligned with the other parts of the interface, sharper, and more coloured to match the shapes, not their lines), and the user sub-action interface's "Sub-Action" text to better (More aligned with the other parts of the interface, sharper, and more coloured to match the shapes, not their lines). In the menu system's main, status, abilities, and equipment pages and the encounter ending system: Grew the user's profile area/areas (Which is presently unused) width and height by 1 arxel, to centre it. Centred the "Use" and "Move" text of the menu system's inventory page, the "Press Enter to confirm selection" text of the menu system's abilities and equipment pages. and the "Press Escape to exit" text of the menu system's status, abilities, and equipment pages. Added the "Press Enter to confirm selection" text to the menu system's inventory pages. Added the "Press Escape to exit" text to the menu system's inventory pages. In the menu system: Added the "Game" option to the list of first level options, which will lead to the game screen, if selected (But currently doesn't work, to avoid the user accidentally losing their progress while the game screen's interface is too simply to allow for anything other than a new game). In the menu system: Shuffled all of the first level options (From "Status" to "Exit Menu") to add space for the "Game" option. Cleaned the video of the menu system's status page, so its lines and shapes are coloured right, near to the first level user action's and the first level user action information's parts of the interface (Which will be subtracted). I changed secondary selections in the abilities page of the menu system to be half transparent white, versus grey. I fixed a transparency problem in the menu system's abilities page. If an action was selected which had multiple targets: The transparency data would over flow in to some of the text. In the inventory page: Would show information for the 1st item selection (If any are at that selection's translation) if at the use/move/drop selection step, which has been fixed. Changed the encounter system's background to using the generalised video and transformation storage, with memory management, versus the old staticly coded way. Changed the encounter system's targeting cursors to using the dynamic video data as everything else does and generalised the output logic to use the video's size for calculating its translation (So it smartly centres and does its other adjustments), with memory management, versus the old staticly coded way. Fixed the encounter background, which was stupidly being loaded multiple times, for normal encounter types. Fixed the user action video's output in the encounter system, which was outputting 1 arxel wider than it should. Moved the user sub-action video 1 arxel leftward, to keep the same amount of space between it and the user action video, with the latter's resized output. Fixed the user action/sub-action information video's output in the encounter system, which was outputting 1 arxel narrower than it should. Changed the layers of the up and down arrows, for the action and sub-action interfaces, in the encounter system. They've been shown as the highest layer as far back as 0.2.0.0. They've been changed to be: Above the action/sub-action windows themselves (Of course), above the cost/count part of the sub-action window (Which would be a part of the sub-action window's video, if I didn't need to differentiate), but below the selection boxes and dynamically generated text (The action specific text). I found problems in the animation systems, both the exploration and encounter systems' versions of it. The animation systems have 3 points in which they'll run: When a game state is loading (A sort of initlaliser, so everything starts at the right state when things become visible), when the game state is running but the animation timer isn't, and when the game state is running and the animation timer is too. The second case is nearly exactly the same as the initialiser, but will also get the animation timer running, so the animation can progress. Why don't I do such a thing at the real initialiser? Cause, by the time the screen is visible, and the exploration/encounter system starts running: It'd count the transition time as animation progress, making the animation be in a pre-mature state. Hopefully that's enough explanation to understand the changes I'm about to report. In each of the 3 points: 3 cases exist in which the animation queue may be emptied. Despite this, the animation timer will always begin running at the ending of this round of logic. So the next round may go to the 3rd point, with no existing animations in the queue, trying to run with empty data, and crashing as a result. The change here? I now check if the queues have anything in them before starting the animation timer, in the case the queues were emptied in any of those 3 cases they can be. I was only checking if anything was in the queues for the first 2 points. In the 3rd: I was assuming the timer was running cause it had stuff to run (Which due to that last bug: Wasn't always the case). I now check if anything's in the queue for the 3rd point too. That other bug is no longer a problem, but this means, if the queues are emptied outside of the animation systems themselves: It won't violently break down. With that said, I normally default or/and empty everything at that point, so the timer should no longer be running. But this additional robustness protects from any future accidents in this regard. The transformation part of your character's defence animation was generating too much data, so having a bunch of unused slots. This has been corrected for both the exploration and encounter systems. Regressed the interfaces which included "Cost" text for a sub-action, so it and "Count" text can be dynamically added as its own video layer, depending on the action type. Fixed some item text, specifically the restoration items, which said "Restore's ..." and should say "Restores". A lot of folder/file shuffling, so the video and audio stuff is organised as it should be. Changed the game screen's video and transformation storage to allow for multiple slots, for the eventual addition of interface stuff. Shuffled the storage for the menu and encounter systems' video and transformation data, so all of the changes fit. Generalised the storage for the encounter ending system's video and transformation data.

After a user action happens: Checked the action chain data, based on the present selections, for changes which would mean the user is too deep in to the interfaces, and step back as many levels through them as is needed. Specifically: The action chain's length (If it's shorter), its nodes' states (If any are disabled), if its last node can't/can have children (File or folder), and its last node's destination alter type (Static or dynamic), to know if the interface depth needs to change and to what level. This is presently something which only happens when the last of an item is used. Did so for the menu system's abilities and inventory (Was doing so in 0.2.0.0, but it was based on the inventory item count, not the user action chain data) pages. Did so for the encounter system, looping through all of your side's characters, whether the action happening is of your side or theirs (They may eventually be able to affect your characters' actions). Fixed unuseable items to never lead to a target selection phase. The inventory page now uses an action's targeting data to know what selection information to show. Both the input and output sides of the code will create a list of users (Unfortunately independently of each other, due to where each part of the code is, so the input may be using a different user's action core versus the output), randomly select from them, check their health, which if below 0 will cause them to be removed from the list and the last 2 steps repeat. Do an action search algorithm for an item node (Removing from the user from the list and restarting, if not found), do a search for the specific item, and then go ahead with the planned useage behaviour. At the output side: I only need the ActionSpecific version of the Item instance at the point of targeting. I could either generate an ActionSpecific instance from the Item, to do so, or go through all of that user selection and searching logic. The latter is what I did. Why? While the former is more efficient and considerably shorter to code: It runs on assumptions. If something breaks, badly, for the user to be at the targeting step, whilst not having a useable item selected (Maybe an item doesn't exist in this slot, maybe it isn't useable, or maybe the conversion failed so what should be a useable item doesn't exist in the action storage): It shouldn't act as if it has an ActionSpecific node to read from. The reason for the randomised user selection is cause you have no way of manually selecting one in the inventory page. You've lost the opportunity by picking the lazy route to item use, which amounts to "Hey, can the nearest guy fetch me ...?". In the encounter system: Changed the way enemies determine the destination of their actions. The old way would count all of the users with positive health, generate a random number within that range, recount all of the users to find the one which matches the random number, and use it as the destination. The new way will create a list of all users, generate a random number within the range of the list's size, check if the user at that slot has positive health, if not: Subtract the user from the list and regenerate a random number to continue. If so: Use it as the destination. It may seem like they're equally efficient, as a worst case would have the users searched through, twice (The first to count users with positive health/add users to a list and the second to recount users/check if a user's health is positive and possibly subtract from the list), in the two algorithms, but they're not. The first algorithm will check all users' health twice, in the worst case. The second algorithm will only do so once, if all but the last user a random number is generated for have negative/neutral health. Fixed an odd error with enemies in the encounter system. It would shuffle their order after every action. It was only supposed to do so in the cases of: The action chain couldn't be found or the action itself failed to run (Cause of one of the many costs not being filled), which it does now. The point of it being to stop an enemy unable to make an action from blocking other enemies trying to do the same. Fixed another odd error. When an enemy attempted to make an action, it'd search a character on your side's action tree to check if the action is available. It'd use the right user identity, but the wrong side identity. If enemies had a uniquely typed/named attack, which doesn't match yours: Enemies would never be able to attack, as they wouldn't find their action in your tree. Derp.

It's time for a short report. The next build of Verisimilitude: Prototype is finished, for which I'm currently summarising 9 month's worth of documentation for. It is privately released for now, so the supporters can test it, but will go public once the documentation for it is up to date. The house and computer move are getting heavy, but it hopefully won't be long until I'm here again, with something to show for all of my hard work.

I have 2 pieces of good news.

Firstly, after what may be literally a decade of misdiagnoses, we may have an answer for the missing parts of what's wrong with the family member, in bad health, I've talked about. Why a decade? Cause symptoms exist, which go back that far, and are only explained by the most recent diagnosis. I won't bore you with specifics about it, only the key parts of importance: They were very likely going to die from it, being in the latest steps of it, which should turn around now (Will know in the next few months), and I'll be able to start my first of two moves of home (The first being to a better place locally) when I know their health is permanently better.

Secondly: I've finished the next build of Verisimilitude: Prototype enough to privately share it with my donators (Including the supporters through Patreon) for testing purposes. Literally the only functionality missing is the flee ability. I won't go in to specifics about what's changed between builds, cause it's not up for the public yet, and it's 8 months worth of changes I don't wish to summarise until it's complete (As such I'm betting on at most a week between finishing the public version and releasing it, the time it could take to document everything). Simply know the wait won't be much longer (March at the latest, if everything goes very wrong. So a worst case).

The last time I talked about the slowness of Verisimilitude: Prototype's progress I listed extremely bad sleep and forever getting sick amongst reasons for it, but it's not only my health which has been in decline. A family member has been a physically worse state than me, decreasing as fast, whom I've had to care for through the year, more and more. They've had me tied down for years, that happening when it seemed like I was going to finally have a way out, so my hope of being able to life a life is nearly completely gone at this point. The last month: They were largely immobilised, until going to hospital, for surgery. Then I had to care for their pets, who have a very specific schedule. Basically: I wasn't able to have quality sleep for a very long while, as I had to keep getting up to handle their needs, and then the family members too, when they returned, as they were in a far more useless state (If it was possible) than before their surgery. I'm very surprised I was able to do anything for so many months, but it's been getting worse, as I said.

I've been unable to progress for the last few days at my work, as the family member decided (Months ago, in the middle of their fast growing state of unwellness, so many opportunities to decide otherwise between then and now) to have friends here, on holiday, for the next few weeks. So I didn't only have to care for them and their pets, but prepare for their visitors too. Christmas was completely spent doing that and trying (Failing to sleep), with the next day being spent doing the same, but whilst being told I'm going to be sued by them, for the dangerous living conditions I caused (Cause everything I was doing: I was doing wrong. Criticisms which have never stopped). So it's a nice thing, for my mood, having my future threatened like that. If I disappear for a long while: That'll be why.

Verisimilitude: Prototype has been progressing, way slower than I'd like, surprisingly doing a bit, on average once per 3 days, in the last 5 months. I haven't been keeping my documentation up to date, as it's a mess from being built up through so many months (So I'll likely lose few days between finishing the next build and releasing it, to catch up with the details), as such: The percentage of completion listed is far from representative of the present state. As I couldn't up date the percentage: I haven't bothered changing the date for every day I do something, as it'd still seem like I'm standing still. It's a lot closer than it was at my last report, to completion, with only 5 things to do (Specifically, in the order I'll do them: The menu system's inventory page's item use case. A large amount of code summarisation (Creating temporary storage, for things which will be repeatedly accessed. A trade between processor and memory useage). Up dating the menu system's interface (Only showing the parts of the interface which need to be shown, at the present level in to it. Showing previous levels' selections as partially transparent, to make it more obvious which selection you can currently affect. And showing the interface and selections which pressing enter will lead to, if any). Up dating the encounter system interface (The same as the menu system's, plus the memory management all of the other systems have received by now, the encounter system being the only system at present, which doesn't completely empty and fill its memory as needed). And adding the flee functionality back in). The list of what's done so far? At least a magnitude larger than what remains, so I estimate it to be more than 90% done. I won't try to guess when it'll be finished though, with how life's going, but it's still progressing, as tortuously slowly as it may be.

Verisimilitude: Prototype, despite the lack of clear signs, is progressing, but arguably too slowly (I think so). The list of reasons why the late release is a long one indeed, one I'm very apologetic for. First, I'll begin with why the slowness, then I'll go in to what good has happened through all of it.

I've been spending a lot of time handling a series of different types of moves, mainly between homes and computers. I've been where I am for far too long, and have been preparing to change it, step by step, so I can temporarily move to a cheaper place, save up, and move again, to the other side of the planet, where more opportunities exist for what I'm trying to do. It's a large amount of mess I have to organise, stuff which has been gathering dust for up to a decade, no time to deal with while university was a priority. Similarly it's been a year since I had a new computer, and I don't wish to dirty up a new one with a direct transfer of everything chaotic on what I have at present to use. I'm playing the long game, in both cases. For the house move: Cleaning up and down sizing everything to exclusively what I want to take with me, which I'm being careful about. And the computer: Much of the same, lots of files needing a thorough organisation in virtual space, plus getting all software needed for this computer's successor, whilst waiting for the next generation of hardware to be released. I've also been regularly sick, a mix of insomnia and stress, so I rarely have the energy to do anything useful these days.

With all of that said, I have been making progress, on many sides. The next 3 part releases (Which are enough for the next whole release) of Verisimilitude: Prototype are nearly perfectly planned at this point, a handful of things remaining to be designed, so simply have to code them, and do any other needed parts too. I have a passport on its way, soon an attempt at a permanent visa, a lot of bank details sorted, and various other steps taken, for the much farther move, all of the nonsense needed to do everything legally and support myself through it. Patreon support will be a large part of that, and of course to earn more I need to do more, so Verisimilitude: Prototype progress will resume shortly, as soon as I'm well enough. A lot of investments have been made also, to help keep my work support reliable. I can't promise an amount of time to do the next release, but it shall at the very least be within this year. A part of the delay is the scope scaling up, as I've found things worth fixing. Hopefully it'll make up for a bit of the wait, and give all of you something far more complete to play with (The encounter system's animations and effect displaying should be the only missing components).

It's been a while, so I thought it'd be worth letting everybody know where I'm at. Firstly, Verisimilitude: Prototype: The next part release is a bit more than half done, including a long list of fixes. I intend to have a good amount more finished before I put it out, including: The item and flee action types back to being useable, the encounter ending state's rewrite finished (Which will include the last a family of changes I've named "Hit and run tactics", which the last part release had functioning for experience, but not currency and items. Flee being unuseable stopped the experience part from being noticeable), the ability to pause at all states (Not only the encounter state), and redoing some of the music (I don't know how much, as I'm out of practice. The intention is to have all of it redone by the whole release, which is 3 part releases from now, the way things are presently planned).

A part of my slowness has been cause of a lot of necessary redirections I've had to do recently. I have the potential of a team and with it the possibilities of larger game projects, big enough to eventually be sellable. I've been cleaning up the reuseable game system Power, specifically for that purpose. If I have a team: That'll be the first thing we need to do, as it needs to be able to support the games we're going to make. At this point: I've done a lot of preparation, cleaning it up. It only needs documentation for the future versions' do lists to begin making real progress, sharing it with the other team members to ease communications. Preparations are happening for when I build a new computer later this year (My current one is a decade old). Preparations are happening for moving to a new house, probably near to the same time as the computer event. Many other things have been happening too, spread between so much work as to be regularly sick, the strain of it having broke me down through this very heavy year.

The next time I put something here, it'll hopefully be to put out one of the many releases all of you are waiting for. Progress is building momentum, I should be back to Verisimilitude: Prototype very soon. Keep patient, it'll be worth it (All of the old functionalities will be back in, excluding: Action effect displaying and animations in the encounter system. All of which will be in the 2nd next part release, with more music improvements).

It's been very long, I know, from the last part release of Verisimilitude: Prototype. I reached a point at 2016.4.22 I would've been happy to put it out to the public, but lost my web for too long to do so. As I needed to do a lot of work for the animation system for what was going to be the 2nd next part release, before I could go to other priorities: I decided to continue all of the way. As such, this is probably the biggest part release I'll be doing, but it may be a while before the next, as I'll be spending a lot of time pushing other things forward (Power and the Site, the former of which I'm trying to organise a team for, so it can go faster, and so we can make larger more sellable games). As things will be so wide spread: I'll try to bring you more news of progress, so it's obvious what's moving and by how much. This part release pushes Verisimilititude: Prototype - 0.2.1.0 from 93.253% to 97.162% complete. It's time to list everything I've done. Have fun.

When closing the game at the same time the beginning/ending part of a state is being run: It would attempt to empty empty memory, causing a crash. When closing the game: The storage of which level the user is in was emptied too early for the exploration state, causing a crash when it tried to empty level specific memory via it and the emptying of shared memory wasn't happening for the encounter ending state, only for the exploration, menu, and encounter states. Audio would crash at looping cause of thread synchronisation problems, something Sun/Oracle had 5 years to fix but have chosen to do nothing about (This is the one case of dirty code I'll have in the game, while it is built with Java). Did a good amount of general code cleaning, but the only parts of importance are: It doesn't store as many wasteful things, loading a bit more as needed versus as soon as the game is opened. Cleaned the user core which was doing unnecessary loops when creating some of the user's data. Cleaned up all of the level and experience changing stuff for the user core. Subtracted storage for users' status, using the users' present health exclusively to know their status. Fixed a bit of memory management for the combo restore item, which was checking the wrong storage to decide when one of the storages should be created. Cleaned the video storage for the encounter ending state, added transformations, having its memory managed as needed, with all of the output code moved to where it needs to be, using the extra information of the transformations to output right. With input timing, if the amount of time needed for a repeat was lower than how much time has happened from the last one: The timer would go down by the expected time, not straight to 0. An example of what's wrong with this, if the amount of time needed for a repeat is 0.1 seconds: If in the 1st frame It's been 0.09 seconds from the last repeat and in the 2nd frame it's been 0.19 seconds from the last repeat, the timer would set itself to 0.09 (0.19 - 0.1 (The amount of time between repeats)) versus 0, so the next repeat would happen too soon, maybe unavoidably so for the user (The repeat you were waiting for has happened, but you can't react fast enough to release the key and avoid an additional one happening). Changed fading from/to black, inputs, health/mana degeneration/generation, origin/destination power degeneration/generation, movement (Walking), animations, and action gauge filling to be done in real time, using the action timer core's data. It will mean people will have more equal experiences with it. If their computer's too slow, it won't unbalance things. As they will have the option to manually change the action speed, they could tell it to run slower, so it doesn't take as much computing power from other processes and not affect playability. Screen transitions will now work no matter what length of time I set it to. Previously, it was very static about it. The timers for screen transitions and encounter ending reward counting were waiting an extra frame after reaching the cycle/stop point before cycling/stopping. Audio pausing between game states (When transitions or memory things are happening) was a bit incorrect, as it would play while transitions were happening and start playing before memory for other stuff had been loaded. I've changed it so audio won't play at all while the memory management phases or screen transitions are happening. In both scenarios: The game is basically paused, so audio (And any animations) shouldn't be progressing. The logic for it? If I had noises for events happening in the game, any screen transition scenario (Be it going between states or manually pausing/unpausing) would desynchronise the audio by letting it continue playing for as long as it does. In the exploration state: When pressing right alt and B (Change the in state), it had no delay between repeated detections, so the timing was infinitely too fast. In the exploration state: When pressing left alt and D (Decrease the action speed), movement wasn't being blocked for the press of D. Applied rounding to: Checking the health/mana criteria for health/mana damage, avoiding the incorrect triggering of these things. Converting between health/mana damage, avoiding the incorrect amounts for the second effect. And the health/mana effects when calculating the trust values' changes. Everything which was of the part number type and using 64 bits of storage takes advantage of it now at the setting of values. I was only using up to 3 digits at the right side of a decimal point, but now go as far as it can store. This only affects user movement, and is too minor of a change to ever be noticeable. Changed the action gauge data for encounters to statically sized types, as resizing won't be needed in the next whole release for them. It's largely to fit the general design of things, as: If something isn't used the smallest bit, it shouldn't exist. Changed the experience and currency award data in the encounter system from 32 to 16 bits, as no more is needed. Changed the tallying for experience earnt from a 32 bits whole number to a 64 bits part number, which means no fractional amounts are lost when stacking multiple enemies' worth of experience. When applying experience changes to your characters: Rounded the experience given, versus the previous automatic (Type narrowing) behaviour of being floored, which means a balance of experience losses/gains with fractional amounts.

For characters: Added local transformations, which are largely for use by animations, a way to adjust imagery so it isn't forever centred. For your characters in the encounter system: Changed global transformations' translations, as they were both global and local data together, with local now split in to its own part. Added storage for the user's video identity/users' video identities in to the exploration/encounter systems, to know which slot/slots is/are active. Changed your side's users' video storage in the encounter system to not use the user's video storage in the exploration system. Did so to allow for multiple users. Change their side's users' video storage in the encounter system to allow for multiple video slots. Added storage for animations. Did so for the user's video's identity and local transformation's translation in the exploration and encounter systems. Added storage for types, names, identities (To know which slots are active), sizes (The length of time), time types (Static and dynamic), alter times, alters, and alter types (Absolute and relative). Added storage for animation queues. Did so for the user's video's identity and local transformation's translation in the exploration and encounter systems. Added storage for types, names, an identity (To know which slot is active), a time (To know when it is in the present animation), a time state (To know if the time should be timing), count types (To know whether or not to use the storage for count maximums), a count, and count maximums. Rewrote the exploration and encounter animation systems to be more uniform and allow for more general useage. Find animations with animation queues, using the storage for types and names of both. If found: Set the identities of the animation. If not found: Go to the next identity of the animation queue. If the animation queue identity tries to go outside of its range (Everything is done): Empty memory. Changed animations to use both absolute and relative alter types (They were only using absolute for videos and relative for local translations). In the case of video: The absolutes are for going to a specific animation's video and the relatives are for going through the same. In the case of local translation: The absolutes are to avoid behaviour from a previous animatiom from affecting this one and similarly parts of this one which are from different animations, and the relatives are self explanatory. The absolute parts mean: As other animations are added/changed/subtracted, I only have to change the few absolutes of this animation to go to the right storage for the many relatives to continue doing what they're supposed to. If animations are queued, before the screen transitions from black: Run their logic once, with no timing done, so things are at their starting state. If animations are queued, after the screen transitions from black: Run their logic as many times as is needed: With no timing done for the first frame, so things are at their starting state. And with timing done for the second frame and forward, so things move to their finishing state. For animations with the static time type: Finite looping will run once and infinite looping will run once for all of the frames. Added logic for animation looping, counting how many loops have happened, and stopping an animation if the count type says the count maximum should be noticed and the count maximum has been reached. When a walking key is pressed, released, and pressed again and the user's character hasn't finished animating back from a walking state to a standing state: It now continues the walking animation from where the transition animation is at.

Relabelled some video/audio stuff to be more in line with what they're for. For example: Sorting all of the character video, renaming them and replacing them in to the correct folders, stored more cleanly, including the animation part of them. The exploration theme, eventually there'll be more, so the current one is now numbered. The game ending theme only happens at your failure, so is for bad endings, being named this way now. Similar things to this, which are arguably meaningless, but make things a bit more consistent in the long term. Resized all of Fenrir Wolfbane's video to exclude completely empty widths and heights of arxels, shrinking to include only what's needed. Resized Fenrir Wolfbane's width axis to better match his video, for the sake of tighter collision detection. Changed the user's walking speed to be based on the width part of their size for collision detection, calculating their stride from it. Which means, if the size was different: The speed would be too. Significantly increased the user's walking speed, as it was too slow (Poorly calculated the first time). It's still slower than its fastest by 16%. Changed Fenrir Wolfbane's animations' timing to be at a more realistic speed, with extra changes for walk (An deceleration/acceleration for a more natural appearance) and flee (An deceleration/acceleration for a more natural appearance and timed for a running speed). For Fenrir Wolfbane's item (If the destination is us and if the destination is them) animations: Added a stand frame, between the find item and throw item parts, to make things smoother. For Fenrir Wolfbane's normal to low health animation: Destroyed the first frame's video (As it was a double of a stand frame). For Fenrir Wolfbane's attack, defence, magic, item (If the destination is us and if the destination is them), flee, normal to (Not from) low health, and low health to (Not from) death animations: When an animation begins, it was instantly at the first frame which is a part of the animation, teleporting to it. So the animations were a bit shorter than they're supposed to be. For Fenrir Wolfbane's dynamic animations: Added neutral frames to the beginning and ending of all animations, so they are independent of other animations before/after them. Depending on the animation, this is either: Stand, low health, or death frames. In the case of the attack, defence, magic, and item (If the destination is us and if the destination is them) animations, both neutral frames needed to be added. In the case of the walk, flee, normal to low health, and low health to death animations, only the beginning neutral frame needed to be added. In the case of the flee animation, the ending neutral frame needed to be changed. It was a stand frame, but it was the wrong stand frame (It was rightward. It should be leftward). In the case of the low health to normal and death to low health animations, only the ending neutral frame needed to be added. In the case of the normal to low health animation, the beginning neutral frame needed to be changed. It is a double of a stand frame, which the double should be destroyed and the stand frame itself should be used. And in the case of the low health to normal animation, the ending neutral frame needed to be changed. It is a double of a stand frame, which the double should be destroyed and the stand frame itself should be used. For Fenrir Wolfbane's non walk dynamic animations: Destroyed the logic for defaulting to a stand, low health, or death frame after the animation has ended. Cause of the adding and changing of neutral frames to the animations, the flee, normal to (Not from) low health, and low health to (Not from) death animations are a bit shorter. Fenrir Wolfbane's low health and death animation's translation alterations were wrong. Determine the rotation from the translation velocities, so the decision of which animation to use isn't based on 8 discrete directions (The way it was with 4 keys of input). Changed the user's size in the transformation core from a whole to a part number, allowing for a lot more variance. If Fenrir Wolfbane's status was normal, and their health had changed to 0, so their status should change to death: The translation alteration for low health would happen. If Fenrir Wolfbane's status was death, and their health hadn't changed from 0, so their status shouldn't change from death: The translation alteration for low health would happen. If Fenrir Wolfbane's status was death, and their health hadn't changed from it: Their status would change to low health at the beginning of an encounter. If Fenrir Wolfbane's state changed between normal and low health, normal and death, or low health and death, outside of the encounter system: The translation alterations at the beginning of an encounter were wrong. Correctly starts encounters with a low health or death animation for your side's characters, depending on present health, but won't allow changes through the battle (As no logic exists to queue animations whilst a battle is happening). For the encounter state: Added a system for determining and storing layer information for the users' video, based on the users' global translation's height axis. As the system will be automatic, the ordering will be: The first found for a layer will have the highest priority of being shown, later findings having relatively decreasing priorities. Fixed the error of having wrong character sizes at the start of encounters from the second forward (Was using the sizes of the previous encounter). Enemy 2 was adjusting it's width translation by the width size of enemy 4, which meant the width translation would be wrong if enemies 2 and 4 weren't the same type. The placement of targetting cursors was wrong for the encounter system, for the cases of multiple cursors (Specifically the smaller secondary cursors, which were in the wrong places).

Split the game timer in to 2: A general one (For the whole game) and a specific one (For the present play through). Moved currency and level information in the menu system, for the additional game timer outputs. In the case a computer controlled character fails at an action, cause they don't want to (Waiting for something) or can't handle any of the costs, cycle through all of them once, to find if any of them are willing and able to make an action. Basically, this means the first character queued not making an action won't stop later characters in the same queue trying to do so themselves. This isn't something which effects VP now (As computer controlled characters only attack, so no intelligence happens or costs exist), but will do so in later versions. Stopped enemies from making an action at the same time as friends. If actions kept happening with no pauses between the animations finishing for the last one and starting for this, none of the encounter ending logic would be reached (This is more likely to happen with the enemy side on its own, but can happen with an even shuffling of you and them too, as in: You make an action, they make an action, and repeat until all action queues are exhausted, so a possibility of 7 additional actions happening after the encounter should've ended. I won't go in to the specifics as to why things need to flick back and forth for you making actions to have such a long chain of this happening). If multiple encounter ending scenarios happened, the logic of the later ones would happen too, over riding behaviour of the earlier ones. The order the logic is checked and happens is: Winning, fleeing, and losing. If you kill them and they also kill you, all rewards are moot as you're going to the death screen. If you flee and lose, potentially unavoidable game over screen, and if you win and flee, you get rewarded for the win, but the encounter ending screen will say you've got nothing (Cause you fled). The last scenario is the only one which has behaviour noticeable to the user. Gave all of the characters of your side of an encounter life timers, which count up for as long as they're alive. Experience is no longer split evenly between characters, it's based on the ratio of their survival in to the tally of all of the life timers. To get an even split, they all have to be alive for the exact same amount of time. As it's about survivability, it will balance nicely in the future when characters are more geared in to different specialties. Healers who stay alive will get more experience than those they have to keep reviving, for example. Experience given is based on the present health of the enemies. If you flee (When it's functional again) but did some damage before fleeing, you'd get experience for it. Having enemies at 0 health is what's needed to get the full amount of experience typical from them, but negative health will give more, up to double. Verisimilitude: Prototype - 0.2.0.0 (The last whole release) would give bonus experience per kill, 25%, which in a scenario of 4 enemies was a bonus of 100% if one character of your side killed all of them (The bonus was applied to the tally. A single character could get 125, 300, 525, or 800% ratios of experience from enemy teams of sizes 1-4). That bonus was removed, as it was a bit unbalanced. This new system will share the bonus and is balanced so you don't get bigger bonuses from larger enemy teams. It's in your best interests to kill all of the hard enemies first, keep attacking them to a very low point, then finish the battle, to get more from it. Applied the general power of each enemy to the experience they give to an encounter, potentially multiplying it. Applied the general power of each friend to the experience they take from an encounter, potentially dividing it. The experience enemies give is based on their statistics, which are also multiplied by their general power when in use. So this whole thing means you get exactly the experience they're worth. Inversely, the experience each of your characters gets is divided by their general power, which makes certain you'll always get the right ratio of experience if you're buffed up like them. Changed rewards at the encounter ending state from being applied instantly to a partial application at regular intervals, the only reward needing more than a single interval being experience (If level changes happen). The point of this, in a future version of the game, when I have a lot more visual space to fit it in, and have redone all of the visual assets (Including interfaces), I'll be displaying statistical increases at level changes, which due to the randomness of them, is impossible to emulate if all of the level changing is done in a singular hit. The encounter ending reward counting will now do multiple cycles of counting (Multiple levels' worth of experience) if the amount of time between frames is large enough. It's a very unlikely scenario (Your computer shouldn't be performing so poorly), but it makes things more timely. Changed the encounter ending state from using a static maximum level to using the dynamic maximum levels stored in the user cores, for counting up experience right (Nullifying experience above what the users can have at their maximum levels). Changed the encounter ending state from using a static experience alter alter to using the dynamic experience alter alters stored in the user cores, for counting up experience right (The different amounts of experience needed for the user to reach higher levels). If the user gains more experience than is needed to level up to the maximum level of 99, the encounter ending state would freeze at trying to count above the change to level 99, both automatic and manual (The user skipping the counting) cases of it. If the user gains enough experience to level up multiple times while near enough to the maximum level of 99 for it to put them at a level higher than 99, they'd level up above their maximum. But in this case: the game would freeze at the encounter ending state, cause of the previously listed problem, so was unnoticeable to the user. Added storage for the user's score. Displayed at the menu screen. Moved level, currency, and time information, to make space. Scores are determined with a comparison of enemies' experience (Dependent on their present health) and friends', points based on the ratio of your experience worth versus theirs. Added storage for the user's highest scores, 10 slots. Displayed at the game screen. Moved currency, currency reward, and inventory reward information for score and score reward information. Changed encounter ending state to count experience within a second (Able to do so with any amount). If level changes happen, treat each level's counting as its own second. The more level changes, the more seconds (One second plus a second per level change). Added the ability to count experience downwards (For a loss). Rounded both experience and experience reward as they're being counted. Changed encounter ending state to count currency within a second (Able to do so with any amount). Added the ability to count currency downwards (For a loss). Rounded both currency and currency reward as they're being counted. Added a score reward to the encounter ending state. Added the ability to count score downwards (For a loss) and upwards (For a gain). Rounded both score and score reward as they're being counted.

Things have been very unstable for me these last few months. I was at war with a very likely homelessness from when university ended, which only recently has brightened up for me, thanks to the support of people donating via Patreon. My quality of life is very poor, but at least it's not going to degrade any time soon (I have at least 2016 as safe), which has bought me time to do more with my work, be more successful, and thus get more support and an increasingly better quality of life (At least this is the plan). Before my survival was secured, I was having regular mental break downs, with a death in the family happening within one of the later ones. Simply: Things have been hell.

As it's been so long since anything was said here, I thought it was worth while to check in, and let people know what's happening on my side of the world. Verisimilitude: Prototype has been progressing well enough, slower than I would've liked (I was hoping to have a new build out last month), and is nearly ready for another release (I only have to rewrite a large chunk of the animation systems. Literally everything else on the schedule has been dealt with). I've been advised by some supporters, people I personally know, that it would be a good idea to keep this place up to date with more frequent but smaller posts, so I don't seem to disappear for long durations. Personally, I rarely have anything worth saying which isn't progress in one of my projects, which would get repeated at the text wall of details upon releasing a build, so seems a bit redundant throwing the information out as fragments. At the top of the Site I do have a little chat system, which doesn't require you to make an account. If you want to give your thoughts on the matter, it'd be the easiest place to do so. Let me know whether or not more ramblings from me on the Site would be appreciated. Either way, if all goes well, expect a new build of Verisimilitude: Prototype in the very near future.

When I last put out a build of Verisimilitude: Prototype, I realised several design deficiencies with how it handled user actions, very significant ones which required a lot of rewriting to solve. Cause of university, that build had taken long enough to release, so I did so, and rolled the newly discovered needs in the do list for its successor. As such, this build largely exists to fix things, many of which aren't accessible to the player (But would be in the next build where I'll reimplement all disabled functionalities). Don't expect sweeping changes when you go to play it, simply know a lot of effort has been put in which makes it far more stable and future proofed as a whole. Also, as university has ended, I'm spending a good amount of time catching up on other duties, some of which have slid for years. This behaviour won't be changing for a long while, so expect me to be spending half of my time making good on a lot of personal promises between working to bring you more game oriented fun. Now, it's time to ramble through a list of changes, way too late at night, and hope some of it reaches you readers in a legible enough state.

Storage for an actions origins and destinations have been split in to general and specific ones. General is what is used to get things started, which will generate specific for every single user involved. When the time comes to store effects for displaying (One of the currently disabled functionalies, but a lot has been done about getting all of the necessary information stored for it), specific is what gets used to build the effect displaying storage, knowing who things should be shown over. The inputted action chain has been flattened for simplicity, making it a lot easier to check when an action is attempted. A layering system is used to know which order of different effect display types exist for the action, this hasn't changed, but what has is that it'll store layers for stuff which may go unused (So in a later version of Verisimilitude: Prototype, artificial intelligence can tell all of the things an action could've done and react accordingly). To follow the change of layering, the individual levels of displayed effects have their own identifying number to search for, so the ones which actually get used can be easily mapped for output. Added a unique identifier for the origin alter type: destination power, and the destination alter type: origin power, the 2 groups of trust values (Allowing for every possible future scenario, like a seduction move which may improve a trust state between you and an enemy artificially). Effect displaying storage itself has been flattened too, which in turn requires an origin/destination for each slot, accompanied by alter types for each (To know what group the value is being applied to. Flee for example gets applied to a whole team as one, not all of the individuals in it). With this flat storage, and the extra layering stuff for the sake of artificial intelligence, I can now store only slots I need, excluding any which'd normally be empty. For what ever reason, I forgot to stick storage in origin/destination power altering stuff, so this is in now, along with the logic needed to build it up properly.

The action chain is checked differently as far as where the memory is and how big it is, avoiding a possible crash scenario for both an empty chain and a chain too short when checking different level nodes (If it was a single node of "Magic", it previously would've attempted to load the 2nd node, regardless of whether or not it existed. This really largely just protecting from any mistakes I make coding in to the distant future, as they won't violently kill the whole game when discovered). Actions which may have multiple participants (Like flee) will now test all uses involved to see if they have the right action nodes for it, excluding them if they don't (A berzerker may be unable to flee for example, becoming a dead weight the other characters literally have to carry out of battle). This shared requirement also carries in to things like costs (A magic action will have a mana cost for everybody taking part in it) and the depletion of action gauges/queues. Cleaned up a lot of how the actions check their cost criteria, the temporary storage of data for efficiency's sake, some missing internal documentation, the application of some data on a per need basis (Not applying difficulty modifiers which impact action calculations in the scenarios they'd have no impact, for example), and the rounding of lots of data.

Fixed destination power altering of the destruction magic, which was using the health damage at the mana damage step. The donation skill wasn't using the right destination power for the accuracy/attack calculations, using the general destination versus counting through all of the destinations. The donation skill now uses an average origin power of you and all of the destinations, for calculating the currency thrown, which was using the origin power between you and the general destination. For the donation skill, it is possible you'll fail to throw any currency (So 0), but it'd store it as currency going down (Negative, when it should be neutral), in this scenario, it'd attempt to throw nothing, but still check for a hit/miss and check for damage (Which should be 0 in this case, but technically not, since nothing happened to even attempt damage), which is of course fixed by now. There was a flaw now fixed, in how the donation skill handled destination mana altering, a memory leak. For Flee, when calculating the powers of the origin side, the loading of origin power was broken, was always using the same origin (Not different characters of the side) for the origin part and destination (Not different characters of the side, and not only that, is set to origin, so the trust of one's self), which I've long since dealt with. Flee is the only action affected by the change mentioned earlier of how actions with multiple origins would determine said origins by who has a ready action gauge/queue, has the right nodes for the job, and can fulfill the other costs, which in this case means you'll only attempt to flee with the people on your team who have full action gauges, the other members being dead weights.

Cleaned up the loading of data groups not in loops. Did a lot of memory management for the main core, emptying temporary storage used for efficiency's sake (This was also done for a handful of lesser cores), also emptying game state specific memory when the game closes (The one last major part of memory management which needed doing. Technically not required, as the game has closed, so no real chance of prolonged leakage. But good practice to clean things up completely in all scenarios). Fixed a menu system memory leak, it wasn't correctly emptying its memory when going from the menu system to the exploration one. Deleted some dead code from the audio core, which was what was replaced in the last part release. Had a leak with action chains being inputted for use, which would happen each time a new action did, the old chain not being cleaned out when replaced with the new one, all of which has been handled. All interface inputs which had a timing of 0.1 are now 0.2 the first time, followed by 0.1 forever after, this is to help users not over shoot. Audio pauses between game states (When memory things are happening), so it's synchronised with playing the game. Fixed the inputs for toggling the pause and map features, which were using the wrong key combinations. Cleaned up scenarios in which pressing the right alt key would change the timing of keys normally used for movement inputs which suddenly become toggle switches for other functions. And lastly, fixed the ability for users to decrease/increase their levels naturally, which was failing for the longest of times due to memory mismanagement (Seriously, nobody reported this in what turned out to be about a year's worth of public releases. Very disappointed with those testing it. The act of experience changing wouldn't be enough to trigger the level changing event, having to instead use the built in cheat for it to get anywhere).

All of this nudges the next version of Verisimilitude: Prototype's state of completion from 92.94% to 93.253%. As always, sorry for the possibly unreadable text wall. It's nearing 4am and has been a long day, so not the most legible thing I've written. At this point, there are 3 more builds planned to complete this version of Verisimilitude: Prototype. Let me know immediately if I've broken anything, so I can roll the fixes in to the next part release. Any who care to support my work, especially in a time I'm struggling with the chances of homelessness, I have a Patreon page for such things. For those already helping with what they can on there, a shout out of thanks. It's much appreciated and your continued generosity motivates me with the warm feelings of knowing "People like what I've done enough to fund my efforts to continue making more". Peace out.

I won't attempt to estimate a release date for the next build, but (Hypocritically against the first part of this sentence) I'm leaning to within a month. Late in to the development of the last, I discovered many flaws with how I'd designed the action handling system, none of which were detectable to the players, but very soon they would be (When reimplementing the currently disabled functionalities, like the items and flee actions). It's been a rocky road, untangling this mess, so tangible productivity was a later starter as I had to thoroughly future proof things. As such, the next part release won't feature much in the way of noticeable changes from the player's point of view (The exception being a handful of fixes to what was already detectable, and some changed logic for the currently accessible user actions). The follow up will be when I put back in everything missing, so will be the one to wait for.

As university has finished, I've taken the opportunity to catch up lots of priorities that have fallen to the side through the last so many years, which in itself is partly the cause of Verisimilitude: Prototype's latency now. I've done a lot in regard to this, but the list is long. I can't promise game development will speed up in the immediate future, but my efforts are very near a point they'll begin snow balling down a hill, so I hope to have a lot done by the time this year comes to a close. As always, thanks all, for your continued patience while I keep working on the things I love, in the hope you'll love these projects of mine too.

It's been a very long while since the last build of Verisimilitude: Prototype was put out, about 5 months. Several days ago I finished it, and have been piecing together the lengthy amount of documentation accompanying its changes. After the delays brought by the heaviest and last semester of university (I've now graduated, for any who've missed it. University will never take valuable work time of mine again) it is now time to show all of you what I've been up to.

I've installed the newest version of Java my computer's operating system can handle, bringing it up from 2013.3.4 to 2015.4.14 (My modus operandi is to only upgrade my software when I begin/end working on a whole version of a project. I've done it this time prematurely as no newer versions of Java will be installable until I have a new computer for them), which includes 227 security fixes and 177 bug fixes apparently (I don't know which of these will affect performance and stability, that'll be for you to discover). During this, I rechecked 3 known errors and found them to be Java's fault, so I can't do anything about them myself: When closing Verisimilitude: Prototype, it crashes during closing due to Java running its built in life time methods out of order (Which in turn trigger mine. The method for running general behaviour gets called once after my method for closing down all used memory, which wouldn't be a problem in any other sensible environment/language). The action timer's core has inaccuracies in its time keeping which make the speed Verisimilitude: Prototype runs at constantly fluctuate (Can be out as far as 20% I've found).

Changed the way images are loaded to be more general purpose, making Verisimilitude: Prototype more application compatible, which lead in to porting to an application variant. This variant is centred based on the screen size, sized correctly with the borders included. While the window can't be resized, I've added a clipping region to Verisimilitude: Prototype doesn't attempt to draw outside of that region, which is good for efficiently and especially applicable to the applet variant (As the page it's embedded in can be zoomed, breaking the display area), in which case the area clipped defaults to a black colour. Storage has been changed from Zip to JAr, with both the applet and application variants in it, allowing me to put up a single file which will both run as embedded (For those with web browsers and plug ins which support it) and can also be got and ran like any executable, as long as any form of Java is installed.

Subtracted, changed, and added comments, which were wrong before this release. Cleaned out useage of the Calendar library in the main and audio cores, which were used for timing, but aren't needed now as the action timer core handles this. Added storage for an all encompassing pause system, with its data created (With default values) and destroyed as needed, which includes timing information for transitions, but isn't utilised yet. Did a clean up of some variable names, mostly video/audio stuff. Changed audio toggling to not happen during transitions. Gave audio a general state (For starting/stopping when the player pauses Verisimilitude: Prototype, later when this feature is implemented beyond the encounter system) and a general power (For muting/unmuting audio as a whole. Presently specific power isn't touched, but would be for audio controls). In the menu core, an error was fixed with the range of outputtable slots, which wouldn't adjust the first/last displayable slot if the amount decreased for how many slots should be shown. Deleted font storage, simply setting font straight by code now. Fixed a long term regression, the map wasn't toggleable during interactions. Change the lighting in level 1.3 at the entrance/exit from/to level 1.2, which was lighting for a double sized door. Fixed the Leviathan to display under/over the user depending on the user's translation, which fixes a regression from the last version of Verisimilitude: Prototype. Fixed a minor memory leak in the ActionGeneral core (Which handles a user's action logic), which wasn't clearing it's ActionSpecificIn/ActionSpecificIdentityIn storage (Which stores the type of action the user has, and in this case is specifically the action which should be run through ActionGeneral). Cleaned a lot of the health and destination power (The target's trust of what is coming their way, which how much they evade/defend is based on) logic of the ActionGeneral core. Made the rounding of the restoration action's results more efficient. Fixed the donation skill, which calculated how much the destination's power should change from mana damage, which of course should've been based on mana damage, but was calculating from health damage. Fixed a small memory error in the dynamic transformation core (Which stores the translation, rotation, and deformation of video objects, and handles collision detection), which was recreating a bit of data every action. Also did some minor memory fix to the dynamic transformation core, both its internal and anything coming from an external source, with a extra effort put in to the inputs of the latter.

The inputs have changed for pausing (From P to right Alt and U), audio toggling (From N to right Alt and F), levelling up (From L to right Alt and L), and map toggling (From M to right Alt and M). Added extra outputs to the action timer core to be used with its new more advanced interface. Instead of only constant showing the current speed (Which was partly done for testing purposes, and I intended to eventually delete), performance information is toggleable with right Alt and A. Other inputs are included which affect the information given, which are: The input state (Whether or not the input count should be paid attention to. Runs at full speed if off) toggled by right alt and B. The output state (Whether or not the output count should be calculated. Pauses if off) toggled by right alt and C. Decrease the input count by left alt and D, to as low as 1 count per second. Increase the input count by right alt and D, to as high as 999 count per second. Toggle the output type by right alt, E, and 1 (Per second) or 2 (Per action). Added origin trust values which multiply accuracy/attack per action (This represents how much a user trusts their own actions). Origin trust values are changed based on the effect of actions, bad/good making it worse/better, determined by the amount of health or mana lost or won versus double the maximum (Accounting for negative maximum). Added storage for action intention flags, which are what determines which direction the origin trust values move upon an action happening (Whether the expected effect was a negative or positive one. If what was expected is what happens, trust goes up. Vice versa if the opposite happens, like using a elemental damaging ability which upon use is discovered by be absorbed by your target). Inputs for changing what your intentions are were implemented, but without any interfaces as of yet (No way to tell what they're currently set to). For the sake of being thorough, the inputs are: Right alt, G, and a number between 0 and 3. 0 is automatic, flipping all flags which are used by the action. 1 is manual, single side and single user. 2 is manual, single side and multiple user. 3 is manual, multiple side and multiple user.

Added comments to level/map stuff in the transformation dynamic core, which is there for collision detection. Change the ability for finding collisions from per 4 arxels to per 1 arxel. Fixed collision walls which had the width axis adjustments flipped, so being the smallest bit outside of range would let you walk through, which has been changed to the opposite. Changed the coordinates upon entering a different level, to always be centred on the entrance. Fixed collision detection, so coordinates are right. Fixed interaction collision, which wasn't detecting the leftward/rightward walls of the Leviathan. Changed from 4 keys (Arrows) to 8 keys (ACDEQWXZ) for movement, which changes the possible directions from 8 to 32. Changed user's velocity to be the same speed for diagonal as for horizontal and vertical. Changed user's speed to be more 3 dimensional, slower vertical and slower vertical within diagonal. Changed user's walking visuals to animate slower. Adjusted coordinates of maps, which were off by a single arxel (Needed for the borders to line up with the levels). Fixed every maps shape, so they match the levels they're for.

The forced level changing of users via inputs has been limited to no longer be attemptable outside of game states in which users exist, which was a crash worthy bug. Level changing downward now has an input of left Alt and L, to test the robustness of this feature (Due to the randomisation of statistics both ways, you may go back to an earlier level with less/more in any statistic than was had previously). Cleaned a bit of the level changing logic of the user core. Fixed Fenrir Wolfbane's initial growth for the agility statistic, which was a step ahead of where it should've been. Fixed the order things were done in the level down logic, which wasn't correctly reversing the behaviour of levelling up. Changed the level alter method's ability to alter statistics by a static or dynamic amount to do so individually, each statistic now having its own flag (Previously there was a single flag which covered everything). Added multiplicative alter values for each statistic and each statistic's alter values.

Rounded all cases of timing for better precision, specifically the action timer and audio cores. Changed the average time between encounters from 2 seconds to 3. The rate action gauges fill has been rebalanced from an aim of 1 second to 3. Health/mana generation in the exploration state has been changed to happen inside actions. Destination power generation in the exploration state has been changed to happen inside actions. Added health and mana regeneration to the encounter ending state. Added destination power generation to the encounter ending state. Added origin power generation to all game states destination power generation exists for. Fixed health and mana penalty which were failing to calculate correctly if the other statistic was above 0 to begin with. Fixed whole number attack/defence addition/multiplication alters to not show parts (An attack of 1 should show as 1, but was showing as 1.0). Statististics affected by difficulty are shown in their altered states (If difficulty is set so you have a general power multiplier of 2, your statistics will appear as such, instead of only being able to tell indirectly through the results of actions. No interface exists for changing difficulty, so this is all just structure in preparation for the eventual ability to do that). Apply power to health and mana when calculating cost of healing room. Apply power to statistics when calculating experience given per each enemy. Difficulty affects health and mana in all of the other cases it should too. Resized experience bars in the encounter ending state from 107 to 105 arxels, which would've over flowed in to the surrounding visuals otherwise. Fixed experience bars in the encounter ending state, which weren't showing the correct data most of the time.

Future builds should be closer together, but I'll be working on more than one project very soon, so any progress not made for this will instead spent on them. The point being, everything will be moving forward, so with enough patience, it'll all get out there. Let me know if anything's broken so I can fix it swiftly. Whilst you test and play, keep in mind I have a list on Verisimilitude: Prototype's page for all known problems (Including functionalities I haven't reimplemented with the new systems).

I lost my web for near to a week (5 days), at which I've had my spiders hard at work, fixing everything. My graduation from university was today, for which I spent a lot of yesterday readying myself for. Progress has been made on Verisimilitude: Prototype, but not as much as I'd like. I have a handful of things to do and then I'll be putting out a build for all of you to play with, whilst waiting for what I'll be making of the next one.

Progress had been coming along very nicely until the last few days, in which I've become increasingly sick, with hot weather not helping one bit. I was also down to literally 3 remaining things to do, 2 of which being mostly done now. I won't go in to specifics on them, but I discovered, while implementing what I have, numerous long term errors in the user action logic which need to be fixed. I don't know yet how fundamentally things will have to change, as the delirium of being unwell is ruining my chances of focusing my mind on anything for too long, memory becoming scattered with any train of thought. Since I can neither predict how long I'll be feeling better, as I'm still in a downward spiral, or the size of potential alterations, I decided to check in and alert everybody to unknown delays. I'll do my best to get back on track, but being burnt out is probably part of the problem, as I've been putting in way too many hours daily since university examinations ended for me.

This is largely a simple check in, so people know generally how things are going. University finished for me recently, so I've been spending all of my spare time since working on Verisimilitude: Prototype. I've got my marks back, which were very high, so I'll be graduating soon, meaning no more university taking time away from my work. The scope of this build has been creeping larger for months, partly why it's taken so long. The more I do, the more I find which can be made better. A lot of what's going in to this build is hidden polish thoroughly applied to it's inner systems, so when finished, don't expect much in the way of obvious changes. I will detail everything different, the list will be long, but again, little will be noticeable.

Keep regularly returning to the Site, as I'll be done with this build of Verisimilitude: Prototype very soon, and will require significant testing. I want to be certain it all functions as it should, so I can go in to it's follow up cleanly. Its successor will be restoring all of the old features, so I will no longer need multiple builds online to play, as it will be fully functional. Stay tuned.

After a long while of server problems, I've found a way in to my account to continue development of the Site. I don't know exactly what's causing the issues, but I'm unable to directly access cPanel, which is the administration and moderation tools for the server as a whole, very useful stuff. I had to find a back door in, due to a reroute leading in to an time out. Once I got in, I went straight to trying something I recently discovered, to fix a long due complaint of the Site, its readability. I've generated a black glow around all text so the colourful background can stay as colourful as it is but not make things hard to read. As this is kind of experimental, I'd appreciate any feedback, so I know whether or not what I've done is perfect as it is.

University is nearly finished, so I'll be able to get back to work fully soon. Don't let these last 2 bits of news fool you, Verisimilitude: Prototype is still the priority. In fact, I plan on doing another 2 builds of Verisimilitude: Prototype before resuming work on the Site, which will bring it up to the point all of the old functionality is back in place, so I can get rid of that old stable build from nearly a year ago. The schedule is 5 builds of Verisimilitude: Prototype to finish the new version of it. As far as this version of the Site goes, not much will be in it beyond this text readability fix. It'll largely exist to allow user accounts, project ratings and comments, and absolute standard compliance with each language it uses to be in effect (XHTML isn't fully compliant, and while PHP was, it's so out of date that there are aspects of it which are deprecated now and throw a lot of errors). The new version of the Site will be a temporary measure so I can have all of the old and new content back online while waiting for the big release of the Site I've been planning for ages and will move to directly after this one.

Oh yes, the title is correct, some development for the Site has been done. For so long, this abridged version of the Site, with nearly all of the content missing (For at least a year, there was no content, simply this page), was all that was on offer here. The hope was my plans for the new Site would be done soon enough, by now a long list of incompetent people who failed miserably at it, while I was focusing on other projects to bring the content up to a standard of quality I'm happy with. Currently, something is in development called Element, which largely exists to replace MySQL as where all of the dynamically generated data of the Site and eventually the Forum (The real one I'll make, versus the temporary phpBB one which nobody bothers using). To coincide with Element's development, I've been kicking up the Site recently, preparing everything for what I've been planning for a long while.

As what I scheduled for the Site so long ago is so big, due to the reliance of the Site in the long term on Element, and keep things clean for archiving purposes, I'm derailing myself a bit. I have 2 new versions of the Site planned for the near future (I'll be dedicating a lot of time to these through the next year), the 2nd being the whole big one I've been talking about for years. The 1st on the other hand will be a merge of the current abridged one and the old full one. The point of it is so largely bring things back in to a linear line of version numbers to make storing old copies more straight forward. For the 1st version, I'll be readding all of the old content (Power technology demonstrations for 0.0.1.0-0.0.4.0, Lost In Space, and Matter), adding previously unrelated but still relatively old content (Power technology demonstrations for 0.0.5.0 and Virtual Velocity: Prototype), updating all old code to follow the current standards of each used language (XHTML, CSS, and PHP), especially anything which failed at this in the first place (Verisimilitude: Prototype, which was never embedded in the page right), cleaning things up and relabelling in the direction of how they'll be long term (Largely preparation for the 2nd new version of the Site), putting back in any old dynamic elements (User accounts, the ability to rate and comment on projects. As we'll be using Element by the 2nd new version of the site, the existence of user account data and everything related to it is fleeting, so new accounts will need to be made later with the new system, but I'll definitely take your thoughts on board for the projects you give them to), and merging hit counters (Again largely for a clean archive, but with the 2nd new version of the Site, these will be refreshed so I can better keep track of the audience of my work).

At this point, I've done a minor clean up of the Site's front page, with the majority of it focused on the project listing part. Many projects have been relabelled to their current names, listing any platform dependencies they may have, and listing any present details for them (When work was last done for them). I have projects which I consider active, as they'll have a release within the next phase of them, but if no work has been done for them, or no previous versions have been put out, they aren't listed at the moment. As all projects listed are active, the ones which don't have a future version listed are indeed still on my radar. Beyond these, there are 3 projects no tangible work by me has been done on: the Forum, Element (Which is being worked on by another member of the team. I have a tight leash on it's design and the direction it's taking, and a good amount of progress has been made, but I don't know specific dates and times to bother putting it up yet, nor how complete it is, as they aren't keeping the same thorough track on it's development as I normally do), and Peace And War (The generic name is purposeful, as how it's presented is largely abstract and up to the player's imagination, but multiple versions of this have been thoroughly planned out through documentation. For now I'll say it's the first game I'll be releasing which supports multiple players, in fact focusing on them. It's a turn based cooperative/competitive tactical/strategic web browser game).

University has been taking most of my time, so I can't promise when the 1st new version of the Site will be done, I'm doing little pieces when I can. Nor can I promise much in the way of Verisimilitude: Prototype progress for the near future. In the case of Verisimilitude: Prototype, work has happened, and I'd like to put a build out during this month, so you have something more stable to play, but don't know what will make it in, so I won't bother listing potential items now in the case they don't make it in time.

Too little of a change to the percentage of completion to bother noting it here, due to the priorities of this new build of Verisimilitude: Prototype. The last build was extremely ambitious as to what was to be rewritten, redesigning things to future proof them, and thoroughly documenting them for an eventual porting to ActionScript (By a team member I'm training, partly as work experience for them, partly so I can focus on developing new stuff, and partly due to all of the inconveniences of using Java, which ActionScript will improve upon. I don't like the idea of stopping bettering Verisimilitude: Prototype to rewrite about 500 pages of code in another language, which is why that'll be done after this full version is complete and thus released). Due to a mess of notes, there's a lot I've probably missed saying today, but it's all either clean up or fixing bugs old and new (Which weren't in the last stable version, so don't count for permanent logging purposes). As I ramble on and on, you may be wondering what exactly I have done. The details will follow, but put simply, the priority of this build was largely spent on finishing on all of the paths I took up with the last build, tying loose endings, fixing things (Especially some long standing issues I was made aware of shortly after the last build was released, despite tracing them back as many months old at the very least), and finishing artificial intelligence. This last part is important, as it makes Verisimilitude: Prototype too difficult to play if you don't cheat. The next build will readd character animations and the displaying of effects in battles, both of which will cause pause events, slowing things down a bit, but for now, enemies attack too fast for you to humanly react. If testing, forcefully level up so you can let me know what doesn't work. If simply here for fun, go back to the older build, which is feature complete unlike this one, but significantly less developed. Now this rant is done, on to the specifics I go.

Added flags to the action timer core for its inputs and outputs, the former tells it whether or not to aim for a speed and the latter to calculate its performance for displaying. Fixed a long standing keyboard input problem, which would happen if either pressing and releasing or releasing and pressing a key fast enough to do so in a single frame, through bad timing and luck (As a part of this fix, the press and release events negate each other, so it's impossible to have both events in a single frame). The mouse input had the same changes made to its event handling as keyboard input's, press and release events negating each other.

Fixed transitions between game states to wait the full duration before going to the next step, with the duration now having a time I can easily change for all cases. The timer keeping track of transitions has changed from 32 to 64 bits to line up with all other instances of timing (This allows for significantly more precision, which'll be especially useful in a future version when I have everything timed to run at the same pace). Changed the encounter ending state to not try displaying anything during the beginning and ending phases, when memory is being shuffled with stuff being created/loaded and destroyed (This is when the screen is black, so there's no point. Plus, when the assets are being dynamically managed, attempting to display what hasn't been created/loaded will likely cause a crash).

Commented general storage in all cases of specific use (Cores exist which have a place for data, the purpose of which isn't known until in use, so this helps document that). Loose bits of commenting missed in the last build was done this time round, which are too many and too minor to list. Rearranged the majority of the assets, excluding the user's imagery and everything for the encounter state (Priorities of the next build include thorough systems for animation and giving the encounter system a place for its graphics and their transformations, which needs to tie in to the way animations will work). Changed "title"/"intro" (Audio was listed as latter) game state to "game", the "explore" game state to "exploration", the "victory board" game state to "encounter ending", and the "game over" game state to "game ending", both in the code and as the assets. Deleted a duplicate lighting image, level 1.5 had a copy of 1.4's door lighting, which was wasting space when it should've been using level 1.4's graphic for it.

Rearranged some exploration level and map changing logic to line up with the menu system equivalent. Flipped the values for where you are in a conversation to make more sense and be consistent with everything else (The least significant value was on the left and most on the right, everything else having this the other way around). Fixed the healing room, which would fail to change states in the case you say yes, need healing, but don't have enough currency.

Cleaned up all of the user action search algorithms and future proofed them so they wouldn't break if the amount of disabled and enabled user actions changes during battles or the menu system. Fixed a memory leak when destroying user actions, which would fail to go to the children of a disabled action, ending and emptying them.

Fixed artificial intelligence to not be blocked by a friend's side character being ready for an action (This was a problem in the last build's code, which wasn't able to have user actions happen for enemies, but should've been trying to in all cases, including this one, despite the algorithm for doing this being empty). Enemy intelligence is fully in (This includes structure for real intelligence later, with parts to determine which actions to use, who the destination is, create an action chain, and throw all of this in to the enemy's action handling core). When health was altered by an action during battles, health wasn't been rounded in the calculations leading to gauge and queue changing logic (Going down to 0 wouldn't empty these if really at fractionally above 0, with the same problem going the other way), this has been fixed.

I'm back at university now, have been for the last 2 weeks. I'll try to continue developing things between assignments for that, but it'll be very random as to what is done through the next few months. I have a big list of things to go through though before going back to Verisimilitude: Prototype, so expect new things here at some point in the near future, if not a new build of that. Although I'd like to have something new released which contains all of the old missing features at some point during this semester. Stay tuned.

So much has been done between builds of Verisimilitude: Prototype, so much that I've lost some of it in my log. I was changing the percentages some of the times being done and not moving them to a short list to summarise here, so things have happened which I can't talk about knowingly if I don't waste time going through the whole long term log to determine what's missing from the short one. Due to a messy work flow, these notes may be hard to read, but I've tried to group them meaningfully. Before getting in to the details, I'd first like to say some generally noteable things: Verisimilitude: Prototype's percentage of completion has changed from 87.138% to 91.246%, the main core's permanent code from 68% to 81%, the whole game's permanent code from 79% to 88%, the size of the code from 607 kilobytes to 955 kilobytes, the last of which amounts to 481 A4 size pages with a font size of 10. All in all, a lot has gone in to this, thoroughly fleshing out what was already there while reincorporating many significantly redone features whilst cleaning things up for an eventual ActionScript port by one of my employees once this whole version of Verisimilitude: Prototype is finished. Now, in to details of what's different this build.

Cleaned a lot of code for memory management, making it more efficient and handling bits I missed in earlier builds. Made the naming schemes for data more consistent. Subtracted the forced case of garbage collection (Telling it to deallocate all of the memory which is unused) which would be thrown at the Java Runtime Environment when creating and resizing the screen (It turns out Java can't handle this efficiently, more memory used by pushing for it to be emptied, stupidly). Changed all cases of depth to height in transformations. Added transformations to the menu system to unify their useage with other systems. Made 2 small fixes to the audio output core: The loop count input/output was incorrectly using the loop count maximum and the loop count wasn't defaulting to 0 once the maximum had been hit and the audio had stopped. Fixed how actions' states were handled, an action's state was ignored when handling inputs and outputs in all cases excluding the action itself being triggered, so it would display disabled actions, let you reach the targetting stage, and attempt to use them, only blocking you at the last step of this. Fixed the experience bars in the menu system which weren't displaying anything. Change the experience bars in the menu system's size from 107 to 105, which is what they should've been, it being possible for the visuals to over flow their assigned area with enough experience. Swapped characters of the user's side so the 1st is nearest the camera (At the bottom) and the 4th is the farthest (At the top). Scaling of character visuals during battles has been subtracted, to make a better attempt in a later version than this. Fix a crash which happens When one of your characters is active and in a sub action menu during a battle when they die, which caused the array of memory to go outside it's boundary. In battles, added output data for origin side of actions, which mostly covers costs of actions and in the case of spells, potentially health damage if mana goes in to negatives.

Added the ability to have as low as negative maximum mana, which can cause a health penalty. Added negative generation for mana when it's below 0. Adjusted changing of trust values for the mana case, now mana can go in to negatives. Added rounding for health and mana for some of the internal calculations so it'd match outputs. Added health penalty which happens when losing mana in to negatives (Which could be caused by health damage or use, the latter for future actions which may damage mana), balanced as an even ratio for the negative part of the effect only. Added mana penalty which happens when losing health in to negatives (Which could be caused by use or health damage, the former for future actions which may have a health cost), balanced as an even ratio for the negative part of the effect only.

Changed the donation skill to round how much currency is thrown and how much is thrown at each of it's targets when there are multiple users being aimed at. Did a lot to fix flee which was very broken, too many things to list, simply that it had no chance of working as it was. Fixed multiple origin synchronisation, which currently is a flee only ability, so flee can't happen in an encounter if all characters on the side doing it aren't ready for it, needing all of their action gauges to be filled, excluding any who are unconscious or dead. Added a special case for flee, in that it can happen if there's only a single side. It always succeeds In this scenario, but is a neutral effect instead of positive as there's nobody to flee from. Generalised flee's calculations to work with multiple enemy sides.

In the encounter system, action gauges and queues are back in, with a handful of differences from their predecessors. The action gauge fill speed is now adjusted by a user's health. If a user has negative health at the beginning of an encounter, their action gauge will automatically be empty. Changing a user's state from positive to negative health will empty their action gauge and subtract them from the queue if they're in it. Changing a user's state from negative to positive health will randomise their action gauge and add them to the queue if their action gauge is full.

Defaulted target selection to your side of a battle, mostly as it's a good neutral position when dealing with multiple enemy sides. Changed target selection to be 2 dimensional, not 1, with it's inputs, with left/right changing users (Would normally change sides when run out of users for a side, which has changed to simply jumps between the last/first user of a side) and down/up changing sides. Gave target selection independent storage per side, so friend and enemy targets are stored separately, meaning each character on your side remembers the last target they had for each side there is. Altered target selection to no longer ignore dead enemies, which means it doesn't skip them when changing your aim and doesn't jump to the next one if already on one which is now dead upon the next turn. Numbered targets by side instead of an absolute value for the whole battle, so friends 1-4 and enemies 1-4 versus target 1-8. Reformatted text accompanyment of target selection in encounters from "Target - ?" to "Side: ? - User: ? - Name: ?". In the menu system, target selection with multiple targets shows a white box for the primary and grey boxes for the secondaries, making it easy to see who exactly is being aimed at of the group. In the encounter system, target selection with multiple targets shows a cursor above all of them, full size for the primary and half size for the secondaries, for the same reason as the menu system's case. When there are fewer than 4 characters on the friend side of an encounter, one of them is being targetted, you attempt to change the target by the left/right key, decrementing/incrementing your aim, and any friends/enemies from the last/first to beyond are dead, targetting will go to the last friend/first enemy, who is dead in this case. This is automatically corrected at the next frame, but means for a single frame it won't display the graphic and it's text for who the target is, instead showing the action information normally hidden by this extra layer.

As far as missing functionalities go in this build (The reason why I still have a much older but more feature complete build available): Enemies can't do anything (Half of their logic is in place, in that the action gauges and queues for them work, but they never build up an action chain to attempt using), animations during battles don't work yet, effects are never displayed, and both item based actions and flee don't work (I know I listed a lot of fixes for the latter, but that's to do with it's internal calculations. Both of these have logic finished for when they're triggered, but nothing is done in the main core to handle flee's potentially successful result and items don't have a conversion system in place to make them in to action instances where applicable).

University officially starts up for me on the 13th of June. I believe I'm through the most substantial rewrites of Verisimilitude: Prototype as far as difficulty goes, so future developments should be easier for me. The goal is to put out another build before university drags me down, but no promises as these schedules rarely go to plan.

While I've been quiet Verisimilitude: Prototype has been progressing nicely. The big delay amounts to this being the first time I've directly tackled the encounter system's code, which was the most broken part of Verisimilitude: Prototype. The new build is near enough to finished that I'm betting it will be done in the next week or so, at which point I'll of course go in to detail about the changes made, but for now I'd like to do a summary so it's clear I haven't been idle.

Negative mana is in place, with downward generation if you ever reach that point, part of a redesign to allow for moves of desperation (Which isn't finished, but amounts to being able to use spells while losing mana in to the negatives, but as a penalty, losing an equal ratio of health as part of the cost.). This goes both ways in that if health is lost in to the negatives by an action, it'll cause a mana penalty (In a later version the term mana is going to be more generalised as energy, which will help this relationship between the 2 statistics easier to understand. One again, this isn't finished, as this is what I'm currently working on).

A lot of far better memory management is in place, with a big clean up of that and other minor broken bits not worth going in to detail today, which includes a rounding fix for health and mana useage for the internal logic, whether or not an action was enabled being ignored by the interface (To make things easier, characters have all of their actions upon creation, with the plan for some to be disabled, activated later by certain criteria. In the case they were disabled, they were displaying and letting you select them, doing every step up to using them, which was the only part of the code this important information was taken in to account.), and lots of fixes to the flee action which was very broken (While the action itself works, there is nothing in the main core to handle it's results, so flee won't be useable in this build.).

Target selection has been fully rewritten with a lot of fixes over the old code, no longer treating all characters as a single line of selections, so left and right arrows change user and down and up arrows change sides. The text output has changed to reflect the side and user paradigm. Actions which have multiple targets will show multiple cursors over each of the group, with the primary target's cursor at full size and all others at half (This granularity means you'll always know exactly who you're looking at, if you decide to go to a single target action shortly after.). The action gauge is mostly in, it's speed impacted by the health of each character and a general adjustment value (Which will be impacted by a later difficulty setting when I implement that.), but while it randomises at the start of a battle and fills up, it doesn't empty when an action is made, empty when a character dies, or randomise again if a dead character is resurrected. Similarly, the action queue is also partly done, correctly queueing up characters when they're ready, but is missing functionality for the same scenarios as the action gauge. All of this effectively amounts to a big chunk of the encounter system being rewritten, with far more to go in future builds.

To support the remaining bits needed for the action gauges and queues, the core for handling action logic had it's outputs heavily rewritten to cover all cases, with all of the data there now, but not implemented through the actions fully yet, with only attack working with the new data at the moment. Lastly, I've regressed the scaling of characters during battles, as I didn't feel I could adequately do what I wanted in the constraints of what systems will be available for this whole version, or that the time commitment was worth it when there's so many other more important priorities. I've also flipped the positioning of the characters on your side, so things'd make more sense in a future 3 dimensional expansion, for the camera's point of view.

Unfortunately for me, I'll have to rewrite most of this when I actually finish the build, as I can't expect people to trudge through pages of text to see everything leading up to the current changes, so expect a lot of this to be repeated when I release what I've been doing. Also know I've been winding up development of the Leviathan Eternal - Site, the Leviathan Eternal - Forum, and something to handle the data of both which I'll get in to detail about later, but will likely extend the work period for those projects if they're going to be done to my high standards.

A new day and with it a new build of Verisimilitude: Prototype, which pushes up the percentage of completion from 85.677% to %. This release continues my efforts to implement the user action cores, bringing useability up significantly, but stopping a bit short of having it fully functional, for a good reason. I'll go in to details soon, but the general impact this build has is applying the user action cores to the encounter system. As I was changing all of the logic to work with the new code, there was a lot of old stuff which due to how it worked was so incompatible that those bits would've required a lot of temporary translation layers for the sake of the old and new interacting properly, a big waste of time. I've rearranged my schedule of the next few builds, pulling the encounter system rewrites to the build which will follow this one, so I can have everything functioning again. The reason I didn't bother for this release is how much more time it would take to put something public, plus the need for people to test things as they are so I can catch some of the flaws and fix them.

Firstly I'll list what hasn't been implemented (Which is why I'll have 2 builds available for a while longer.): During encounters, action gauges aren't depleted when a user makes an action, animations are never triggered, and the effects of user actions aren't displayed. Enemies are unable to perform moves themselves as they need completely new intelligence to be programmed in that will work with the new cores, so it's impossible to lose battles except by your own hands. The donation skill which I said with the last release is now something that can hit multiple characters on a single side, the visuals of targetting don't take this special case in to account, so only one arrow will appear (This ability still potentially damages other enemies, there's just no sign of it beyond their eventual deaths.). While items are obtainable, they never translate in to actions for the users, so they can be equipped in the equipment page and moved and dropped in the inventory page of the menu system, but not used like they normally would be (The logic is in place for using them, once useable items have been converted in to user action instances, but that conversion isn't in place yet.).

Now I'll go in to the changes made for this release: One of the biggest changes for this build is I've done a lot more implementing of the user action cores, for the encounter system this time round, which isn't finished as per the missing bits I mentioned before (Anything I didn't list as not functional can be assumed to be in place to the same level of useability as the older of the 2 public releases for this version made available. If any of that is found to be broken, promptly let me know so I can roll fixes in to the next build.). Added to the menu system's ability page and the encounter system the ability to remember the selections of individual user action groups instead of having a single value per depth, so the magic, skill, and item groups all have their own memory. Added to the encounter system the ability to remember each character's depth of selection, so the depth each character is at is remembered when swapping between active characters or using an action with one of them, meaning only having to navigate through the interface for future actions if they're different to what is already selected from the previous action made, quickening things. Generalised the ability page of the menu system's and encounter system's inputs for potentially infinite depths of user actions. In the ability page of the menu system, if the user has no actions they can use, some inputs are disabled, specifically the arrows and enter keys, and some outputs are disabled, which amounts to only the selection box not being displayed (This only happens for 1st level actions, 2nd level and deeper already doing the information part by default.). In the encounter system, if the user's action gauge is full and they have no actions they can use, some inputs are disabled, specifically the arrows and enter keys, and some outputs are disabled, which amounts to the action interface graphics, the image for an action's information, and the selection box not being displayed (This only happens for 1st level actions, 2nd level and deeper already doing the information part by default.). Added health and mana generation to the menu state, like the explore and encounter states, generating from 0 to their maximums within an hour, with health's generation direction being based on if it's currently at a negative or positive value. Changed the trust values all characters have to also generate much like their health and mana, to their default values within an hour, their defaults being dependant upon if it's the trust of a character on their side or the other side, and this happening for the same 3 states as health and mana generation: The explore, menu, and encounter states.

The following is a list of fixes made to specifically target anything I broke with the last build (Mostly, with exceptions made for a handful of long standing problems I recently discovered.) or was simply wrong: Rearranged the action timer core to better handle its inputs and outputs. The action timer core is now used directly by audio objects, which were redundandly calculating their own timing data up to this point (Mostly used for looping and keeping track of music when muted.). All video objects for the explore state which weren't using the transformation core now are (For consistency and the eventual unification of video output.). Collision detection with the Leviathan had it's width axis walls too wide and it's depth too far upward, this has been corrected. The healing room was outputting currency needed as a part number, which is back to being a whole one. Condensed a lot of memory used for inputs/outputs of interfaces, especially the menu system. The side of user actions' origin and destination wasn't being set in the menu system, which would've lead to a big problem if an encounter has happened at any point (It would've potentially had actions be done by and at enemies which don't exist in the menu system.). The biggest instance of fixes were applied to the donation skill, especially it's mathematics which had multiple crash triggers, which aren't worth going in to beyond the fact donation never had a chance to work as it was (In the impossible case the user got some currency to try it.). Any calculations for the 1st digit's worth of currency being thrown by the donation skill was erasing any successful hits before then. With the donation skill, each successful currency hit stacks the whole value of the digit being checked, instead of the single units it was supposed to be trying for, meaning up to several times more currency would appear to be used, becoming exponentially worse with stronger characters and more currency to use. Inventory and equipment weren't being loaded in to the user action cores right, which was a point of failure for the donation skills and any of the items (If the latter had been fully implemented, items currently not translating to actions for this to be possible.). Flee, which has an automatic targeting system based on who's using it, was setting it's target based on it's target instead of who's using it (Meaning when used, the characters were effectively trying to flee themselves.). The reward of experience given when a battle ends is supposed to be determined by calculating the ratio of live characters on your side versus the total amount of characters you have, experience being divided equally between them, but this was breaking when any dead characters had negative health, a bonus fraction of experience being given to those (If there were 4 characters, 1 dead, the dead one would get a third of the earnt experience from out of nowhere.).

I've been going through a low patch recently, which is why the lack of progress reports for a while. I've spent the last month or more rebuilding a lot of the interface of Verisimilitude: Prototype amongst other things, with a vast amount of long term improvements, fixes, and general bits of goodness as I've heavily refined the cores dealt with in the previous build. As of the late point of tonight, about to head to bed Verisimilitude: Prototype is now at the same level of functionality as the last version I put online. In the next week or so I plan on continuing the conversion to the new systems, which only really needs to be applied to the encounter system (Which will mostly duplicate what I've done with the menu system, but some extra layers for a simple artificial intelligence, animations, and action gauges, all things the menu doesn't have), with a small exception for inventory based special cases (Which require some additional work to behave well with the new arrangement of reuseable cores). My next post shall be to say the new build is up and fully functional again, something it hasn't been for a while.

I've put 2 builds of Verisimilitude: Prototype online. The 1st is version 0.20, so people'll better appreciate all fo the effort which went in to building up content and the systems making up the whole experience of the much publicly hated 0.21, and better get why the focus of 0.22 is bettering the experience versus the content (Bettering the content is what I have planned for 0.23-0.24's schedule, with minimal tweaks to the remainder of experience changes I want to make which are far less a priority than what's being pushed in to 0.22). The 2nd is the newest build of 0.22, which has a handful more special purpose cores, which while they may be fully done, the implementations of them in the main core are only half way, so the build previous of this one will stay available until next build which fully implements these new features is done, as at the moment Verisimilitude: Prototype isn't fully playable, which I'll get in to with this lot of news.

As I've mentioned in bits through the last few months, I've been focusing most of my Verisimilitude: Prototype time on writing better systems for handling user actions. The list of improvements made through this probably aren't exhaustive, as I'm writing this last thing before heading to bed at the ending of a late night, but here goes.

Added two cores, one for actions specifically and one for actions generally. To elaborate, the former holds all of the data of each action, including relationships with other actions, while the latter exists to handle the event of an action being used. A thorough check is done when ever an action is triggered to ensure the chain of it is all right, so some extra security. It's a very fluid system which allows many levels of actions within actions, with extensions in place for long term growth, plus external supports for improved functionality, which I'll get in to now. It is possible for an action to have more than one target, either all of one side, or both sides of an encounter, with data to be applied at varying levels too (You may have an action which does damage to all of your enemies, and displays the result for each of them, or instead does the same damage to all of them, throwing up a group value instead of one per individual). This also goes in reverse, with the potential of having actions which require multiple users to make it happen, all of them needing their action gauges full (Which is already utilised by an action I've bettered through this). As it's storing so much data to be thrown around, a fix will be in the next build to make combo restore display both it's health and mana effects when used (At the moment, it only does this for mana). Lastly for this core exclusive stuff, there's heaps of data in place which has the same level of granularity as the damaging and healing impacts afford by what I've already mentioned, but is used for status effects instead (Which is what flee is now treated as, it being the only action using this for the near future, but opening the door to so many possibilities).

Now on to the extra wrappers through the main core and changes I've made to some actions' logic while I was at this area of Verisimilitude: Prototype. Each character has a trust value for all others in play, which is used to determine how much they attempt to evade and defend against an action coming their way. It no longer matters if an action is considered good or bad. Healing actions like the restoration magic and restore items don't automatically hit everything like they used to (A problem with accidentally using them on enemies) and damaging moves like attack and the destruction magic don't get automatically avoided either (Meaning if you go to hit yourself, you'll be more likely to do so). The trust values change based on how much an action changes the target's health or mana for better or worse, which can be exploited. It might be easier to damage an enemy if you throw an exceptionally strong healing item at them first (Making them lower their guard, due to the trust value, as they expect more beneficial things to come from you) then hit them hard with something which may not normally penetrate their defences. At the moment these trust values default to never evade or defend against an action coming from your side to the opposite against actions coming from the other side. In the next build I'll have these values slowly generate back to their defaults, so if you hurt yourself, and can't heal yourself due to your character blocking anything coming from you (If it was another member of their team, not trusting their actions, or if it came from them, not trusting their own actions bizarrely), this won't have you permanently stuck.

The beginnings of a difficulty system have been implemented. There are values to adjust all of a character's statistics at the point of action, a simple multiplier so the original powers of the player never have to change, and thus there is the possibility difficulty can be reset by the user as they play and never break anything doing so. The flee action does randomisation per calculation of each user's agility instead of the group as a whole, for every combination of friend and enemy, to apply all of the different trust values in play, and as I said, it will require all users of a side (Exceptions made for any unconscious or dead) to have their action gauges full before they can do anything. The donation skill has changed the most, it now hits all targets on one side, with the interface changed to display this difference, with coins potentially lost on enemies already fallen. The amount of currency used for the donation skill rather than being a random amount of the total is now based on your agility, multiplied by your unequipped attack (Unequipped because it makes no sense for a sword your holding making you more proficient at throwing things), and the accuracy versus evasion calculation happening based on the value of each magnitude of currency thrown. Meaning for 278 currency thrown, the calculation is done 2+7+8 times, working out how much of what's thrown actually hits, since it's many objects hurled at your opponents. Enemies store their actions the same way you do, which will allow me to add structure for how they make actions in the next build, allowing eventual intelligence to take place with them. The result of every calculation when performing user actions is rounded instead of the fractional value always being lost (Effectively rounding down in all scenarios).

Something I must stress before continuing, is that these user action cores aren't fully implemented. I've only put them in place for the menu system so far, not the more important encounter system, which will be the harder job (Made easier as I can build on what I've figured out through the menu system) and is the focus of the next build which shouldn't take me too long. Due to the limited functionality until the user action cores are fully implemented, I've left the last build online, so people have the choice of either the fully playable version or this potentially unstable one to help me with testing. Remember, implementation has only been done for the menu system, so don't bother with battles. Due to encounters not working now, you won't be able to get currency or items, which will limit what actions you can use in the menu (But the logic is in place for all of those, you just never gain the resources to try them).

Lastly here's a bunch of other changes made for this build, all of varying significance. The timing core has been heavily reworked so not only does it tell me the performance of Verisimilitude: Prototype when running, it also allows me to set a goal speed, and will make the processor sleep a dynamic amount of time between frames to accomplish this, versus the old way of statistically sleeping for a 50th of a second which would exclusively work with the impossibility of the game taking no time to generate frames. A problem with the last build, with keyboard input timing, which would slow the walking speed after breaking out of interactions with the healing room interaction, has been fixed. There was also a gap in the ranges of currency it would calculate when asking it to heal you, so it could get stuck in rare cases. Regressed an old change, which would detect Verisimilitude: Prototype detecting the loss and gain of input focus, resetting keyboard input each time this happened, potentially causing sticking issues when Java misreported these events happening. A lot of better memory management in general, largely user, menu, inventory, and equipment focused, creating and destroying data as needed with no time or space ever wasted. When assigning memory, only as many slots are allocated as needed for user statistics (Through the user cores now), user actions (Same scenario as statistics, with their new cores), and equipment (For the 1st and 3rd, 4 slots were always made, when you may have as few as 1 character. For the 2nd, 9 slots were made, 4 for friends, 4 for enemies, and 1 as temporary storage when loading each enemy. So a significant improvement in memory management). Memory clearing never happened if game over was reached from the menu system, causing a leak if this scenario kept repeating, a rare flaw to witness. Currency storage has been changed from 32 to 64 bits, meaning a significantly larger range of the currency one can have, and will no longer display in the menu system if the player hasn't acquired any yet. Walking animations now load based on the first user core stored in the group, which will be extended in a future build, allowing you to swap between which core is actively used for this, thus if you have multiple characters, you can pick which one you want to walk through levels as. Fixed a long term bug. abilities page of menu was using the scrolling values from encounters, which weren't resetting, so if scrolling happened in an encounter, it would permanently displace text outputted in the menu for that group of sub actions (Was sub action exclusive, actions weren't affected), which only happened on a per user and per action group basis.

I've been through a lot of trouble implementing Verisimilitude: Prototype's new cores in to the main part of it, and as such have decided to split what was intended for one build in to two. The build in question won't be a completely functioning one, simply available for testing, so the last will remain online until the second next is ready, as that will complete my work on this part of Verisimilitude: Prototype.

I'm sorry for the delays, but keep in mind that I'm spending a lot of time future proofing Verisimilitude: Prototype by developing systems far more advanced than it'll need in the near future, making things far more expandable long term, and this is where a lot of my time is going. This means if I continue working on it beyond this version, it'll be far more rapid, especially in regard to adding new content and replacing what's there with stuff of better quality. A lot of what I've been doing here will carry over to other projects, hopefully making them more speedy endeavours.

I won't go too deep in to details about the progress I've made, simply a summary as I want to hurry back to making more while I'm on a roll, keeping in mind I've been delayed by sickness since the last piece of news. The new cores for user actions are finished as of yesterday, and I'm now in to implementing them and the wrappers which will surround their use in the main core. They allow for a diverse range of expandability in the future, and also encompass wildly changed user actions themselves. The statistics at play are now crippled by any reduction in health the character's involved may have, there are values in place to impact things in there which will later be changed by the eventual difficulty setting, and all characters have trust values which affects how much they attempt to evade or defend against any actions coming their way from a specific person. Healing actions can now be evaded and defended against, with the trust value determining this factor and the donation skill is now a multiple target action (There's far more to it than that, but again, I'll go in to detail later when this build is finished).

There has been much in the way of computer troubles delaying my productivity, many viruses hit me, which took several weeks to deal with fully, followed by nasty memory leaks from the newest version of some of my security, specifically AVG, which I've since made work arounds for since I doubt they'll fix this severe problem any time soon. As such, there isn't as much to report as I'd like, and the new build I was hoping would be up during this month will be pushed a handful of weeks forward.

It's not all bad news, I have managed to accomplish some important steps in the direction of my aims for Verisimilitude: Prototype's next build. All of the systems for user actions have been designed, with 3 core components required: A core to hold all of a user action's data, a core to handle the logic of what happens when using what's in the former core, and an implementation of surrounding layers in the main core for utilising all of this new stuff. I have finished developing the first of these a short while ago, with an insubstantial amount written for the second.

As a bit of a bonus, I've made a change which significantly impacts performance. Previously, it would have the processor sleep for a static amount of time between frames, 20 milliseconds, with the goal of 50 frames per second. This would require the computer to impossibly perform an action in zero time between these sleeping periods, which would never be the case, so Verisimilitude: Prototype would always run slower than intended, averaging 41-43 for me. An extreme case of older hardware requiring 20 milliseconds to step forth with a further 20 milliseconds of forced sleep time lead to Verisimilitude: Prototype running at half speed. Now it's smart enough to dynamically adjust the sleep time based on a parameter I've given it, so in the 20 milliseconds to make an action extreme case, it wouldn't sleep at all between frames, and thus would run at full speed, a significant improvement. This took a while to manage as I merged all of this logic in to an old core there for simply counting how many frames were happening, so now it's got an input for how fast I want it to run and an output of the speed it's actually going at. When Verisimilitude: Prototype development ends for this next full version, this whole system will be ported to the Enigma Infinartum - Computer Game Engine, thus I'm considering this bit as progress for both, and have changed the date and time of the latter to show the recent work.

As a final note, I'm well aware of when it is and want to wish all of you happy holidays and a happy new year. If all goes well for me, university will end half way through the year, consist entirely of easy classes, and thus allow a lot of time for me to focus on my work, thus expect a lot of new content through 2015, including a new version of the Leviathan Eternal - Site and the Leviathan Eternal - Forum to support them. Take care of yourselves out there.

The next build of Verisimilitude: Prototype is slowly edging forth. I won't try guessing at an estimate of when it'll be finished, as a lot of design work is involved, of which it's hard to know how long any particular fragment will take me until I've successfully build it all up.

While it's hard to say where I'm up to, as everything is in constant flux while I try to nail down facets of the new systems, I can at least go in to detail about what's planned and attempt explaining why it's taking so long. Simply put, I'm rewriting all of the code to do with user actions, which mostly occur during encounters but can be triggered in the menu system too. Of all of the remaining code that hasn't gone through a rewrite toward the next stable version, this is the biggest and most messy. I'm about half way through designing it but have barely written any code to support it, as chances are the remaining elements will require anything I write to be changed again in the near future. So it's best I wait until it's all settled down before I make much in the way of tangible progress. Everything planned now for this aspect of Verisimilitude: Prototype is part of a long term schedule of changes, which will impact both this and other games which are being thought about through the process of making this.

The rewrite of this core is for the most part a large clean up, one which will make the less special case actions and everything wrapped around them far more reuseable in both this and other contexts, for the sake of some future projects with similar systems required. I'll be taking the opportunity to tweak around some of the different actions for the better, specifically the donate skills and all items in the inventory, as I'm happy with how all of the others are handled.

Some new logic will be put in place which gives each character a trust value for each character including themselves, only applied during battles, which will multiply the evasion and defence of each character by a number between 0 and 1 based on how much they trust actions coming in from that specific character. Good actions will lower their guard, bad actions will raise it. All characters of one side will start every encounter with their guard fully lowered for their team members, with the reverse being true for the other side of a fight, and vice versa. What does all of this mean? Healing actions will no longer be taken by enemies at full strength if you accidentally happen to use one on them, while any damaging actions used against yourself initially won't be defended against or avoided at all. Down the track when status effects are in place, one which confuses the characters will make them use random actions on random targets, which means potentially attacking people on their team. Their friends become more cautious of anything coming from them, even if the confusion effect goes away. If attacking one's self, via this status or by accident of the player's, the character will be paranoid about their own actions and thus start putting their guard up, even if they go to heal themselves. Alternatively, if using actions on the enemies, either actions which would normally heal anybody (Via confusion, or the player's own stupid actions), or will heal specifically that enemy (Due to the ability to absorb that particular element perhaps), the enemy will let their guard down, either thinking you can't hurt them or are simply too stupid to be able to. This can be used to your advantage, as you can start an encounter by using positive actions on them, to make it easier to use a negative one later. Healing them despite already being at full health, so when swapping to a damaging move, it's more effective.

There will be a bunch of fixes amongst these changes, one already being done which deals with a problem introduced with the last build (When going all of the way through the conversation tree with the healing room, input timings are broken for some of the walking directions, until walking in to another room or opening the menu, both of which reset the timings), but I expect I'll be rather quiet until this build is ready to go up. It's a big job, one people will hopefully be patient about, and more appreciative of the effort put in to it while waiting. Fortunately, the issues to deal with in later builds are nowhere near the same magnitude of this one, so I shouldn't get tied up putting so much thought in to how those latter systems are designed.

I've placed the newest build of Verisimilitude: Prototype on the Leviathan Eternal - Site. Obviously there is a difference in dates between when it was done and now. The delay of it's release has been due to having a lot of documentation to untangle for it so I'd know where I am moving forward. This has pushed this version's completion from 74.057% to 79.652%, with 1,000s of lines of code changed or added to it. I'll now try to elaborate on the differences, but as it's been a long process of many months for this one, during phases of university hell, I may forget some minor details.

A menu core has been written, which while it's used in the menu system, is a different thing. It helps a lot with the generation of interfaces, making them behave in a uniform manner, automating a lot of the heavy mathematics under the bonnet. I plan on further developing this in a later full version of Verisimilitude: Prototype, so it takes a stronger hold on the input and output aspects of gridded menus, but for now it's simply a helper of sorts, with a lot being passed to and from it. This has lead to a handful of alterations for the better. Selection looping is now row and column direct, versus selection order, which was taking you from this row to the previous or next when going beyond the first or last slot of this row. The diagonal movement of your selection is now possible, previously if 2 keys were pressed, the 1st would lock up, so you'd be stuck with only horizontal or vertical shifts. A similar issue dealt with, when opposing keys were pressed, the latter would wholy lock up the former, so you wouldn't stay positionally neutral while both were pressed. This core has been implemented fully in the menu and explore systems, the menu system being the distinct phase of Verisimilitude: Prototype which is full of interactable interfaces, and will be implemented in the encounter system at a later date. The encounter system, to avoid breaking anything before I hit the full rewrite of it, is still using it's old code for menus, so doesn't benefit from these new behaviours witnessed everywhere else.

The menu system itself has gone through a thorough rewrite, the only exception being code which touches on the same user actions useable within encounters, which will be tackled in a later build. There are transitions from and to black between each full screen of content, like the explore system, with the dynamic loading of assets when ever shifting through these pages. Each time a new page is entered, all of it's inputs are set to their defaults, to avoid any out of boundary errors from going beyond the useable range for this page while on a different page. Unique inputs on each page have their own menu core instances, which fixes a crash on the inventory page, when going between using and moving items, the former having a range of 9 (1-4 are friend slots, 5-8 which shouldn't be touchable but are in this glitch are enemies, and 9 is where enemies temporarily load when battles occur), the latter a range of 20. Changed how the enter key behaves in some scenarios, it would take you back a step when equipping an item or moving one, now it leaves it up to manual control. In turn, it will step back if using an item through the abilities or inventory page, when all instances of it have been exhausted. Lastly, for the equipment page, if swapping current equipment for the last item in a slot, and there are no empty slots before the one selected, what was equipped would go in to the next empty slot, when it should be entered in to the currently selected slot which was recently emptied, this has been fixed.

2 extra crash scenarios have been dealt with, both for during battles. The 1st would use the wrong slot to check against when attempting to reach the targetting stage with an item, specifically one of the inputs for the abilities sub menu instead of the inventory one, not even the main value but one of the variables used for handling scrolling (Something the new menu core automates smoothly, which will clean this up later when implementing it in the encounter system). The 2nd was something that's crept in during development of the version of Verisimilitude:Prototype this is all leading up to, so is a new one, a memory error when trying to flee while an actual was already happening, fortunately handled.

I won't hazard a guess when my next build will be, as I have probably too much ambition for what I want to achieve with it, but I'll keep everybody up to date here with events as they happen. Hopefully the gap between releases won't be so big this time, as I have a while before my next university semester. Ideally the full version will be done before then, so I can move on to other equally important projects, like the new Leviathan Eternal - Site and Leviathan Eternal - Forum.

Progress has been going relatively well for Enigma Infinartum - Verisimilitude: PROTOTYPE, with things a bit slower more recently. I've finished implementing the menu core in to the menu system, I've talked previously about the differences between these two things. Many long standing issues have been dealt with, all but one were present in the last version of Enigma Infinartum - Verisimilitude: PROTOTYPE, with the exception being a rather nasty crash during encounters which would often happen when trying to flee.

I found a severe flaw with how the menu core was handling selection looping, where changing input to go beyond the visible rows and columns which should jump you to the opposite side. This wasn't working well when the slots one could touch didn't add up to enough for a square grid, a lot of odd looping behaviour which would've made no sense to the player if they witnessed it. This involves a lot of heavy mathematics and had me stuck for a long while, hence the delays in reporting progress and actually placing a new build online for you all to try. Today I've managed to break through with this, so are in the process of rewriting my solution to the same standard of my other code, and catching three other potential cases with rearrangements of what I've done.

With the recent break through, I expect a new build will be put up within a week at most, so keep an eye out. It will be a far more stable and polished experience than what's online now. Most of the polish has gone in to the menu system, but all of the breaks I've handled are on the encounter game state's side, which was the biggest deal breaker for most people.

University has ended for the year, so I'm fully back to my work. You'll be hearing a lot more from me for the next few months at the very least. My primary focus through this time will be finishing Enigma Infinartum - Verisimilitude: PROTOTYPE's next version, followed shortly after by the Leviathan Eternal - Site and the Leviathan Eternal - Forum, which I have many ideas for, to make them way better than they've ever been.

I'm fortunate enough to have my first regular donator on Patreon, something which in itself is very motivating. Thanks for your support, it's very appreciated. For the first future release of Enigma Infinartum - Verisimilitude: PROTOTYPE, the Leviathan Eternal - Site, and the Leviathan Eternal - Forum, I'll keep placing partly finished builds on here for the sake of testing stability. After these versions, all future builds between releases will be exclusively private to those on Patreon who are supporting my work by then, a privelage for helping me on my way through these projects.

I have bad and good news. As I've said earlier, I knew this would be the heaviest semester I have to face. It's effect on my work is simply having no time for it. So the bad news is no progress for any of my projects, including Enigma Infinartum - Verisimilitude: PROTOTYPE. The good news is I'm half way through the semester now, so while I can't focus on my work here for the better part of 2 more months, I'll be able to focus fully on everything shortly after then. This news is to simply let you know everything is okay on my side of life, simply quiet for a while.

A lot has been done to implement Enigma Infinartum - Verisimilitude: PROTOTYPE's new menu core, with the results so far being quite promising. The core is doing it's job without any issues and has allowed me to heavily clean a lot of code that was doing the same job the old fashioned way. I've rewritten most of the menu system (The menu system is a distinct game state of Enigma Infinartum - Verisimilitude: PROTOTYPE, while the menu core is simply there to help with interfaces, and will thus be used in other places later), nearly all of it's inputs, a good amount of it's outputs, fixed some long standing flaws, and added full screen transitions.

University is getting in the way as usual, so my progress will likely steadily ebb, but I intend to have a new build online within a week with any luck. This new build will implement the menu core fully through the menu system, and in the one case it's needed for the explore system. I'll leave it until later for the encounter system, as that's a mess, and a lot of other work needs to be done there, so it'd be more efficient to work on multiple things concurrently at that point.

Work for Enigma Infinartum - Verisimilitude: PROTOTYPE's menu core is finished. It's now time to start implementing this new core through all of Enigma Infinartum - Verisimilitude: PROTOTYPE's interfaces. At the point all of this is done, I'll be placing a new build on here.

While a lot of this progress may not be particularly exciting, it's important as it's focused on rectifying many mistakes made during Enigma Infinartum - Verisimilitude: PROTOTYPE's early development, constructing unified systems to handle common needs (Many of which will be ported to other projects later, so the effort placed in to prototyping these cores here will have wide spread potential for increased productivity. It'll make programming these projects a lot faster in the long term, as I'd only have to focus on the game specific requirements at that point, rather than all of these features that are shared between them). I realise it's taking a long while, but that's the cost of making these systems thoroughly future proofed for my many projects' long term needs and ensuring their stability in the face of errors.

University continues for me very soon. It should be the last major instance of it, but like all previous years I've been doing this for, will slow down my progress on Enigma Infinartum - Verisimilitude: PROTOTYPE and any other active projects I may try to push between school time. I'll be trying for a handful of builds over the course of the next few months, but won't make any promises, as I expect this semester to be a rather heavy one.

Fixed an experience problem, not enough memory was being used, so at higher levels the amount of experience needed to go up a level would enter the negatives. Fixed an item core problem, memory wasn't being destroyed when not needed any more. Lastly, started writing a menu core (Different to the menu system. The menu system is a unique part of Enigma Infinartum - Verisimilitude: PROTOTYPE, the menu core is simply a unified way to create interfaces, including the menu system's). This new core is mostly done, it simply needs some additional logic for the special input cases, and for Enigma Infinartum - Verisimilitude: PROTOTYPE's interfaces to be moved to the new core.

This new menu core is the focus of the next testing build, with a handful of unrelated changes to the menu system coming with it (Full screen fading like all other parts of Enigma Infinartum - Verisimilitude: PROTOTYPE have now. It has come to my attention that there is a handful of very nasty breakages, some of which make Enigma Infinartum - Verisimilitude: PROTOTYPE impossible to play as they cause everything to die. I won't be able to fix these for a while with my schedule, rewriting the encounter system not happening for a handful of months, so try to be patient while waiting for me to reach that point of the rewrite.

We've had donations for a long while now, a new way to help us has been added, Patreon. We've recently created a Patreon account at http://www.patreon.com/user?u=207709, which allows you to regularly pay when ever we have new content to release.

The page is very bare at the moment, but a lot more will be added to it when I have the time. On it we will talk through the progress of each project it as happens, the plans for every release we'll be making that triggers a transfer from you, and give you enough warning to change the amount you've pledged, based on what project the newly released content will be for (So you can focus your spending on the projects most important to you). The incomplete builds of our projects we're currently releasing publicly for testing will be moved to donaters only, with either a delay before going public of up to a month, or not at all (Depending on what the mass of the donators vote for). There won't be any latency at all for the fully featured version of each project to be released when it comes. Anything you're generous to give will help a lot as we build things up here to push out the best content we can.

My plans are for the new Leviathan Eternal - Site and Leviathan Eternal - Forum to both be finished and placed online within a year. As that's a long way from now, and Enigma Infinartum - Verisimilitude: PROTOTYPE needs the latter so I know what troubles people are having with it and can deal with them quickly, I've installed phpBB as a temporary measure. I'm aware there is a handful of people who spend some of their free time testing it but can't get a hold of me on anything else for what ever reason (I know of some people who generally can't talk to me at all as messages aren't making it both ways, I've stopped trying to figure out why it is, as I've tried so many things that haven't worked and have no clue what's causing the issue), so to those people, I recommend you migrate to the Leviathan Eternal - Forum (The temporary phpBB one), and talk to me through that, as I do want to hear all of your opinions, but nothing else has been working so far to allow that.

The latest build of Enigma Infinartum - Verisimilitude: PROTOTYPE has been placed on this site, pushing it from 63.212% to 74.057% finished. Most of the effort has been placed on writing new systems for the user and enemy characters, items, and the inventory and equipment systems which use the item core. Any issues found specifically with these aspects of Enigma Infinartum - Verisimilitude: PROTOTYPE are of the most importance to me as I'm not aware of any of them yet (There were a lot I spent a heavy amount of time dealing with through the last few days I worked on the code of Enigma Infinartum - Verisimilitude: PROTOTYPE). The menu and user action systems (The latter of which is mostly used in the menu and encounters) will be my focus for the next 2 builds in the order given. After, I'll move my efforts to everything concerning the encounter system itself and the victory board page that follows it. Thanks everybody for your patience and support this far in to what's turned out to be a very time consuming endeavour.

Read through for the last of the changes made to the newest version of Enigma Infinartum - Verisimilitude: PROTOTYPE, of which I'll be releasing at a later point today:

Dealt with a small graphical annoyance of mine for the 1st frame of the northward walking animation for FEnrir Wolfbane, a single arxel of it that was out of colour with the whole set. Changed the currency wanted by the room which can heal your characters to round it's value instead of letting it fall to the previous full unit.

When experience is shown inside the menu, it's changed from a relative value to the next level up and an absolute value of what you have, to an absolute value of the previous level down, next level up, and what you have. The graphical bar stays the same, just showing the relative point between levels that you're at. Have negative health to make reviving harder, go as low as negative maximum health. Changed health and mana to show both present and maximum values within encounters. The low health status has been changed from a quarter of maximum to a half. Changed the statistic output to round down/up rather than drop the decimal down, for both the menu and encounter states.

Menu indices reset to their defaults when exiting any full screens worth of content, to avoid being out bounds when entering a different part of the menu. The menu's status screen has been altered to no longer list useable actions or let you select a target with them (Was basically a redundant case of what's on the abilities page, except here none of it was functional, it was all for show and nothing else).

Created an item core, with it's type, name, reading (Normally used for information), value count, value/values, and the ability to load all of it's data. Created cleaner inventory and equipment systems that use the new item core, holding data for the state, count, and item itself in the case of inventory, the state and item itself for equipment, and the ability to dynamically handle it's memory useage. All equipment should be applied to base statistics, meaning shield * shouldn't be applied after armour * and vice versa. When comparing equipment, the % modifer has been changed to the * modifier. This effectively does the same job but is shown a bit differently, a % of 100 is now a * of 1 for example. The equipped before/after part of the equipment page of the menu state treats empty inventory slots as equipment without modifiers beyond neutral (+ of 0 and * of 1), allowing a comparison to/from changing between having something equipped and not at all. This whole new equipment list of changes has fixed something important in the process, that the * modifier was showing 0 for no equipment, when it should've been 1. If I had something equipped, went to change it for the last item in the inventory, of which there was 1 instance, my current equipment would've gone in to the slot after the slot emptied by this action. This isn't an issue any more. There were 2 square areas on the equipment part of the menu that had nothing shown within them. They now show the selected item inside the equipment (1st box), and the chosen item within the inventory (2nd box), when you're at the appropriate depth of interaction. During the inventory part of the menu, if using the move action, and if choosing the 2nd item to swap between selections, it would only be showing information for the 1st item, never the 2nd. It now shows information for the item being actively targetted. The interface has changed for inventory, allowing information for 2 items to be shown, which only ever happens during the move command.

When in the middle of an encounter, the pause when an action happens, which would normally affect everything, doesn't block most of the user's input now, with the exception of setting the last step in motion for an action to happen. Meaning you're able to navigate through the interfaces and do anything else you want to while you wait for enemies to finish attacking you. Managed an crash instance which happened when ever the donate skill defeated the final enemy of a battle. This was caused by not storing the skill user's identity and that of their target for animation purposes when ever any skill was used, of which donate is the only skill currently available. Fixed a donation skill issue, was checking against magic defence for normal hits and defence for critical hits. As critical hits have been deleted from the code, it was using magic defence through the calculations for finding the damage done. Now it uses defence instead, as it should've done from the beginning. Fixed flee action, was storing the conclusion as a fixed point rather than a floating point number, meaning a fractionally positive result would lead to a failure when that shouldn't be the case. Only take in to account live participants in an encounter when doing the flee action, specifically when counting up their agility before dividing by how many participants are on their side of the battle. This means that some deaths on your side make it harder to flee, and some deaths on the enemy's/enemies' side make it easier to flee.

Added a core for user characters, with many changes from the old system. With data for the levelling type (Finite and infinite) and level maximum (For the finite case of levelling type), experience needed to go down a level (Yes, levelling down is now doable, but won't be utilised for the next stable version), growth data to know the different amounts of experience needed for each level change, which can be linear or exponential and can have a base value to start with. There is logic in place to automatically rearrange a character's current level and experience based on changing any of these level and experience factors.

I may've mentioned earlier that I've subtracted the ability to fully restore health and mana when levelling up, and instead have the current values grow by their ratio relative to the maximums, to be more realistic with how it's handled. In their place though, health and mana actively regenerate during the explore and encounter states, with the ability to grow up to their full values within an hour. In the case of health, which can hit negative values, it will degenerate to a greater negative value, meaning your unconscious body is simply bleeding to death steadily. A health or mana of 0 though don't regenerate in either direction, as they're the neutral points.

When levelling with the new system, I'm able to set if I want statistics to shrink or grow in a linear (How enemies are altered) or exponential (How friends are altered) fashion. Also I have the choice of if they should shrink or grow by static (How enemies were changed) or dynamic (How friends are changed), with the dynamic case how statistics are altered by multiplying them with a random value between 0 and 2. Enemies as said were using the static way of change up to this point, but I've changed them to be dynamic like the user's characters, to make things fairer between sides. They continue on their linear path though, as changing that factor would need a lot of rebalancing, which isn't a priority for this release.

I previously talked about the changes as to how equipment is applied to a character's statistics. Well to enable this, there are values holding the combined effect of all equipment on a particular statistic, to be subtracted or added in a single hit when something changes, like the player changing what's equipped.

The following is the last of the progress I promised to report months back but never got around to, all of the stuff that stacked up over a long period of working on Enigma Infinartum - Verisimilitude: PROTOTYPE:

Added a uniform system for finding the keyboard input's state, with data for the pressed/released state of each key, if there should be a key specific delay between recognising the press state between consecutive game updates, the length of a key's delay if it has one, both the turn over point and where it's currently at, if there should be a limit to how many times a key's pressed state is recognised in a row without releasing it, and how many times a key's press has been registered in a row and the limit it needs to reach before any more updates of it pressed is ignored.

Added the ability to delay handling keyboard input events within the input handler. This is used to prevent keyboard and mouse input events being handled too fast for the user to react. Removed the input delay when the input has stopped being active. This allows the user to get a faster response by pressing/releasing multiple times than pressing and stopping. Detected when window is updated and reset the stored data for every type of keyboard and mouse input event. With the better system for handling keyboard input, any keys that previously had delays now have their own exclusive timer for it, so their delays don't affect other keys. There were cases that input needed to be delayed within the explore state, like the menu and encounter states, but wasn't, this has been fixed. All input delays for anything that isn't a toggleable setting have been changed from 0.2 seconds to 0.1 seconds. Input delays of 1 second have been added to everything that is a toggleable setting, specifically map, music, and pause. By applying the new keyboard input system to all keyboard input, there is no hardware/operating system forced delay between the 1st detection of input to the 2nd forward detection of input, meaning all delays are manually set by me and my timing code. Delays for input are maintained between screens, to stop players from accidentally skipping them. The smooth transitions between anything that occupies the full screen helps with this too. Specifically dealt with the accidental skipping of the victory board state and of the intro state from the game over state if dead. Some aspects of the encounter system had input delay and some didn't. The way it was coded, it would allow actions to be triggered when the enter key was pressed regardless of if it's delay was active. Meaning if you weren't fast enough to release the enter key, you'd go through both the target selecting phase and action triggering phase too fast for the player to react. This was only an issue with the enter key, no other inputs were effected.

I've finished everything I wanted done for the next prerelease of Enigma Infinartum - Verisimilitude: PROTOTYPE for testing purposes. It's been a long day of hard work, but well worth it. I haven't placed what I've done online yet though, I'll most likely be doing it soon, after I've written all of the progress I've made and reported it here. So keep checking back and very soon there'll be something new here to sink your teeth in to.

I know it's been a very long time since I last reported progress on here, but that's because it's been going slowly, with the most excessive semester of university yet that's taken most of my time, plus nothing I felt was worth talking about as there was a lot I was in the middle of but none of it reaching a finished state during the last few months.

With all of this said, it doesn't mean progress hasn't been happening. There is actually quite a lot of it, with a new build due soon for the sake of testing. I've been mostly focused on rewriting large parts of Enigma Infinartum - Verisimilitude: PROTOTYPE, specifically the code that holds the data of playable characters, the code that holds the data for items, and the inventory and equipment systems that use the item code. I have more university work that's a priority, but I'm at the tail of it, so hopefully soon I'll have this new build up.

There's a handful of breaks I'm aware of that I want to deal with first, plus a lot of catching up I need to do on it's documentation (The current values for how complete the next full release is is many months out of date). As so much work has gone in to this and only recently has enough of these rewrites been done that Enigma Infinartum - Verisimilitude: PROTOTYPE is playable once again, I'd very much appreciate any feedback people can give me as soon as it's up, so I can deal with any new problems I haven't found myself.

I've had somebody doing a lot of work for the Leviathan Eternal - Site within the past few months. They've recently sent me everything as they have to focus on university now. There's a lot there, I don't know what of it works, at the very least it is a good head start for when I have the time to work on it.

University is taking up most of my time now, so my progress will be slow for a while for things like Enigma Infinartum - Verisimilitude: PROTOTYPE. If all goes well, this will be my last year of heavy university work, so while I won't bet on how much of my work will be finished this year, things will definitely be a lot faster next year forward.

The list I'm about to go in to contains a bit over half of what remains to report from the last few months of Enigma Infinartum - Verisimilitude: PROTOTYPE's progress. Hopefully I won't find myself in this circumstance again, talking about the successes of my work ages after they happened.

Fixed flee action, was storing the conclusion as a fixed point rather than a floating point number, meaning a fractionally positive result would lead to a failure when that shouldn't be the case. Only take in to account live participants in an encounter when doing the flee action, specifically when counting up their agility before dividing by how many participants are on their side of the battle. This means that some deaths on your side make it harder to flee, and some deaths on the enemy's/enemies' side make it easier to flee.

Took out the system that would ensure diminishing effects from higher agility values on the action gauge, which is especially important for the player's characters who's statistics go up exponentially, as this meant they hardly moved faster at the highest levels than the lowest levels. Balanced the rate action gauges fill so the fastest character within an encounter will need 1 second to be ready for an action, all other characters filling up at a slower rate, relative to the their agility versus the fastest character's agility.

Changed user's character's translation from fixed point to floating point values, which doesn't mean much now but will allow for smarter movement later, with walking better adjusted for diagonal directions and the 3 dimensional angle of levels. Was getting stuck in the middle of walk cycles when hitting walls, made sure this no longer happens. Wasn't setting the animation frame to it's default position when walking stopped, so while the player would change to a standing state, if they started walking again they would begin in the middle of their walk cycle, rather than at the beginning as they should. Now keeps animating the player's character to walk regardless of what collisions may happen. If walking in 2 directions at once, so diagonal. If a collision wall gets in the way, once you've walked so far that you're no longer colliding, you won't be going diagonal, you'll just be going horizontal/vertical (Whichever the collision with the wall didn't disable). Dealt with a rare issue that would cause the direction the player is facing while walking diagonally to flip between horizontal and vertical directions.

May show wrong Fenrir Wolfbane sprite briefly before a battle, the standing sprite for the battle, stopped this from being a problem. Dealt with a weird flash between sprites and translations for them when entering an encounter they appear in, seen at explore state. Shows standing frame of explore state when an encounter ends, most obvious if the player was facing a different way before the battle than they are in the battle, or are at a low health or death state when a battle ends, fixed so it never happens now.

Changed the setting for audio output to unmute/mute the relevant audio channels instead of playing/stopping them. Stopped the explore theme from playing within the menu or victory board states. Added the ability to detect when the software is being closed, to manually stop the audio channels and clear them from existence. This fixes a long standing issue caused by Java which involved music continuing to play long after the program has been closed, as Java would keep invisibly running when it shouldn't, as it couldn't automatically handle closing audio itself.

The following is all work I've been doing recently for Enigma Infinartum - Verisimilitude: PROTOTYPE, I should note before you continue reading, that while I've completed this very thorough core, and placed a lot of effort in to making it cater to all of my current and potentially future needs, it hasn't yet been implemented, all of the older equivalent systems still being in use instead. Implementing this core will be the next thing I do, at which point all of the game changing aspects I mention here will go in to effect.

Added a new core for characters that is used mostly within the menu and encounters. It holds the name and all of the usual statistics known to players, all of the values needed to handle linear (For enemies) and exponential (For the player's characters), it also holds a type to identify by and all of the data needed to load any of the characters present.

It has a built in way to limit the maximum level a character can be, and whether or not that limit is to be applied (Allowing for unlimited levels within what computers are capable of counting up to if I decide for it), as well as the character's experience needed to go to the previous and next level, and their current experience (Yes, previous level does mean at some point in the future there will be scenarios where you may be forced to level down), and experience growth values that allow it so different characters may require different amounts of experience to change levels (Meaning a character may reach higher levels sooner, but at the cost of less growth per level and hitting their maximum limit sooner).

Values are in place to store compounded buffs for attack and defence, the main use for them at the moment being for the effect of equipment. Currently in the case of shield and armour equipment types, they are applied one after the other to defence, which makes little realistic sense. These new values will allow all of their effects to be thrown together and applied at once which is fairer.

Logic has been added to generate health and mana as time goes by, completely filling within an hour. If health is at a negative value, it will generate backward until the negative maximum. Yes soon I'll be allowing both positive and negative health, which can be taken as conscious and unconscious, so while in negative, the fact you're generating to a greater negative can be interpretted as bleeding to death. If at 0 health though, you won't generate health either way as you're at a perfect balance between states of consciousness.

Up until now, the player's characters would have a randomisation added to the growth of their statistics but enemies wouldn't, I'll be changing this later so both are randomised. This new core has such a thing as a setting.

I've placed the newest build online for testing purposes, keep in mind that while all of the code is present for this new system, none of it is utilised, so the only change that will be noticeable to you is that the revivification spell has been taken out, with restoration pulling a double duty to heal characters whether they have a negative, neutral, or positibe health.

I believe I've dealt with enough of my documentation that I can continue development at the same time, so some of what I'll be talking about will be stuff I've done near enough to present, edging further in that direction until it's all reasonably new. I also think it's about time I have something to show for my efforts, so at the right where I normally list the dates/times of the last stable release and my most recent work per project, the section for Enigma Infinartum - Verisimilitude: PROTOTYPE includes links to both the old stable version that hasn't seen the light of day for a handful of years, and the newest build (With a date/time and % of completion, to make it clear what build is available, as it won't always be the newest, just what I deem stable enough with the changes I've done finished enough.). Initially this page for the new build was going to be just for people I have that are testing it for issues before making it public, but reception from them has been good so I figured I'd open it up for everybody to provide feedback for.

Lastly for today, I realise the progress notes I've been releasing recently are a bit of a mess, but I hope everybody can look beyond that and focus on how much has been done, as that's certainly what I'm doing at the moment. Without further ado, here's a heap of what I've sorted today within my do list: Took out the revivification spell which was something I was toying with, there so you can bring allies back from the dead, instead the restoration spell will be pulling double duty for that, all made possible by allowing fallen allies to be targetted in the first place. Fixed accuracy/evasion problem. was storing the result as fixed point when it should've been floating point. was missing enemies that should be unmissable because the result was less than 1 and thus losing it's fractional value to become 0. It's now a lot harder to accidentally skip the victory board and go straight to the explore game state, the same goes for skipping game over to reach the title screen, partly due to better handling of input delays, and the smooth transitions that now happen between distinct sections of the game. Got rid of the experience bonus, which was given to characters whenever they defeated an enemy, meaning the stronger characters became stronger faster while the weaker stayed wake. Improved character statistics by making them floating point numbers rather than fixed point, they're shown as fixed point to the user though, the most important effect this has is that fractional growth at levelling up accumulates, so characters become stronger at a faster pace. Dead characters are no longer able to make actions within the menu. The attack action is now useable within the menu. Fixed an issue that would allow the menu to be triggered when at the victory board. If killing yourself via menu, music wouldn't correctly change when you hit game over screen. If the battle theme is muted, and then unmuted when another song is set to play, two songs will be playing, the old and the new, and both loop, and then only the new can be muted, not the old, the only way to get out of this was to reach the point where the unmutable audio would normally play and mute it there. If death happens during boss, boss theme won't carry over to game over screen, but will carry over to title screen and play instead of title theme (Different to the problem where 2 themes play at the same time.), muting will flip between 3 states, boss playing, nothing playing, title playing, and back to nothing playing, boss theme will also carry over to other game states, but disappears for the theme that should be playing if muting is done enough. Movement is now locked when an interaction is taking place, avoiding the awkwardness that was walking to change input selection. Added a way to manually end interactions via the escape key, all can be exited except the second talk with the Leviathan. Previously it was possible to walk away from the Leviathan during the second talk with it which happens after the encounter, this is no longer a problem as you can't manually exit the dialogue now. Stopped displaying the amount of equipable items within the menu when their amount is equal to 0. Adjusted warp collisions so the space you have to be within is centred on the visible door.

Here's another bunch of things I've managed to accomplish these last few months: Changed the loading of Java code external to mine to load exclusively what is needed, significantly shortening the load times. Added cores for static and dynamic transformations, which have values for translation, rotation, and deformation, and translation velocity for the dynamic transformation's case, all of this used to make handling visual things a lot easier. Changed the ability to begin encounters from the explore state to do this when the user is walking and a collision is happening, previously encounters wouldn't be able to begin if the user was walking and colliding on the depth axis. Changed player walking so the player won't visibly walk if both keys on the keyboard are pressed within the same axis. Changed player walking so the player faces the direction they are trying to walk all of the time, including if they are hitting something collideable. Changed player walking so the player won't change the direction it faces back and forth if walking both directions within the same axis (Walking nowhere.) or diagonally. Changed the ability to find collisions to be tighter so the player can't walk outside of a level. Stopped skipping of the first frame of walking animations, would happen for each cycle after the first of a continuous walk, meaning if you release all walking keys and then start walking once more, the series of cycles will reset and thus the first cycle will be frame complete unlike the second forward. Warp collision has looser requirements, so only at least half of the player's length has to be within a door's space, versus completely within the door's space. Collision detection rounds coordinates, making things a bit more balanced. When a walking key is released, the player smoothly animates to a standing state versus instantly changing to it. Took out the critical hit statistic which was applied to attack, magic - destruction/restoration, and skill - donate, wasn't needed with all of the randomness already in place for actions. The level you're currently exploring is now shown as ?.? instead of ?-? within the menu. Health is now shown as present/maximum instead of maximum/present within the menu and encounters, with the same going for mana. Mana is now shown as present/maximum instead of maximum/present within the menu and encounters. The duration of your whole time playing, no matter how many instances of restarting, is now shown as hour.minute.second instead of hour:minute:second. A lot of these text rearrangements are of personal taste with the exception of the health and mana present/maximum ordering which was pointed out to me as being a bit bizarre. Tweaked warping to ensure the player character is centered correctly at the entrance of a new explorable area upon entering. Tweaked map graphics to be more accurate in regards to collision and warping, also easier for the player to view. Added an image for a new map for level 1.3, which is triggered to be visible after the boss encounter for that place is defeated, this has the slightly different geometry of the level there to see. This new map is correctly loaded when entering the level and the one for before the boss encounter is cleared from memory when not needed. Having the map visible no longer affects the colour of text within the menu system. When maps are toggled on, they appear any of the interaction based interface, rather than over. As the maps were recently improved to be more accurate to the collision, their coordinates when entering levels have been adjusted to match their changed shape.

In no particular order, simply writing each item as I attempt to organise them between my many text files of short hand notes: All of the remaining code that was in different cores to the main one, or disparate chunks of the main one, have all been cleaned up enough to merge, making my job of furthering them much easier, now I don't have to jump all over the place to trace faults and change features. Tightened transitions between game states from 1 second to 0.1 seconds, it felt too sluggish on top of loading assets during the black screen it fades to/from. Transitions can now happen between levels of the explore state, which is set to clear memory and dynamically load things as needed. For the title, explore, and game over states (That's 3 of 6 of them, the remaining being menu, encounter, and victory board.), during transitions, when the screen has reached black, all visual and aural assets that are needed are dynamically loaded, and clear memory of any from a previous state (Only if the previous state was 1 of these 3.). Input timers have been fixed, they were delaying input reactions when the timer maximums were set to 0 (Which meant they were supposed to not have any form of delays at all.). The level limit for the user's characters have been increased from 99 to 999. Subtracted a difficulty setting that was supposed to make things easier for people, I have a lot of difficulty balancing I'd be doing within a later release than this one, which would be a better time to place an option that alters difficulty in to the fray (It would've been too much trouble to balance this now, only to have to balance it again later, so this feature is temporarily dropped.).

I mentioned earlier that I'd be going quiet as I focused my attention on Enigma Infinartum - Verisimilitude: PROTOTYPE's progress, that I'd be working purely with short hand notes rather than my usual extensive documentation, to try and speed up the process as I wouldn't have to maintain anything elaborate. After several months of hard work I'm ready to start updating my do list to be sure of what remains, and will place news on here about the things I've done, in no particular order as I compile the details from a handful of disparate files. As a hint of how much I've done generally, the better half of the code has been completely rewritten for the better, and short for few issues I may've missed, are deemed in a perfect enough state for the eventual release of the next stable version. I'll be breaking from my usual efforts solely to update everybody here with what's been done, while assessing what else I have to do before I have something tangible to show. As soon as I've cleaned up my documentation for this, I assure you I'll change the % of completion at the project section of this site to better reflect the current state of things.

I was able to fix my computer a long while back and have been quiet about it as I've focused on university. My last examination was recently so I now have more time to focus on what matters, my work.

1 of the 2 programmers is back, Junaos, who has found better work on the side that will give him more resources to focus on our work. Shortly after he finishes moving, he'll be working on the Enigma Infinartum - Computer Game Engine, pushing that forward.

Luke Usher/Soulless Sentinel has decided to do their best to destroy my work and won't be tolerated, I've never had the bad fortune of knowing somebody this bad before.

A friend of a friend, Greg, is helping me with the Leviathan Eternal - Site and the Leviathan Eternal - Forum. Good things will surely come from him. He has done more within 1 week than Luke Usher/Soulless Sentinel had done within 3 years, and I'm very grateful for it.

Enigma Infinartum - Verisimilitude: PROTOTYPE is steadily moving forward, I've made a lot of progress within the long quiet. I'll take the time later to talk about what has been done, currently everything is dirtyly written as short hand. Simply know that the date/time and percentage shown on the Leviathan Eternal - Site are wrong

The 2 people who are the few people I know that could help with my computer problems and explicitly promised to have both disappeared, Junaos and Luke Usher/Soulless Sentinel, it's been over a month since I've heard from either of them.

None of the people I know who know Junaos have heard from him either so chances are that something bad has happened there. I'm considering him temporarily off the team since whatever is keeping him means he is unable to help at the moment. As this site is on his server and none of this has disappeared, I'm betting nothing has changed as to what side he is on. Here's hoping for a speedy return.

Luke Usher/Soulless Sentinel on the other hand is a completely different story. He has gone out of his way to block every line of communication I ever had with him, so he can have his "time of the year" when he becomes unreliably moody for a handful of months. If he ever turns up again, experience shows that he'll have absolutely no idea why he ended communication with me, most likely doing it on a random whim, as that's how he operates. It's sad that I ever have to rely on him, sadder still that he was the only person on the team able to work on the new site and forum. When he blocked all routes I could've talked to him through, he went ahead and blocked me from his server which is where the newest (3 months out of date now, as he works so slowly) code for my site was. He's proven to be so slow that it would take him so long to make any progress, each time he went to make progress he'd have to relearn everything he'd already done, suddenly find so many flaws with it, and start mostly from scratch. Because of this, I do have many copies of the site (The newest being 6 months out of date), but they're all aborted attempts at certain features, a useless mess.

I hold nothing against Junaos as his circumstances the last time we talked hinted that something serious may happen in the near future from then (And most likely has, considering nobody has heard from him since, of his closest online friends). Luke Usher/Soulless Sentinel knew that Junaos's circumstances meant he wouldn't be able to help me for a long while (Not knowing Junaos by name though, as I referred to Junaos as "the other coder on the team" to Luke Usher/Soulless Sentinel and vice versa), so Luke Usher/Soulless Sentinel promised to bear the weight instead since he had no school or job or any other commitments and gave the impression he wished to make up for his numerous previous cases of unreliability (I didn't say "so he can have his "time of the year" when he becomes unreliably moody for a handful of months" lightly, I've actually been waiting for 4 years so far for him to do the site and forum work, and within that time he has made a habit of regularly disappearing for weeks to months at a time, normally beginning such sessions by blocking every channel I have to talk to him through. Believe me, I've tried many times to find others to help instead, but they've never stuck around long enough to do anything, so I've had to keep suffering Luke Usher/Soulless Sentinel's failings instead).

Simply put, I hold Luke Usher/Soulless Sentinel's determinedness to screw every aspect of my work over as responsible for my current situation. I no longer have access to the newest site code because of him (Which was the only version that had anything usable on any level), so those 4 years of dealing with him were for nothing and I now have to start everything from scratch. The kicker is that also because of him, I still don't have access to a computer I can do any work with, so nothing to use while spending months to work out how to do the site and forum coding needed, and all other projects are permanently on hold as once again I don't have a working computer to do them with.

Don't expect progress any time soon, I'm not lucky enough for circumstances to change.

This isn't about any new progress but instead covers what I alluded to earlier but was unable to report on due to my computer woes.

Changed input delay from 0.2 seconds to 0.1 seconds, for all input that ever had a delay. Subtracted ability to completely fill physical health and magical energy when user characters go up a level. Added ability to change present physical health and magical energy, determined by the change to maximum physical health and magical energy when user characters go up a level. Changed explore theme to not play within the menu or victory board. Lastly a bit of cleaning and minor fixes not worth mentioning.

While my computer isn't working, I'm able to access it's data, having moved enough of it to a secondary computer dedicated to occasions like this, magnitudes slower but at least it allows me to keep going. I should be making more progress fairly soon, but at a slower pace as fixing my primary computer is a higher priority, as that allows me to in turn work faster on important projects like this.

For sometime over a month I've been working hard to fix my computer which has been becoming worse and worse. To this day I'm unsure how much of the problem is hardware based and how much is software. Today it hit the point of no return, infinite blue screens of death. This is very bad timing as I was getting in to the swing of things with Enigma Infinartum - Verisimilitude: PROTOTYPE if the relatively regular news updates were anything to go by, which will now have to stop. I managed to do a fair bit more recently that I haven't been able to report, all of my work can't be accessed which includes the logs of what I've done so far, all I have is the current percentage of completion which I've put up here for everybody to see.

For those who personally know me, you won't be able to contact me for a long while, until a miracle happens. For everybody else, I expect I'll be down for the count for a long while, perhaps forever, only if the last month of hell leading to my computer's current state aren't undoable.

The map system has been changed, maps have been moved to the centre from the top right corner, maps have also been down sized from a 4th of the levels' sizes to a 10th. Due to where maps were, enough of the top and right side were cut off to the point you couldn't see farther via the map than just looking at the level. The down size significantly increases the maps' effectiveness, while levels now are too simple to make the most of it I do intend to make later levels more maze like. Maps have been visually redesigned to make the details clearer at the new size.

Transitions between game states have been synchronised with all other code so the visual stuff changes at the right time. Input and any other aspect of game play is locked during transitions to make sure the player is never caught off guard by them.

I have finished designing many changes for how Enigma Infinartum - Verisimilitude: PROTOTYPE is structured, making future work a lot easier, and began implementing these changes. The first functionalities to take advantage of the new structure are the synthesised audio output core which has been properly utilised for the first time, with audio files loading directly before when needed, meaning a smaller loading time when first opening Enigma Infinartum - Verisimilitude: PROTOTYPE to play, also transitions between game states, where the screen will fade to/from black when hitting what is effectively a loading screen before play modes, such as when starting an encounter with enemies.

I've rewritten the core dedicated to synthesised audio output and cleaned up a lot of the other input and output cores I've been working on these last few months, dealing with the last of the cores reusable between projects.

My plan of attack is to fix everything that's broken since the last stable release, readd any missing functionality that was temporarily disabled during rewrites a long time ago, check and perfect all of the changes I made a long time ago (Making sure I'm 100% happy with the results), restructuring and cleaning all of the code some more, and finally going through the remainder of what's on my do list.

The intention is for me to complete the next release of this and Enigma Infinartum - Lost In Space this year, and have a new site and forum online which I'm relying on somebody else for, who has sadly been stalling things for many many many months, but hopefully will pull through and make the wait worth it soon.

This semester of university is pretty much finished, meaning I'll have a lot more time to focus on our work for about 1 month before the next semester begins. Hopefully things will move forward far enough to make up for the recent drop of progress, both with the site itself and the games it will support.

Previously I talked about moving my focus to Enigma Infinartum - Terminal Velocity: PROTOTYPE over Enigma Infinartum - Verisimilitude: PROTOTYPE, which I've decided against. Progress is slowly being made for the site, as soon as it's finished I'll be rereleasing the last stable release of all of my computer games. I am likely right about Enigma Infinartum - Terminal Velocity: PROTOTYPE being the weakest release for the near future, but unlike Enigma Infinartum - Verisimilitude: PROTOTYPE it hasn't had a stable release so far. The public opinion about Enigma Infinartum - Verisimilitude: PROTOTYPE is that it's the worst thing I've released, so I'd prefer to push out a newer release of this before the first release of Enigma Infinartum - Terminal Velocity: PROTOTYPE. This far in and there isn't any progress worth talking about for anything, especially because of the university work I talked about previously, I'm simply here to make it clear that everything is moving forward and I'm not dead.

Progress for Enigma Infinartum - Verisimilitude: PROTOTYPE has been very minimal. I've been stuck on audio output for a while, spent a lot of time designing this and a lot of what I'll be doing after. I've been very unwell for few weeks which has slowed me significantly.

I'm entering a new hell with university which will make sure I have little time for Enigma Infinartum - Verisimilitude: PROTOTYPE within the next few weeks. Because of where university appears to be going in to the near future, I'm thinking about moving my focus to the Unity version of Enigma Infinartum - Terminal Velocity: PROTOTYPE which I feel will be the weakest release of all of the releases I'm working on for this phase. This way, everything after will be relatively a lot better and so people will react nicer. Enigma Infinartum - Verisimilitude: PROTOTYPE will take my focus directly after if I go forward with this.

I've been slowly but steadily making progress with Enigma Infinartum - Verisimilitude: PROTOTYPE since I last made contact. A lot of time has been spent rereading through all of my old code, which I haven't touched for near to 2 years. I'd be a bit more down about it if that time hadn't been spent working on the Enigma Infinartum - Computer Game Engine, the results of which I'm quite proud of and will finally able to show everybody when the new Leviathan Eternal - Site and Leviathan Eternal - Forum are online.

I've rewritten cores for finding the action speed, to know how fast things are playing, keyboard input, mouse input, and general input which takes care of keyboard input and mouse input. These cores are the least Enigma Infinartum - Verisimilitude: PROTOTYPE specific and easily reusable for more Java projects if I decide to do them. I began with these specifically to knock out the easier lots of this long over due rewrite, as it's been so long since I've touched anything Java related, including this project. Now all of these cores have been done, I'll be moving to rewriting the core for audio output and writing a core for general output which will take care of audio output. To make my life easier, video output won't have a dedicated core for this release, and a lot of what is needed there won't be rewritten much from my old code. The intention is to move everything roughly half way code-wise as to where I want them to be by the time I finish this version, so it doesn't take too long to accomplish.

After I'm finished with the audio output and general output cores, I'll be doing a lot of restructuring to make things cleaner and easier to work with, also allowing for smarter data loading, so files will be loaded shortly before being needed, rather than all loaded as soon as Enigma Infinartum - Verisimilitude: PROTOTYPE begins running. This new structure will also allow for smooth transitions between parts of the game like moving between explorable levels or jumping in to an encounter. For quality control purposes, I'll be having private playing sessions with supporters I'm in direct contact with, so I can have feedback before completing this, which means there should be less flaws, as hopefully they'll be able to pick them up long before the general public has a chance to suffer them, and thus I have a chance to fix them before release.

Everything has been moving forward slowly since my last update. I've spent the better part of a month pulling together disparate notes for each of my projects to I can amalgamate them in to something usable and know exactly what my development plan is for each of what I'm working on. Of all I have to work on for the cycle of releases I'm going through, Enigma Infinartum - Verisimilitude: PROTOTYPE appears as if it will be the hardest and need the most time, as it's last stable release was the most flawed of all of my work. I have spent a lot of time getting ready for this and expect to begin working on tangible aspects of it soon, I'll be updating the side of this page to show how complete it is, at the moment it's far from complete as you can see, hopefully that'll all change soon.

I've been very quiet recently for multiple reasons. I've been very unwell for over 1 month which has significantly decelerated my progress, keeping me stuck on rewriting the documentation for the newest version of the Enigma Infinartum - Computer Game Engine, the rewrite of which has progressed from 23.22% complete to 72.888% complete since I last talked about it. I was hoping to balance my slow progress, that I'd be able to talk about my coder, Soulless Sentinel's progress on the Leviathan Eternal site and forum, but they've been avoiding me out of fear as to how I'll react to their constant failures, having waited 5 plus months for something they promised many times would take them 1 month to complete. So sadly things haven't progressed much due to my unwellness as his incompetence, which is why I've been quiet for a while. At least I'm pushing through this so something is happening, regardless of the failures of people under me, their broken promises about any degree of success never getting less depressing. It sickens me to know I'm forced to rely on people like Soulless Sentinel, that spend more time running from me than making an effort to do something worth while.

The coder is back and work is steadily going forward with the new site and forum, the forum hasn't been touched but will be released at the same time as they're two sides of the same coin. I won't go in to too much detail as to what has been done so far, but I've received a copy of their work from about a month ago which is when they last worked on it when I last talked about this, and I've also received a newer build as of today. The amount of work they've done since the only build I had from two months ago before their recent reappearance, is so much that in a worst case scenario, I'd be getting a significant head start if I had to continue doing the remainder of what needs to be done, which it it looks like won't be the case, they are quite driven to completing this for me. As soon as they send a new build of the site that is able to do everything the build of the site currently online can, the new build will be going online for testing and feedback would be much appreciated.

To get the maximum amount of feedback possible for it, I'll be waiting for the new version of the Leviathan Eternal site and forum to be completed before uploading any content such as the newest version of the Enigma Infinartum - Computer Game Engine. The last time I mentioned rewriting the documentation for this, it was 9.863% complete, it is now 23.22% complete, I haven't spend much time on it during the last week due to being unwell, which I hopefully won't be for much longer.

Over the years there have been many people who have supported me, I thought it would be nice to show who has supported me with more than motivation and have added section at the left side of this site to list who have been my best supporters as far as giving me the resources to push my work goes. A big thanks to everybody listed.

As said earlier, I have completed the Enigma Infinartum - Computer Game Engine version 0.0.5.0, but haven't released it yet. While I have everything packaged and ready to go, I am rewriting the list of what has been done with this version, and would prefer to wait until such documentation is far enough along, that what it says will better represent all of the time and effort that went in to this.

As I have said earlier, I have been waiting for the next version of the site and forum to be done, which among other things, will allow me to finally get as much feedback as I need from releases such as this. The person handling both the site and the forum haven't sent me anything new for 2 months, and while I am aware they have made a lot of progress since then, my patience is wearing thin at the frustration of trying to get them to send me a newer copy of what they're working on, coupled with how relentlessly hard it is to get in contact with him, it appears of all of the many methods I try to contact him, he either isn't bothering to check his messages, or is avoiding me (Hopefully not), so here we are, waiting to hear from him.

If he doesn't reappear sometime soon, chances are I'll have to do everything he was supposed to do, which will take me far longer due to inexperience. I expect this will delay me from getting back to all of my so very neglected projects for at least another 6-12 months. Hopefully this won't be the case, but we shall see soon.

I have completed the Enigma Infinartum - Computer Game Engine version 0.0.5.0. This has taken me a very long time and I'm very proud with the results.

I have spent the last so many hours sorting through all of the builds between version 0.0.4.0 and version 0.0.5.0, organising the done and do lists, and getting everything ready for version 0.0.6.0's development. Because of this, I haven't uploaded anything today, just letting everybody know how much things have moved forward. Hopefully I'll have everything uploaded tomorrow, and will be relying on feedback via e-mail, at least until the next version of the site and forum is online, which will hopefully happen very soon.

Some people are aware of how long it has been since I've released anything, especially a new version of certain projects, not helped by how close many releases appeared to be to completion before I removed the percentages from the project side of this site, showing such a thing.

I want to make it clear that none of the projects listed at the project side of this site have been forgotten by me, for each of them I plan to do at least 1 more release, for the majority of them I plan to do more than that. I have focused all the time I have had available on the Enigma Infinartum - Computer Game Engine for the better part of 2 years, which has lead to all other projects falling behind.

Between now and 2013's ending, I plan to have released 9 new versions of projects, including those that have been so close to complete for so long. When these 9 releases have happened, I will begin consideration of what I'll be doing for future releases, especially based on whatever feedback I get.

Due to a series of unfortunate events, I've been without an internet connection since roughly the 25th of the 11th. A long story short, I don't expect to have a reliable way to be here until the 31st of the 12th. Regardless of what may have seemed like me disappearing, I have continued to work during this time, mostly focusing on the Enigma Infinartum - Computer Game Engine.

Some of you may have noticed that I removed the percentages for projects' completion at the right of the page. I have been slowly rewriting the lists of what has been done and what has to be done for each project, as these rewrites are incomplete, trying to calculate the percentage of completion for them is impossible. I will be updating the dates for when I last worked on them, but the percentages won't reappear until I've finished rewriting the documentation for them.

I have recently had code sent to me for the site's progress and it is very promising.

All of the user data has been split betweeen a non-member and a member space, 2 databases will be needed over the previous 1 to handle this, what does this mean for everybody here? For the first time ever, the site will allow people to anonymously comment or rate projects, and create topics and posts when there is a new forum. This change is an experiment to see if it will allow the site and forum to better flourish, as people will be able to be involved without having to take the time and make the commitment of making an account. If it turns out that people abuse this privelage, the non-member section will be removed, this is partly why the database for user created content has been split in to 2, as it will allow the non-member part to easily be removed without damaging the member part if it comes to it.

Iframes are in the process of being replaced by a mixture of XHTML, CSS, PHP, and JavaScript. Iframes are what have allowed an inner page to load within an outer page for so long, at the moment it's not that useful as there aren't many pages to go to outside of the news page, but when there was a lot of content here, it allowed far more efficient page loading as only the new fragments had to be loaded for each page. Why the replacement? Iframes are a type of frames, and any type of frames has many problems, which is why professionals normally frown upon them. Search engines have problems navigating sites with frames. Pages can't be directly shared with people as their browser only shows the link for the outer page, not the inner page with the content they'd want to share. If a search engine or person manages to share a link to an inner page, it will load without the outer page, some of the time there is code within the outer page that is crucial to the inner page being outputted correctly, with my site specifically, the background images won't load, so the background will be white, and as the text is white, well, nobody would be able to see anything without manually highlighting the page. Work on this change has been successfully tested with the news page, and a fall back mode is being written for people who don't have access to JavaScript, either because they have it turned off, or their browsers don't support it, so this site should appear perfectly okay for them.

I plan to meet my earlier promise. When changes like I've talked about have been applied to all of the site, I'll be uploading new code, and hoping everybody who does visit will take the time to give feedback, so we can do our best to polish our work.

For people who have been following what I write here for a while, this will appear to be deja vu. Work is actively being done on a new site and forum, chances are high that progress will be uploaded within 1 month, when that happens we will be wanting a lot of feedback so we can perfect everything before officially releasing the new version of the site and forum.

If everything goes as badly as earlier when I talked about ending Leviathan-Eternal, the worst case scenario is that the site and forum will exist as they are, after the new version has been released, and I'll try to release at least 1 new version of each previously publicised project before ending everything, so the site and forum should have a lot to offer within this worst case scenario. Hopefully everything will be significantly better than that and we will be forever releasing fun things for everybody here.

Recently everybody has gone out of the team, likely forever. There was 5 of us, now there is 1. They were doing a lot of work, or at least they were supposed to be, on the computer game engine, the site, and forum. As they've all gone, it likely won't happen now. After so many misfortunes over the years, I'm tempted to stop trying, everything appearing impossible to do by myself. If everything dissappears here, it would be because Leviathan-Eternal has ended. It was fun for a while and hopefully everybody involved will move to better things.

The person who was working on the new version of the site and forum has gone, as we have so few people and none who are able to work on this, progress will be significantly slower than was planned. I'll try to organise a solution to this problem, the worst case scenario is I'll have to focus my time on this while many projects go without any progress for a while. I am determined to make sure the new version of the site and forum is done soon enough to help all of our projects become more public.

Some people may have noticed I had adverts showing at the top left and top right sides of this page, they were from Google Adsense and were helping pay for the work we're doing as people being here would indirectly lead to us having more money to work with through Google Adsense. Sadly Google decided to permanently close our account without giving a reason so we have lost that way to make money, making donations a more important thing as we won't be able to make money without having anything to sell and it will be a while before we have anything to sell.

I will be prematurely uploading the new version of the site and forum when they are usable for early feedback. I want to find all problems with the new site and forum early so they can be solved equally early. Any data relevant to this old version of the site or the premature release of the new version of the site and forum will be removed after this time of feedback ends, if anybody wants to continue being members, they will need to make new accounts. The new version of the site and forum isn't online, I will say more here when they are.

For anybody who wants to be helpful for the progress of Leviathan-Eternal's many projects, I have added the donate page which allows people to donate money to Leviathan-Eternal.

A new version of the site and forum are being made with solutions to hopefully all of the problems within the old version. This temporary minimal version of the site will exist while we work on the new version of the site and forum. Hopefully the new version of the site and forum will be completed within 2 months.

The site and forum have been dead for over 4 months because the server's owner didn't pay for the hardware the site and forum were on, he said he would pay for it on the 4/5/2012 but that clearly didn't happen, I have been messaging him for many months with the hope he would send me the site's and forum's data so I could move to a new server without him but he hasn't. This server is temporary until he stops being incompetant. All projects are progressing as usual so there isn't any reason to be concerned about that. Hopefully this problem will be solved sooner instead of later.