Introduction

The Dark Souls Trilogy (1-2-3) from FromSoftware is one of the modern gaming classics. The games should be experienced by everybody because of their excellent gameplay, combat mechanics, atmosphere and character development. The defining characteristic of the Dark Souls Trilogy and what scares most gamers is their over the top difficulty.

This great difficulty is increased even more because of the saving mechanism of these games: There’s a single save game in the game, if you die you’ll return to a previous checkpoint (called bonfire). These checkpoint are sparcely located within the gaming world and they are not always near boss fights, so if you die in a boss fight you may need to kill enemies for sometime before you reach the boss again to retry. Also, everything is permanent so if you screw up somehow (i.e you kill an important NPC) there’s no way to “restore” your game; you’ll lose him (and his items if he’s a merchant) for the rest of your current game!

If the above seems too difficult for you to even try, fear not! There a particular way to have “real” saves in all three Dark Souls games, even if it is a little cumbersome. It will be much less cumbersome than having to restart the game because you killed an important NPC.

Disclaimer

Before describing the technique I’d like to provide some disclaimer points:

• The Dark Souls Trilogy should be experienced as-is. You shouldn’t use this method because you’ll make the games easier and not as difficult as it was intented by their publisher. Use it only as a last resort when you are going to abandon the game.
• Most other Dark Souls players will mock you and hate you for using these techniques.
• You may break your save if you do something wrong so I won’t be held responsible for losing your progress.

How Dark Souls saves your game

All three Dark Souls games have a particular directory in your hard disk where they place their save game. There’s a single file with your save game that has an extension endingg in .sl2.

From my PC, the folders and names of each of these games are the following:

• Dark Souls Remastered: Folder C:\Users\username\Documents\NBGI\DARK SOULS REMASTERED\1638, filename: DRAKS0005.sl2
• Dark Souls 2: Scholar of the First Sin: C:\Users\username\AppData\Roaming\DarkSoulsII\0110000100000666\, filename: DS2SOFS0000.sl2
• Dark Souls 3: C:\Users\username\AppData\Roaming\DarkSoulsIII\0110000100000666\, filename: DS3000.sl2

Notice that the username will be your user’s username while the numbers you see will probably be different.

Now, when some particular action occurs (i.e when you kill an enemy) the game will overwrite the file in the folder with a new one with the changes. You will see a flame in the top right of your screen when this happens. Notice that this happens on particular moments, for example if you are just moving without encountering enemies your game won’t be saved (so if for example you make a difficult jump the game won’t be saved right after the jump). Also, Dark Souls will save your game when you quit (so if you do a difficult jump, quit the game and restart you will be after the jump).

The above description enables you to actually have proper saves: Quit the game (not completely, just display the title screen), backup the save file in a different location, start the game. If you die, quit the game (again just display the title screen), copy over from the backup to the save location and start the game again. Notice that you should always quit the game before restoring from a save file because Dark Souls reads the saves only then. If you copy over a backup save while playing the game the backup will be just overwritten with the new save data.

However you can backup your game without actually quitting: When you’ve reach a point you feel it needs saving, just alt+tab outside of your game copy over the save to a backup location (you can even give it a proper name) and continue playing. When you want to load that save you’ll need to quit, restore the backup and start the game again. Notice that when you do this the game will show you a warning that you “did not properly quit the game”. From what I can understand, when you quit the game Dark Souls writes some flag to your save game. If you shut down your PC while playing (or copy over the save game) then Dark Souls won’t write that flag to your save game. However from my experience in all three Dark Souls games this warning doesn’t mean anything, the game will continue normally without any problems.

Making it simpler

Copying over the save game in a different location is cumbersome and makes it easy to do mistakes (i.e copy instead of restoring your backup save, copy over the current save to your backup). To make this process easier I will give you here a simple autohotkey script that will do this for you using F7 to backup your save and F8 to restore it (don’t forget that you can only restore when you have quit the game and see the title screen).

To use this script you need the excellent autohotkey utility. Download and install it and then execute the script by double clicking it (it needs to have an .ahk extension):

#SingleInstance Force
#MaxHotkeysPerInterval 99999
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.


SAVE_FOLDER_DS := "C:\Users\serafeim\AppData\Roaming\DarkSoulsII\0110000100000666\"
SAVE_FILENAME_DS := "DS2SOFS0000.sl2"
BACKUP_FOLDER_DS := "C:\Users\serafeim\Documents\ds2\"


GetFolderMax(f)
{
  MAX := 0
  Loop, Files, %f%\*.*
  {
    NUM_EXT := 1 * A_LoopFileExt

    if (NUM_EXT> MAX)
    {
      MAX := NUM_EXT
    }
  }

  return MAX
}

F7::
{
  ;MsgBox % "F7"
  ;MsgBox % "Will copy " . SAVE_FILENAME_DS . " to " . BACKUP_FOLDER_DS

  MAX_P1 := GetFolderMax(BACKUP_FOLDER_DS) + 1
  ;MsgBox % "Max + 1 is " . MAX_P1

  SOURCE := SAVE_FOLDER_DS . SAVE_FILENAME_DS
  DEST := BACKUP_FOLDER_DS . SAVE_FILENAME_DS . "." . MAX_P1

  ;MsgBox % "Will copy " . SOURCE . " to " . DEST
  FileCopy, %SOURCE%, %DEST%
  return
}

F8::
{
  ;MsgBox % "F8"
  MAX := GetFolderMax(BACKUP_FOLDER_DS)
  MAX_FILE := BACKUP_FOLDER_DS . SAVE_FILENAME_DS . "." . MAX
  ;MsgBox % "Maxfile is " . MAX_FILE

  SOURCE := MAX_FILE
  DEST := SAVE_FOLDER_DS . SAVE_FILENAME_DS

  ;MsgBox % "Will copy " . SOURCE . " to " . DEST
  FileCopy, %SOURCE%, %DEST%, 1
  return
}

The script is very easy to understand but I’ll explain it a bit here: First of all you need to define the SAVE_FOLDER_DS, SAVE_FILENAME_DS and BACKUP_FOLDER_DS variables. The first two are the folder and filename of your game (in my example I’m using it for DS2). The BACKUP_FOLDER_DS is where you want your backups to be placed. This script will backup your save file in that folder when you press F7. To keep better backups it will append an increasing number in the end of your filename so when you press F7 you will see that it will create a file named DS2SOFS0000.sl2.0, then DS2SOFS0000.sl2.1 etc in the BACKUP_FOLDER_DS. When you press F8 it will get the file with the biggest number in the end, strip that number and copy it over your Dark Souls save file.

As you can see there’s a GetFolderMax function that retrieves the max number from your backup folder. Then, F7 and F8 will use that function to either copy over your Dark Souls save file in the backup with an increased number or retrieve the latest one and restore it in your save folder.

The script works independently of the game so if you configure it and press F7 you should see that the backup file will be created. Also if you delete (or rename) your Dark Souls save file and press F8 you should see that it will be restore by the backup.

So using the above script, my play workflow is like this: Start Dark Souls, kill an enemy, press F7, kill another enemy, press F7 (depending on how difficult the enemies are of course). Die from an enemy, quit the game, press F8, continue my game.

One thing to notice is that in Windows 10 it seems that the hotkeys are not captured from autohotkey when the game runs in full screen. When I run the games in a window it works fine. Some people say that if you run autohotkey as administrator it will capture the key-presses but it didn’t work fine for me.

Intro

In this small post I’ll present a small tutorial on how to add a timelne of your Wagtail posts using the Horizontal Timeline jquery plugin.

This will be a step by step tutorial to help you understand the concepts. As a base we’ll use the bakerydemo wagtail demo. After you’ve properly followed the instructions you’ll see that this demo site has a “Blog” that contains articles about breads. Following we’ll add a timeline of these articles grouped by their publish month.

Decisions, decisions

For this demo we’ll include all the “blog” pages in the timeline. However we may wanted to select which pages we want to include in the timeline. This could be done either by adding an extra field in our blog pages (class blog.models.BlogPage) like include_in_timeline or by using the Wagtail ModelAdmin functionality. For the ModelAdmin we’d create an extra Django model (i.e BlogTimeLineEntry) that would contain a link to the original page. We could enchance this field with extra fields that we may want to display in the timeline, for example a smaller description. Something like this:

The other decision is where to actually output the timeline. For the demo we’ll just put it in the BlogIndexPage page. If we wanted to add the timeline in a number of different page types then we’d need to add a template tag that would include it. But since it will be available only to a single page type we’ll just need to override the get_context method and the template of that particular type.

Overriding the get_context

As we described above, we want to group the timeline entries based on their publish month. For this, we’ll use the following code in the BlogIndexPage.get_context method:

def get_context(self, request):
    context = super(BlogIndexPage, self).get_context(request)
    context['posts'] = BlogPage.objects.descendant_of(
        self).live().order_by(
        '-date_published')

    entries = context['posts']
    dentries = {}
    for e in entries:
        month = e.date_published.strftime("%m/%Y")
        month_entries = dentries.get(month, [])
        month_entries.append(e)
        dentries[month] = month_entries

    lentries = sorted(
        [
            {
                "date_small": k,
                "date_large": v[0].date_published.strftime("%B %Y"),
                "entries": v,
            }
            for (k, v) in dentries.items()
        ],
        key=lambda z: z["entries"][0].date_published,
    )

    context.update(timeline=lentries)
    return context

So what’s the purpose of the above? First of all we use super to retrieve the context that any parent classes may have setup. After that we add a posts attribute to the context that is a queryset of all the published children of the current page (which is the BlogIndexPage), sorted by their published date.

In the for loop that follows, do some dict trickery to “gather” all entries for a particlular month/year in a list under that particular key in the dentries dict.

Finally, we create the lentries list which will be a list of the form:

[{
        "date_small": "09/2020"
        "date_large": "September 2020"
        "entries: [BlogPage, BlogPage, BlogPage...]
}, {...}, ...]

This struct will help us in the next step when we implement the timeline template.

Fixing the template

To use the horizontal timeline we need to add a couple of css/js dependencies to our template. For this, we’ll first go to the bakerydemotemplatesbase.html file and add the following snippet near the end of the file just before </body>:

{% block extra_script %}
{% endblock %}

The above is required to give us a placeholder for adding some needed js dependencies and code.

After that we’ll go to the bakerydemo\templates\blog\blog_index_page.html file and add the following just before {% block content %}

{% block head-extra %}
        <link rel="stylesheet" type="text/css" href="//cdn.jsdelivr.net/gh/ycodetech/horizontal-timeline-2.0@2/css/horizontal_timeline.2.0.min.css">
        <style>

                .timeline .selected {
                        font-size: 24px;
                        font-weight: bold;
                }

                #timeline ol {
                        list-style: none;
                }

                .horizontal-timeline .events-content li {
                        background: #f2f2f2;
                        font-size: .8em;
                }

                #timeline img {
                        width: 200px;
                }
        </style>

{% endblock head-extra %}

And the following at the end of the file

{% block extra_script %}

        <script src="//cdn.jsdelivr.net/gh/ycodetech/horizontal-timeline-2.0@2/JavaScript/horizontal_timeline.2.0.min.js"></script>

        <script>

        $(function() {
                $('#timeline').horizontalTimeline({
                dateIntervals: {
                        "desktop": 200,
                        "tablet": 150,
                        "mobile": 120,
                        "minimal": true
                }
                });
        })

        </script>
{% endblock %}

Notice that the head-extra block is already there in the base.html file so we don’t need to add it again. It just has some styling changes for the timeline to be displayed nice. Also the <script> tags we added just include the needed dependency and initialize the timeline component.

Of course we haven’t yet added the actual timeline! To do that, we’ll need to add a file named timeline_partial.html under the blog/templates/blog folder (same folder that blog_index_page.html is) with the following:

{% load wagtailcore_tags wagtailimages_tags %}
<div class="horizontal-timeline" id="timeline">
  <div class="events-content">
        <ol>

          {% for month in timeline %}
                <li class="{% if forloop.last %}selected{% endif %}" data-horizontal-timeline='{"date": "{{ month.date_small }}"}'>
                  <h3>{{ month.date_large }}</h3>

                  {% for te in month.entries %}
                        <div class='row'>

                                <div class='col-md-6'>
                                  <h4><a href='{% pageurl te %}'>{{ te.title }}</a></h4>
                                  <span>{{ te.introduction }}</span>
                                </div>
                                <div class='col-md-6'>
                                  {% with img=te.image %}
                                        {% image img width-200 as img_thumb %}
                                        <img class="" src="{{ img_thumb.url }}" alt="{{ img.title }}">
                                  {% endwith %}
                                </div>

                        </div>
                        <div class="clear bottommargin-sm"></div>
                  {% endfor %}
                </li>
          {% endfor %}

        </ol>
  </div>
</div>

The above will generate a <li data-horizontal-timeline='{"date": "01/2020"}> list element for all months and inside that it will add an <h3> with the full name of the month and a bunch of bootstrap rows, one for the entries of that particular month (including its title, description and their image at the side). It should be easy enough to follow.

Finally, we need to incldue the above partial template. So add the line {% include "blog/timeline_partial.html" %} immediately above the <div class="row row-eq-height blog-list"> line in the file blog_index_page.html.

If you’ve followed the instructions you should be able to see something like this:

The os_mon erlang application

os_mon is an erlang application that, when started will run 4 processes for monitoring CPU load, disk, memory and some OS settings. These don’t work for all operating systems but memory and disk which are the most interesting to me do work on both unix and Windows.

The disk and memory monitoring processes are called memsup and disksup and run a periodic configurable check that checks if the memory or disk space usage is above a (configurable) threshold. If the usage is over the threashold then an error will be reported to the SASL alarm handler (SASL is erlang’s System Architecture Support Libraries).

The alarm handler situation

The SASL alarm handler is a process that implements the gen_event behavior. It must be noted that this behavior is rather controversial and should not be used for your own event handling (you can use your own gen server solution or gen stage). A gen_event process is an event manager. This event manager keeps a list of event handlers; when an event happens the event manager will notify each of the event handlers. Each event handler is just a module so when an event occurs all event handlers will be run in the same process one after the other (that’s the actual reason of why gen_event is not very loved).

The SASL alarm handler (the gen_event event manager) is implemented in a module named :alarm_handler. A rather unfortunate decision is that the default simple alarm handler (the gen_event event handler) is also implemented in the same module so in the following you’ll see :alarm_handler twice!

The default simple alarm handler can be exchanged with your own custom implementation or you can even add additional alarm handlers so they’ll be called one after the other.

To add another custom event handler for alarms, you’ll use the add_handler method of gen_event. To change it with your own, you’ll use the swap_handler of gen_event. When the default simple alarm handler is swapped it will return a list of the existing alarms in the system which will the be passed to the new alarm handler.

A simple alarm handler implementation

As noted in the docs, an alarm handler implementation must handle the following two events:

{:set_alarm, {alarm_id, alarm_description}} and {:clear_alarm, alarm_id}. The first one will be called from the event manager when a new alarm is created and the send one when the cause of the alarm not longer exists.

Let’s see a simple implementation of an alarm event handler:

  defmodule Phxcrd.AlarmHandler do
  import Bamboo.Email
  require Logger

  def init({_args, {:alarm_handler, alarms}}) do
    Logger.debug  "Custom alarm handler init!"
    for {alarm_id, alarm_description} <- alarms, do: handle_alarm(alarm_id, alarm_description)
    {:ok, []}
  end

  def handle_event({:set_alarm, {alarm_id, alarm_description}}, state) do
    Logger.warn  "Got an alarm " <> Atom.to_string(alarm_id) <> " " <> alarm_description
    handle_alarm(alarm_id, alarm_description)
    {:ok, state}
  end

  def handle_event({:clear_alarm, alarm_id}, state) do
    Logger.debug  "Clearing the alarm  " <>  Atom.to_string(alarm_id)
    state |> IO.inspect
    {:ok, state}
  end

  def handle_alarm(alarm_id, alarm_description) do
    Logger.debug  "Handling alarm " <>  Atom.to_string(alarm_id)

    new_email(
      to: "foo@foo.com",
      from: "bar@bar.gr",
      subject: "New alarm!",
      html_body: "<strong>Alert:"  <>  Atom.to_string(alarm_id) <> " " <> alarm_description <>  "</strong>",
      text_body: "Alert:" <>  Atom.to_string(alarm_id) <> " " <> alarm_description
    )
    |> Phxcrd.Mailer.deliver_later()

    Logger.debug  "End handling alarm " <> Atom.to_string(alarm_id)
  end

end

This implementation also has an init function that is called when the handler is first started. Notice that it receives a list of the existing alarms; for each one of them I’ll calle the handle_alarm function. This is needed to handle any existing alarms when the application is starting. The :set_alarm handler also calls handle_alarm passing the alarm_id and alarm_description it received.

The clear_alarm doesn’t do anything (it would be useful if this module used state to keep a list of the current alarms). Finally, the handle_alarm will just send an email using bamboo_smtp. Notice that I use deliver_later() to send the mail asynchronously.

As you can see this is a very simple example. You can do more things here but I think that getting the Alarm email should be enough for most situations!

Integrating the alarm handler into your elixir app

To use the above mentioned custom alarm event handler I’ve added the following line to the start of my Application.start function:

:gen_event.swap_handler(:alarm_handler, {:alarm_handler, :swap}, {Phxcrd.AlarmHandler, :ok})

Please notice that the :alarm_handler atom is encountered twice: The first is the event manager module (for which we want to swich the event handler) while the second is the event handler module (which is the one we want to replace).

os_mon configuration

The are a number of options you can configure for os_mon. You can find them all at the manual page. For example, just add the following to your config.exs:

config :os_mon,
  disk_space_check_interval: 1,
  memory_check_interval: 5,
  disk_almost_full_threshold: 0.90,
  start_cpu_sup: false

This will set the interval for disk space check to 1 minute, for memory check to 5 minutes, the disk usage threshold to 90% and will not start the cpu_sup process to get CPU info.

Testing with the terminal

If no alerts are active in your system, you can test your custom event handler using something like this from an iex -S mix terminal:

:alarm_handler.set_alarm({:koko, "ZZZZZZZZZ"}
# or
:alarm_handler.clear_alarm(:koko)

Also you can see some of the current data or configuration options:

iex(4)> :disksup.get_disk_data
[{'C:\\', 234195964, 55}, {'E:\\', 822396924, 2}]

# or
iex(7)> :disksup.get_check_interval
60000

Please notice that the check interval is in seconds when you set it, in ms when you retrieve it.

Conclusion

The above should help you if you also want to better understand alert_handler, os_mon and how to configure it to run your own custom alert handlers. Of course in a production server you should have proper monitoring tools for the health of your server but since os_mon is more or less free thanks to erlang, why not add another safety valve?

If you want to take a look at an application that has everything configured, take a look at my Phoenix template application.