-
RPG Frequencies has taken the time to create a Discord Channel for Sojour to promote discussion!
You can join the discord here: https://discord.gg/DRnv3Qs5Ru
I’d like to thank him for the time and effort in setting this up!
RPG Frequencies also hosts a You-Tube channel covering all things Solo RPG here:
https://www.youtube.com/@RPGFrequencies
In the meantime,
Have Fun!
RobP
-
If you want to get a feel for what Sojour is capable of, the current manual can be viewed here.
Have Fun!
RobP
-
Sojour is a Windows based solo focused VTT that provides journals, maps, tokens and time management. A detailed run through is shown on this timestamped video.
It costs $10 USD. Once bought, Sojour is yours to keep. There are no subscription fees, online servers or DRM. All your data remains your data, stored on your computer. You will get free updates as they are produced.
If you have ever struggled trying to use a multiplayer VTT for solo gameplay, then you should give Sojour a look 🙂
-
Sojour 1.3.0.0 Custom Folders is finally here! It’s with a little excitement and some trepidation that Sojour 1.3.0.0 has finally been released!
The reason for the trepidation is that this release also includes a huge refactor of the code in the User Interface layer. I think my testing has covered everything, but with such an extensive change, it always feels that whatever testing I do, it will never be enough!
This release is primarily about providing the new custom folders feature for customers.
Other features and fixes are also included. The full list is below:
RPG-360 Sojour now supports custom folders! That is, the ability for users to create their own folder structures under a variety of nodes in the assets browser. This story also included a massive coding refactor of the UI layer.
RPG-407 Sojour now provides the option to activate or deactivate all characters under a folder or node, including all of its sub-folders, with just a single mouse click.
RPG-411 Reenabled the use of the enter key to close simple dialog windows. This functionality was originally disabled due to useability issues. However, it turns out those issues only affected the larger dialog windows (the user would accidently shut them when hitting enter whilst typing text entries). This functionality was re-enabled after a customer request.
RPG-412 Moving the mouse cursor off map whilst the fog of war torch is on, will temporarily switch off the torch until the mouse cursor returns over the map.
RPG-414 Fixed a rare bug (which bit me) for the Restore functionality. In the bad old days if you squirreled away your old saves folder before the time of Sojour’s file manager being introduced, and then changed your Windows Documents directory, then tried to restore that saves folder, it would lead to missing maps and tokens. This has now been fixed.
RPG-416 The Microsoft WebView component has been upgraded to the latest version. This is used for viewing PDFs.
RPG-417 Sojour now hides and re-shows the token palette for more of its functionality. This is to prevent soft locks caused by the palette appearing over other dialog windows.
Here is the obligatory You-Tube video covering off the main new features:
I hope you good folk will find the new folders functionality beneficial for your games! 🙂
That’s it for this release!
Have Fun!
RobP
-
This is a very quick update post to let you folks know where we are!
After 14 hours and 30 minutes, the custom folders detailed testing is now complete!
Many interesting issues were found and all have been resolved.
In addition, I also needed to tidy up a few things. For example, the context menu now looks a lot more professional with the functional areas being properly separated into groups:
Nicer looking menus! (Click for larger image!) The code for custom folders has now been merged into the main code branch, so there is no turning back now – the next release has to include custom folders! This release will be version 1.3.0.0.
The only thing left to do now is to update the manual.
This will be a fairly significant revision as there is a lot you can do with custom folders, plus, I also need to cover off the upgraded character activation-deactivation system.
Total time on this feature has been pretty high:
Total time on custom folders! (Click for larger image) Each day is the equivalent of 8 hours, so in total I have worked 70 hours and 57 minutes on custom folders and this total does not include the additional effort needed to update the manual.
Not long to go now! (Honest!)
Hopefully this update will be in your hands in the next week or so. Thank you for your patience!
Have Fun!
RobP
-
Before I discuss this update, I’d firstly like to thank each and every one of you that have bought Sojour! We have now reached the 500 sales mark and have earned the coveted Gold Best Seller Tag:
We reached 500! 🙂 (Click for larger image) With that excitement out of the way here is the custom folders update.
Custom folders has reached a milestone – All of the functionality is now coded!
The tasks that I have left are to update the manual and to conduct extensive testing and fix any issues that are found.
During the final coding phase of custom folders I had to change the way that the deactivated character feature worked. Though now that it is done, I think it’s a change for the better!
In the past, when you deactivated a character, it would be moved to a special Deactivated Characters folder within the Assets Browser:
Before Deactivation (current system):
Before deactivation Ionara appears under the Characters folder. (Click for larger image) After Deactivation (current system):
After deactivation Ionara has been moved to the Deactivated Characters folder. (Click for larger image) This has now changed. The Deactivated Characters folder is no more!
In the new system, when you deactivate a character, rather than moving folder, its iconography will change instead:
Before Deactivation (new system):
Before deactivation. Note that there is no deactivated characters folder! (Click for larger image) After Deactivation (new system):
After deactivation. Ionara stays in place, but her iconography has changed! (Click for a larger image) But wait, that’s not all that’s changed!
Given that we now have the ability to create folders within the characters folder, I decide to add the option to be able to activate and deactivate all characters within a folder and its sub-folders with a single mouse click!
For example, here I have created a number of folders to represent my core characters and various places within a scenario:
Here we have created a number of folders to categorize our characters. (Click for larger version) Our party is currently in the tavern. All the characters associated with the tavern are activated, whilst, conversely, the character in Ionara’s home is deactivated.
When the party eventually moves to Ionara’s home, we could activate Ionara by activating all characters under Ionara’s home, then we could deactivate all characters under the ‘In the Tavern’ folder using just one mouse click:
Here we are about to deactivate all characters that are ‘In the tavern’ using the new menu options. (Click to view larger image) The end result of deactivating everyone under ‘In the tavern’:
All the tavern residents are now disabled by a single menu item! (Click for a larger image) In addition, if one wanted to, one could activate or deactivate all characters under the Scenario 1 folder (and sub-folders) or alternatively all characters in the entire campaign by selecting the correct folder level.
Plus, one still has the option to individually activate or deactivate characters.
This new functionality should make it much easier to organize and manage your characters in large campaigns.
That’s it for this update. I hope you all like what you see!
Have Fun!
RobP
-
This is a very minor tweak to the load-save mechanisms that were themselves updated in the previous release under RPG-396.
The reason for this adhoc release is that a customer has reported on Drive-Thru that Sojour wasn’t saving their data. I couldn’t replicate this issue, no matter how hard I tried, but I was paranoid enough to go over the updated load-save code with a fine toothcomb.
This examination resulted in a few minor tweaks. I don’t think these tweaks will affect anyone, but I’d personally feel a lot happier if customers use this release rather than 1.2.155.0. As a result I have taken down 1.2.155.0 and replaced it with 1.2.160.0.
If anyone else sees any data saving issues, please contact me at sojour.pollysoft@outlook.com.
Have Fun!
RobP
-
I’ll start by saying that this is NOT the custom folders release. Work is still ongoing for that release, but I do have a video of it in action!
Instead, this release is focused on bug fixing and maintenance that addresses the following issues:
RPG-396 When Sojour crashes (on load), we should not be overwriting the main save files: This is an important one. I have had 3 reports over the last year of customer’s save games being corrupted.
When I examined their saved games, it looked like the save files had become partial save files. I finally traced a potential use-case where this can occur…
There are occasions where Sojour could crash during loading resulting in incomplete data being resident in memory. The global exception handler would then try and save that data resulting in partially complete saved files.
This will no longer happen. In addition, I have changed the code for closing down Sojour post crash so that it more reliably closes its process down.
RPG-397 Sojour shouldn’t crash if there are missing data directories on load. A week or two back I had a customer report that their Sojour game was crashing during loading and there was nothing they could do.
On investigation, I discovered that some of the customer’s data folders were missing. This upset Sojour and caused it to crash.
Sojour is now a lot more tolerant with regard to missing folders or data. In addition, if a crash is detected whilst loading, Sojour will now offer the option to pick a different data directory, restore from a back up, or simply exit:
The new exception handler for failed loading! (Click the image to see a larger version) RPG-399 Sojour crashing when dragging character to map with journal open. This was an odd one in that the investigation had found some corrupt internal data within the customer’s save file which, alas, I hadn’t been able to reproduce.
This corrupt data was centred around token characteristics. All token characteristics code has now been updated to be more fault tolerant.
RPG-400 Adding or editing a map-link with no campaign selected crashes Sojour. Sojour used to use the assets browser to get the current campaign or ruleset. The flaw with this approach is that if a user selects a different campaign, or no campaign at all, it can lead to Sojour having problems.
This code has been entirely re-written and all places that used to rely on the assets browser for the active ruleset or campaign, no longer do so, and instead, use the updated code.
RPG-401 Adding or editing a map-link when the map is set to show all, doesn’t show them! This is a minor issue where adding or editing a map-link would result it in not respecting the current map’s Show Map Links option. This has now been fixed!
Work has been slowed down a little by the fact that Sojour currently has three work streams associated with it:
The three main work streams / branches! Having three streams of parallel work means that any issues I find in one of them has to be merged into the others. This is normally pretty easy using my source control system.
However, the fly in the ointment is that the Custom Folders branch sports a radically different UI architecture from the other two branches, which means that some fixes have to be hand coded as opposed to merged!
Normally I try to work on one thing at a time, but I soon realised that if I stayed on the calendar work, my customers would see very little new from me as that work is such a large undertaking.
Custom folders sprung up as a result of many customer requests and of seeing Lord Gwydion struggle with his data during the live streams. As with most things software related, I had thought it would be a quick and easy update, but it has turned out to be a little more complex. Hopefully the video above will provide ample evidence that we are headed the right way.
Finally we have the main branch where all the hot-fixes and high priority changes go.
My end game is to get back to one branch again, but this is predicated on me delivering the Mk2 Calendar and Custom Folders functionality! 🙂
That’s it for this post!
Have Fun!
RobP
-
I spent most of last week on the unscheduled refactoring work alluded to in the last post.
Doing a big code refactor is always a scary experience that can be likened to renovating a house.
You start off by ripping things out, moving them around and then trying to re-wire everything back up. It all feels like a real mess that could never ever work again!
It’s at this point, with a multitude of compiler errors, that one experiences the temptation to just scrap the refactor and go back to the original code. However, with a little fortitude, patience and a large dollop of luck, one can see it through to the end and reap the benefits!
One of the benefits for me is that the amount of code in the main window almost got halved!
From over 6000 lines of code to around 3600 lines of code! (Click for larger image) The removed code was taken away and componentised by functional area. So all the map actions are now in one place as are all the journal actions etc. They are no longer intermingled in the main window’s code. This makes it much easier to locate and understand the code I need to work on!
The refactor has also enabled me to create a custom context menu component which allows for the addition of the custom functionality to support user defined folders.
For example, every user defined folder’s context menu now inherits functionality from its parent asset:
The context menu on a folder under Journals. (Click for larger image) 
The context menu on a folder under Tables. (Click for larger image) If you examine the two images above, you will see that the folder under journals inherits journal functionality, whilst the folder under tables inherits the tables functionality. This will work for all other asset types too.
Custom behaviour such as this would have been a right royal pain to do inside the main window’s code – hence the refactor.
Now that the refactor is behind me, work has re-commenced with user defined folders – itself a distraction from Calendars Mk2 – but we will be going back to that too!
The result is that we are now at a point where one can now perform most of the standard operations that one would expect to be able to perform on the new user defined folders.
For example, here is a screenshot showing a whole bunch of journal and map folders that I created:
Folders galore! (Click for larger image) All your existing data and games will work with the new folders system – Sojour will automatically update your data to be compatible. (It will also create a backup of your data too!)
What’s left to do?
Firstly, I need to get the whole thing to work with drag and drop – this can be non-trivial.
Next up, I will be refining the deletion code. Right now there isn’t a lot of warning if you delete a top level folder containing a lot of your precious work. I want to make sure that such deletions cannot happen accidently.
Once that’s done, I’ll need to look at character activations and deactivations, as these got a little more complicated under the new folder structures.
Finally, I’ll need to update the manual and accompany that with a lot of testing.
So a fair bit to go, but the hard stuff is now out of the way!
Alas, I can’t give a release date for this as there are simply too many variables at play, but hopefully, the screenshots above will provide some assurances as to how far along we are.
That’s it for this post!
Have Fun!
RobP
-
This is a quick update to let you folks know what I’m currently up to!
Calendar Mk2 work is still progressing with more automated tests being added all the time.
However, I decided to take a short break from the calendar work to enable me to deliver some much requested functionality: Folders!
Up until now the user had no real power of organisation in Sojour. They were reliant on the structure that’s provided in the Asset Browser.
The new code that’s being written changes this and will allow users to add their own folders so as to better organise their work:
We will soon be able to add folders! (Click for larger image) To add a folder, all one need do is right click and select ‘Add Folder…’ to an existing folder or to one of the following nodes:
- Campaign Assets
- Characters
- Documents
- Journals
- Maps
- Tables
- Document Templates
This will result in the folder naming dialog appearing:
The folder naming dialog (click for larger image) Once a name has been entered, your new folder will appear in the Asset Browser:
A new custom folder! (Click for larger image) The folder system is coded to allow one to define folders within folders. You can go as deep as you need to go. The only limitation is that folders can only hold one type of data based on their parent node.
For example, if you create a number of folders under the Maps node, only maps can be stored in those folders. However, you can store as many maps as you want at whichever levels that you want!
I was on the home straight of delivering the folders functionality when I realised that Sojour had a bit of an architectural problem…
Whilst plumbing in the new menu items needed to support the folders system I realised that the display layer of Sojour had rather too much complex code in it. 6412 lines of code to be precise. (Eeek!)
This code encompasses a huge range of user functionality resulting in it being hard to figure out what’s where and how it all hangs together.
Architecturally, on the whole, Sojour is pretty good in that each subsystem such as Maps, Journals, Tables etc is confined to its own classes with no cross talk.
However, the large display layer kind of throws the spanner in the works with regard to architecture because it has to orchestrate many of these subsystems and user controls to do the users bidding – often resulting in some pretty complex code.
This complex code is made harder to understand simply because it is all in one place within the display layer.
I felt I needed a way to simplify the display layer in order to make it easier to find and understand what was going on within that layer.
To that end, I came up with the concept of an Action.
These Actions represent the actions of a user.
Actions would then be grouped into classes by originating subsystem. For example, all actions originating from a Journal would find themselves housed in a JournalActions class.
These actions classes would then coordinate all the UI changes and subsystem orchestrations in order to achieve what it is that the user wants. Such an architecture helps keep related functionality together and it encapsulates the really hard parts away from the display layer.
The result is that the display layer will have a much simpler and smaller code base.
For example, if you wanted to change the hit points of an NPC in the Journal, all the display layer would need to do is call JournalActions.UpdateNpcHitPoints – just one line of code and that’s it! This contrasts to the many hundreds of lines of code currently within the display layer for this specific functionality.
The other advantage of this architecture is that many UI elements can now cleanly invoke the same functionality without having to duplicate the code or understand how it works!
It’s a great architecture and I’m quite pleased with it. But, alas, it’s going to take a fair bit of time. I have already made a fair bit of progress but there is still a long way to go:
Almost 12 hours have been pumped in so far! (Click image for full sized version) It turns out that the quick diversion from the Calendar Mk2 work for custom folders is going to end up being a not-so-quick one.
On the plus side, it will leave Sojour’s architecture in a much better place to accept changes and as a bonus you folks will get the much requested folders system!
That’s it for this update!
Have Fun!
RobP
-
This is a minor update that provides the following enhancements:
RPG-391 Attempting to open an already opened document will now bring that document into focus, even when that document is minimized. For minimized documents Sojour will now restore it to where it was originally located on the desktop and then bring it into focus.
RPG-392 Microsoft’s WebView2 component – used for PDF viewing – has now been upgraded to the latest available version.
The WebView2 component proved particularly difficult to update as my source control system wouldn’t let me push the latest WebView2 binaries because they were too big.
Dev-Ops hat is now firmly on as I attempt to fix the WebView2 issue! The downside to being a sole developer on a project is that one has to be multi-disciplined. I have to be the Software Developer, the Technical Author, the QA, the DevOps person, the Marketing Manager, the Business Manager, an Accountant and the Customer Service representative! Though luckily not all at once!
To fix the WebView2 issue, I had to put on my Dev-Ops hat and figure out a way around the binary size issue. After a lot of tweaking on the build server, I finally managed to find a solution and get the latest WebView2 component to build on the build server! 😎
The above enhancements were added after watching Lord Gwydion’s excellent You-Tube series for Under the Ashen Skies:
I noticed that Lord Gwydion worked with a lot of PDFs and was having issues locating the ones he needed to use – hence the above enhancement.
Work still continues on the Mk2 calendar system. The automated tests are now up to 211 in number! These tests have highlighted many areas where the code needed improving.
These improvements have been implemented, but there is still a lot more to do, both in terms of adding new automated tests and in adding new Mk2 calendar functionality.
We are now up to 211 automated calendar tests! That’s it for this update!
Have Fun!
RobP
-
This is a fly by update to let folks know that development is still ongoing in the Sojour world despite time pressures.
As per previous posts, the current development focus remains with the Calendar Mk2 system (which I should really give a name!).
One of the things that I have realised whilst developing this system is that it has many complex algorithms that interact with each other. As a result it can be quite easy to upset them and not know that they have been upset.
In the end I decided that this is an area of Sojour that absolutely needs some automated testing around it.
Automated tests will automatically ensure that the complex algorithms in the Mk2 Calendar are performing as they should. These tests also highlight existing potential issues and pitfalls – many of which have since been fixed after being identified by these tests.
The ever expanding test suite for calendars Mk2 (Click for larger image) We are now up to 134 integration tests that are automatically run by my development environment every time I merge code:
The build server automatically running the new tests! (Click for larger image) Writing the tests takes a fair bit of time, including the time required to integrate them with the automated build pipeline – it’s why the build server screenshot above shows a lot of red as I try to get the server to run the tests correctly.
Despite the time cost, these tests enable me to write code faster and more efficiently.
If I do break something it will be flagged on the build server and also in JIRA as shown below, top left (the red rectangles are builds where tests failed):
The builds show up top left in JIRA! (Click for larger image) If any of the tests do fail, they will provide detailed information as to why they failed that should speed up my job and also help to produce a warm fuzzy feeling that things are working properly and headed in the right direction.
Ok, so that’s what I have been doing on the new calendar system, but, what’s Dorian when it’s not at home?
Dorian is a new graphics engine that I’m working on. It will replace Ionian which is the one currently used by Sojour (and by Ancient Armies).
A very early version of Dorian strutting its stuff! Why a new graphics engine?
The primary reason is that Ionian is preventing Sojour from being a 64 bit application, which limits the memory it can access. This can lead to limitations with image sizes etc.
Dorian will be fully 64 bit compatible, it will support Direct-X 9, 11 and 12, plus it will allow rendered surfaces to be embedded in WinForms – much like the current Ionian engine.
The above demo shows it running successfully in a 64 bit application in a WinForm – a big milestone for the engine.
There is still a lot of work to do and once the engine is ready, Sojour will need to be updated to be able to work with the new engine. It will be a non-trivial job, but it’s a piece of tech debt that has to be tackled to allow me to take Sojour to the new places it has to go.
That’s it for this post!
Have fun!
RobP
Sojour is the premier solo virtual table top (VTT)
Sojour 