Tag: RPG Software

Posted on

April 2025 Development Update!

A quick fly-by update to let you good folk know where we are.

Development has been slow, mainly because I’m finding trouble getting the time together. That’s completely my fault, as I have far too many hobbies!

I’m still working on the Mk2 Calendar system but we have progress!

Firstly, we are back where we were – in that the calculation and display systems are now fully operational again:

The calendar is now working again!

In addition, multiple rolling entities can now be added. In the above screenshot we are just using one set of rolling entities called ‘Days of the Week’. But what if we also added phases of the moon?

It’s a little artificial in that I have only included 4 phases, but it’s a great example!

Here is what the calendar looks like with phases of the moon added:

Two sets of rolling entities! Days of the week and phases of the moon!

Not entirely realistic. However, rolling entities do support a skip function. Given that these phases tend to happen every 7 days in real life, I have decided to set the ‘Day Skip’ to six. eg there will be six skipped cells before the next rolling entity triggers.

Sets the day skip – 3rd field down – to six!

The results?

The phases of the moon rolling entity now skips every six cells!

It is starting to look a little more ‘real’, though I did randomly set the synchronisation point on the previous screen (aka Start Year and Start Rolling Entity), so these moon phases will not be the ones you will see in real life – unless I’m very lucky.

The above functionality will enable people to to add special rolling events in the form of iconography or text to their calendars. This should benefit many RPG calendars. For example the Runequest Gloranthan calendar should show the phases of the Red Moon as that moon directly affects the strength of Lunar magic. This system makes it very easy to add those phases!

Can we go further? Maybe by adding a third rolling entity?

A third set of rolling entities? Why not?

This new set comprises of 5 random pictures in a fixed sequence. Adding the new sequence results in a calendar that looks like this:

Three sets of rolling entities! Days of the week, Moon Phases and another random image sequence!

In addition, I can also apply an independent ‘Day Skip’ to the new rolling entities. In this case I will specify a skip of 2 cells:

Skip set to two fields!

The result?

All working as expected!

As you can see in the above screenshot it all works perfectly!

Plus, as you would expect, these rolling entities roll properly across month boundaries.

Here is a screenshot of the previous month:

The previous month!

Note that the sequences of rolling entities, the days, moon phases and the other images carry over across the month boundary!

What about going a month forward?

Forward a month!

Going forward a month also results in the three sequences from each rolling entity group carrying on correctly across the month boundary 😎

Plus, remember, that the Gregorian calendar that you see in the above examples is created from first principals using time units and rolling entities – no operating system calendar components are used! Sojour’s calendars also go a lot further forward and a lot further backward in time than the Windows calendar too – see this post for more information.

None of this post probably makes much sense right now, but it will do when I put a video together explaining this new powerful system and how it will help you create any calendar that you can imagine!

A lot of progress with the Mk2 Calendar system, but still a lot more to do.

And for those that don’t know, if you buy Sojour, all updates are free 🙂

That’s it for this update!

Have Fun!

RobP

Posted on

March 2025 Development Update!

Rather than stay in a black hole whilst working on the Calendar Mk2 system, I thought, that instead, I’ll provide some regular updates.

These updates might not necessarily prove useful in of themselves, but at least they’ll let you folk know that I’m still working on things.

In the last post I alluded to the fact that I had refactored the code in the calendar backend without having updated the UI to use that code (Doh!). This resulted in various UI elements simply not working, or in extreme cases crashing!

A bit of a backward step considering we did have a mostly working system!

I’m now at a point where the UI is starting to work again.

Although a hard slog, I think the detour is worth it. The result is that the new code runs faster and because it is better encapsulated, the higher level code in the UI is also a lot simpler!

The hard bit is working out what needs to stay, what needs to go and what needs to be modified. This is quite a difficult task when one considers the complexity of the modelling (it’s complex because it can model any calendar you can imagine!)

Here are some screenshots that show the UI is now back and working… mostly….

Firstly we can now view mark 2 calendars again:

The UI is now showing calendars again – without crashing out!

The above screenshot shows a Gregorian Calendar created with Sojour’s built in tools.

At this point, the structure of a year has been defined, but the Days of the Week rolling entities have not been switched on. The result is a calendar month with the correct number of days but no real context.

Next up, I switch on the Days of the Week rolling entities:

Days of the Week rolling entities activated!

Straight away we can see a number of things have kicked in.

Firstly, days of the week now appear in the calendar and you can see that the relevant time units in the tree-view have been properly overridden by the rolling entities.

The other notable feature is the way the month view has automatically added space elements to allow all of the same days of the week to align in the correct column (the additional blank row at the bottom is an existing bug that will be fixed).

The fact that this is working at all, is somewhat miraculous, given how different the new backend code is.

Next up I tried turning off the upper header bar to see what would happen:

Upper header bar turned off!

Right away, the system removes that header bar.

It has also realised that with no column headers, the calendar cells no longer have context – i.e. the day of the week. The system remedies this by automatically adding the day of the week to each calendar cell.

Speaking of calendar cells, these are not the finished product. The cells are currently rudimentary and are designed so that I can check the calendar calculations are working correctly. They will look a lot better and incorporate a lot of new functionality once completed.

Everything seems in order, although the ‘spare-row’ bug is still there.

Finally I turn off Days of the Week to make sure the tree-view reverts back to its original settings:

Days of the week turned back off!

And it does! All good!

There is still a huge amount of work to do as I keep identifying additional use-cases that need to be covered off by the code. The good news is that the newer code is much better segregated, which makes adding new functionality like this a cinch.

The effort ploughed into this feature, so far:

That’s a lot of commits!

That’s a lot of commits and development time!

Whilst this feature takes me away from Sojour’s more regular updates, I’m a firm believer that it is essential for Sojour’s longevity.

Sojour needs a calendar system that can model rolling calendars, which right now it cannot do. The current version cheats with regard to this feature by having the Gregorian calendar use the Windows Calendar! In contrast the new system does not do this and recreates all calendars from first principals.

That’s it for this mini update!

Have Fun!

RobP

Posted on

Sojour 1.3.18.0 minor bug fix has been released!

This is a small bug fix that one of my customers reported:

RPG-440 Drag and drop in the Assets Tree-View now works when there is no map loaded.

That’s it for the release.

Work is still underway on the Mk2 calendar system, though it turns out I have more work to do than planned.

Last year, before I added the custom folders system I had added a whole bunch of integration tests to Sojour to support the MK2 calendar – 211 of them in total!

Integration Tests for the Mk2 Calendar System!

What I hadn’t realised was that whilst writing these tests I had actually performed a large refactoring of the code to ensure that each class was focused on its job, and solely on its job.

Architecturally, it’s a great idea and it will also make the system easier to maintain in the future.

However, these changes were put in without updating the UI layer to use the new updated system(!) – “previous Rob” has a lot to answer for!

This has meant a lot of rework in the UI layer. We are headed in the right direction, it’s just I’m a little further behind schedule than anticipated.

In the meatime

Have Fun!

RobP

Posted on

Back in the Saddle!

I’m now back in the saddle after some time off over the Christmas period.

I hope that everyone had a great Christmas holiday and is feeling refreshed for 2025!

The first part of this year’s development effort will be focused on completing the work on the calendar Mk2 system for which there have already been a number of posts.

The Mk2 Calendar System!

For those that want the TLDR, the new system supports rolling calendars which means that calendars such as Pathfinder’s become a possibility. It also means that the Western Gregorian calendar can start using the same calendar technology as everything else (it currently uses Windows Operating system components).

Once the work is completed, users should be able to create any calendars that they can imagine – all from within Sojour itself.

I feel that the Mk2 system is important because Sojour is primarily built upon three cornerstones:

  1. Time tracking
  2. A sense of place (aka mapping)
  3. Journaling.

I have always considered the time tracking part to be the weakest subsystem of the three which is why it is being upgraded. There are also plans for the other two, especially the journal, but I don’t want to go into that just yet.

The Mk2 Calendar System is one of those tasks that I know is big and that I’m already quite far into it, but alas, I don’t really know how much farther there is to go. All I know is that there is a tangible sense that I’m over the hump.

That’s it for this short update.

Have Fun!

And I’ll talk to you all later!

RobP

Posted on

Sojour 1.3.1.0 Minor fix has been released!

This minor fix addresses the following issue:

RPG-421 When dragging campaign assets to the map, Sojour used to register two drag and drop events, this resulted in the drop event being called twice, which in turn resulted in two identical tokens being dropped on the map. This only affected campaign assets that were set as not unique. This has now been fixed. The drag and drop event is now only registered once, resulting in only one token being dropped.

This is the only reported bug after the rather large release on Friday (touch wood). I was expecting a torrent of bug reports and angry customers with pitchforks on the Saturday morning, but luckily for me, that never materialised!

I guess the testing was good after all! 😎

If you folks do find anything else, please do get in touch and I’ll see what I can do!

That’s it for this drive-by post.

Have Fun!

RobP

Posted on

Sojour 1.2.160.0 has been released!

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

Posted on

Sojour 1.2.155.0 has been released!

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

Posted on

Refactor done! Plus an update for User Defined Folders!

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

Posted on

Folders and a Refactor!

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