Whisky visit to Islay

In April 2022 I visited Islay with a few friends to visit distilleries and try whisky. I will write a bit about the distilleries.

Ardbeg

Ardbeg has a more uneven, spectacular and even experimental range of whiskies compared to other distilleries on Islay i would say. In the store you can buy a 3×20 cl kit of Beastie, An Oa (their kind of introduction whisky) and 10YO (the Ardbeg classic). Limited sale of bottles in distillery.

Because of Covid-19 things were not quite normal. In Ardbeg the shop sold a 5×2.5ml tasting that you could try in their café, in their garden or bring home. I brought most of it home and did head to head tasting (I think it is really hard to do something with 5 whiskies at the same time). I rank the from best to worst:

  1. 22 year old Twenty Something
  2. Auriverdes
  3. Traigh Bhan (batch #3)
  4. Dark Cove
  5. Perpetuum

Very short notes follow:

22YO beats Traigh Bhan. 22YO is ligh, fresh, salty with a lingering flavour. Traigh Bhan is more sweet and woody.

22YO beats Auriverdes: Auriverdes is very slightly darker in color, a bit less peated, and a bit more fruity (but not sweet) and winey. 22YO is more aggresively peated on the nose, and has a softer saltier more sea-like complex flavour. Auriverdes is a bit bitter.

Auriverdes beats Dark Cove: Dark Cove is darker and sweeter, richer, with a hint of sherry on the nose. Auriverdes is more ash-dry. Tasting Dark Cove it is both sweet and raw peat, with an unfortunate hint of sulphur in the end. Auriverdes more elegant, integrated and fresh.

Traig Bhan beats Dark Cove: Dark Cove is dark with a hint of sulphur. Traigh Bhan is ashy, very dry.

Dark Cove beats Perpetuum: Dark Cove is sweeter with a hint of sulphur. Perpeteeum is drier, more malty, fresh but more bitter.

22YO beats Perpetuum: 22YO is classic, winey, malty and complex. Perpetuum is pale, malty fresh and dry.

Traigh Bhan beats Perpetuum: Perpetuum is rather dry wood, bitter. Traigh Bhan is light, soft sweet, burnt and a bit sour.

I also made short tastings against other whiskies.

Bowmore 18 beats 22YO Ardbeg: Bowmore is darker, mellow, malty, soft yet peated in the mouth. 22YO Ardbeg is more peated, has more salt and sea, some freshness, but hints of bitterness and rather burnt.

The Ileach vs Ardbeg Perpetuum: Ileach is daker, soft, salty, a bit bitter and the easier whisky to drink. Perpetuum is more dry, ashy and has a strong flavour of petroleum.

Ardbeg Dark Cove vs Bowmore 15: Bowmore is darker, with a rather sweet and fruity aroma with some vanilla. Ardbeg is also a bit fruity, but more dry, sour and peated. Bowmore quite easy to drink, not so overwhelming. Ardbeg has a bit more punch, more petroleum, perhaps more sulphur. Bowmore may be more easy but Ardbeg has more character and Bowmore is not that good to beat it.

Ardbeg 22 beats Longrow 18: Longrow is darker, with a somewhat sweet aroma. Ardbeg is more dry and peated on the nose, and with a fine elegant full peated flavour. Longrow is thicker, more sour, more dirty.

Bunnahabhain 8 Heavily Peated beats Ardbeg Traig Bhan: Very similar color. Bunnahabhain has on old closet smell. Ardbeg more sour peated. Bunnahabhain is soft, rich complex and peated. Ardbeg is lighter , less soft and complex, and more thin.

Ardbeg Auriverdes beats Bunnahabhain 8 Heavily Peated: Bunnahabhain a bit darker, with a softer less peated aroma. Tasting both Ardbeg has a more solid consistent flavour, salty, peated and balanced. Bunnahabhain is a little sour and a litte bit everywhere.

Laphraoig beats Ardbeg Auriverdes: Laphroig a little darker, and with a slightly heavier aroma. Auriverdes a hint of fruitiness on the nose, a bit burnt in the mouth, more ashy and dry. These whiskies are quite similar, Laphroaig being a bit softer in the mouth. Auriverdes is more spectacular.

Kilchoman Machir bay beats Ardbeg Auriverdes: Machir Bay is paler, and with a more sweetish synthetic aroma. Ardbeg is more straight peated. In the nose, Kilchoman is a bit oily, quite soft, and sweetish. Ardbeg is saltier with a hint of petroleum. Auriverdes is more spectacular.

Ardbeg Corrywreckan beats Ardbeg Dark Cove: Dark Cove slightly darker, and with a sweet sherry aroma. Corrywreckan is more dry, and rather salty, reasonably complex. Dark Cove has a fruity taste of sulphur.

Ardbeg Dark Cove beats Longrow 13 Red: Longrow has a more red (unusual) whisky color. Both have a powerful fruity sherry aroma. Longrow is rather nice salty first, followed by some old margarine. Ardbeg is saltier, less balanced. Longrow is more mature in flavour, but too much sulphur.

Ardnahoe

As I understand it Ardnahoe is as of April 2022 not selling any whisky, just busy producing, so we just stayed for a photoshoot in the morning.

Bowmore

Bowmore is the oldest licenced warehouse on Islay and their facilities indicate “premium” (as Lagavulin). Age statements is important for Bowmore marketing and be aware that Bourbon/Sherry mix varies a lot between ages (with 15YO being pure Sherry). In the distillery I tried a (budget) Bowmore #1 (not available where I live) and I find it preferable to Bowmore 12.

We did a Vault Secret Tour of the distillery ending in tasting directly from two casks in their oldest warehouse and being permitted to fill up a 10cl bottle ourselves and bring home. That was nice.

Bruichladdich

We just did a quick gift store stop in Bruichladdich. I have to admit I am not a very big Bruichladdich fan and we had not planned to do very much there. It seems the Gin brand Botanist (which is excellent) that is manufactured and sold by Bruichladdich is perhaps a bigger business than whisky nowadays.

In Bruichladdich you can fill your own (well, I guess they supply the) bottle from a cask in the store.

Bunnahabhain

Also in Bunnahabhain we just did a stop i the gift shop and strolled around a bit. Bunnahabhain has by far the best shop on Islay for the tourist fan (but check out Lagvulin too). There were several distillery-exclusive whiskies available as 70cl, 20cl or 5cl which is quite perfect when you are on whisky-tour on Islay. They also serve free tastings of those whiskies in the store so you can try before you buy.

Coal Ila

We did not visit Coal Ila.

Kilchoman

In Kilchoman we did a tour and a tasting. Kilchoman opened in 2005, and the thing about them is that they do everything locally. 30% of the barley comes from their own farmland around the distillery – and that goes into the 100% Islay Malt. The rest of the malt is bought from Port Ellen Malteries. Kilchoman is not about age statements, and perhaps there will be occational aged whiskies, but never in the core line. Machir Bay is 90% bourbon cask and 10% sherry cask, it is also the one I like the most. The visiting centre was nice and the shop had some smaller bottles for sale for tourist (20cl, 5cl) which I appreciate.

Lagavulin

In Lagavulin we did a tasting of 6 whiskies in their warehouse lead by legend Ian McArthur. The whiskies we tried were from 10 to 25 years old. For “drivers” or the careful drinker it was possible to get samples home instead of drinking in the warehouse. Ian explained that 16YO is the main expression. Everything else is limited, gimmic. Lagavulin offers a premium standard product, the 16YO, and that is how they want things to remain. 16YO is (as I remember it) is heavier and sweeter than other things I tasted in th Distillery, so 16YO is kind of different. This means that when you encounter a peated whisky that does not taste like Lagavulin 16, it may very well be a Lagavulin nevertheless. The Distillery store, which was very elegantm had plenty of whiskies to buy, Lagavulin and other brands (like Mortlach). Everything in 70cl bottles though so no purchases for me.

Laphroaig

We did a nice standard tour of Laphroaig. I asked and they dont make 15YO Laphroaig anymore and the 10YO is their very popular main whisky. They have plenty of variations: Select, Quarter Cask, and some sherry options. Select is a mix of different things. Quarter Cask is finished an a 125L Quarter Cask, which makes it sweeter. Lore is a more premium old rich mix. Distillery store has a very basic range of Laphroiag bottles for sale, and when it comes to smaller bottles just a 35cl 10YO.

Port Ellen

Port Ellen is under (re)construction and we had the opportunity to take photos of the stills.

Springbank

We finished our journey taking a trip to Campbeltown and Springbank. We did no take a guided tour in Springbank but we ordered a whisky tasting to our table, and they had good choices of tastings! The store was kind of crappy with expensive clothes (like they do not want poor people to wear their brand), and very limited selection of whisky to bring home. I tried the blended whisky Campbeltown Loch which was a surprisingly nice experience (but do not expect miracles of course).

Springbank also hides the bourbon/sherry-ratio as age statements: 10YO is 60/40, 12YO is 100/0, 15YO is 0/100 and 18YO is 50/50. For us bourbon fans it means that the 12YO cask strength is the reasonable choice.

Buying bottles

As a tourist from outside UK I can bring 1L whisky home duty free (that is, paying tax in UK and not paying it again when I get home). I would have been very happy if more distilleries offered 5, 10 and 20cl bottles of interesting whisky in their stores. If you visit Islay and you visit the distilleries in some order it is not so easy to know where to spend your money. So my advice for shopping whisky in the distilleries:

  • If you want a nice 70cl unusual, perhaps even exclusive and expensive bottle, buy it in Lagavulin
  • If you want good selection of smaller bottles, and being able to tast, go to Bunnahabhain
  • If you want something unique – hand filled – buy it in Bruichladdich
  • If you just want to bring home 1L of a good scotch whisky, buy it duty free in the airport on your way home

Practical Fullstack approach to Vue3

I am a fullstack developer. I do user support, requirement analysis, nginx configuration, backup handling, integrations and css. Much of my work is centered around Node.js and Vue.

I do not love Vue and I am not fascinated with it, nor interested in its internal working. It is a tool to write reactive (2-way-binding) web applications and to modularize web code (write small reusable components).

I started using AngularJS (v1) years ago. That changed the way I thought of web development and I became more productive making better web applications. However AngularJS is kind of abandoned now, and it is a much heavier framework than need. So I started transitioning to Vue2 some years ago thinking of it as AngularJS-light. In most ways Vue2 is nicer than AngularJS, except sometimes it (the reactivity system) does not work (predictably). Well, Vue2 probably works exactly as it is written to work, but for me as a developer I think I do what works, and then it fails for some delicate detail that I can figure out if I have time, maybe. That is waste of time and it adds uncertainty to my job.

I have this feeling with Vue2 that I need a plan (a design pattern) and I still have not found one that works well. Now I started migrating Vue2 to Vue3 and things change a bit (and things break a bit). So now I really want to find simple design principles for my Vue3 applications, that I can follow so everything works without me thinking about it.

State

The real challenge when writing an (single page web) application is managing the state:

  • Information about session
  • I/O and error handling
  • Incoming data, updating state and UI, avoiding conflicts
  • Application settings, like filters and user choices
  • Data validation and invalid-data-feedback to user
  • Data modelling

This is harder than writing a good user interface. So the client-side-design needs to be state-first, not UI-first. Also

  1. I am migrating things from Vue2 to Vue3 that were originally AngularJS. If the state, business logic, I/O, were dependent on AngularJS-stuff I would be stuck in AngularJS.
  2. I can write this state in generic JS (not specific for web/UI) and thus make it possible to also run it on a server, exposing it as APIs and do automated testing

So I am not interested in Veux. Perhaps it can run backend, I do not care. This is how I think of my architecture:

  1. GUI (as thin layer as possible)
  2. Web component business logic (plain JS, no Vue, can run in Node.js)
  3. State (plain JS, no Vue, can run in Node.js)
  4. Server Side (Node.js)

Most code can (ideally) run in 2-4, and can thus be tested in Node.js. Vue is only about (1).

State – Vue – Interface

Some applications are large and state consists of many modules. Some are small. For a simple example I think of state as (this is, admittedly based on Vue2-experience, where you need to consume state data in a way that makes it reactive in Vue).

STATE = {
  ro : { ... things that are readonly to Vue (like server data) ... }
  rw : { ... things that Vue can change (like filter choices or user input) ... }
  api: { ... functions that can do stuff with state ...}
}

Typically I would get this from a plain JS factory function where I can supply dependencies that are possibly implemented (for I/O) differently on Browser and Node.js:

function MyStateFactory(libIO, lib1, lib2) {
const state = { ro:{} , rw:{} , api:{} };
... set up state ...
return state;
}

How do I make this state available (and reactive) in my Vue application and Vue components? I can admit that in the past I have been lazy and done things like (pseudo code):

Vue.Component({
  data : function() {
    return { state : STATE };
  },
  ... more stuff
});

That kind of works in many cases! But I have also ran into problems. In a real application you have 3 types of components:

  1. Those that depend only on supplied props
  2. Those that depend only on state
  3. Those that depend on a mix of props and state

In theory, all components should be (1) and all other design is rotten (you may think). In practice 2 and 3 are useful too.

So the real questions are:

  1. How do you expose state, as data and functions, so changes can be picked up by the right components?
  2. How do you design components so they update when they should?

AngularJS – Vue2 – Vue3

AngularJS has a function that recalculates everything, over and over again until it gets the same result twice. Then it updates the DOM accordingly. AngularJS does not detect changes to data automatically, however when you use its api to manipulate data, you are also telling AngularJS that you are changing data, and the function mentioned before can run. If you change data from outside angular you may need to use $scope.$apply() to tell Angular to refresh.

In Vue2, when you make an object part of “data” in a component, it becomes “reactive”. This is very implicit and it has some limitations (with Arrays, for example). What if a prop changes? What if you have a method that uses external data (as a state outside Vue), does that trigger refresh of the component? If a parent refreshes does that refresh the children? What if a child element deep down in data/prop changes? What if properties in data are replaced/added rather than modified? All I say is that to someone so stupid and ignorant as me it is not obvous how to make Vue2 just work.

Vue3 is more explicit (I interpret that as Vue2 was unpredictable not only for me, and that the Vue2 abstraction was leaky). While AngularJS and Vue2 hide the mechanism that drives reactivity Vue3 has the very explicit functions:

  • ref
  • reactive
  • readonly
  • shallowRef
  • shallowReactive
  • shallowReadonly

These functions are what connects the Vue controllers to the outside-of-Vue-world, and makes it possible for Vue to detect changes.

Vue3 – a first simple practical design

So, now we can think that we have something like this:

var state = { a:1 };
state = Vue.reactive(state);

Vue.component({
  props : { /* parameters to component here */ },
  data : { /* component local data here */ },
  methods : { /* access state via functions here */ }
});

Lets explore what happens and what works!

Vue.reactive()

We need to understand – exactly – the difference between the argument and the result of Vue.reactive():

var state_reactive = Vue.Reactive(state_original)

I have experimented (test0) and found that:

  • They share the same data, that is, the data lives in state_original
  • If you add/delete/modify data in one of them, it is immediately available in the other
  • state_orginal, and none of its children, will ever be reactive
  • state_reactive, and all of its children, will always (more on this later) be reactive
  • state_orginal and state_reactive (and all of its corresponding children) are never the same object (everything in state_reactive is Proxy to state_orginal)

The consequence of this is that your state-library must modify data in state_reactive, if you want Vue to be notified of the change (when Vue anyway refreshes for any reason, it will get the changes).

So the problem becomes:

var state = StateFactory();

// will not work because the internal state of StateFactory is not affected
state = Vue.reactive(state)

// this has severe implications:
//  1) Vue is modifying something inside the state library
//     (that was explicitely supposed to be read-only)
//  2) How does the state library protect itself?
//     possibly keeping an internal ro, and replacing the state.ro regularly
state.ro = Vue.Reactive(state.ro)

So I would say that you will need to design your state library with this in mind.

  1. Be clear that state.ro, state.ro can be made reactive this way, or
  2. Expose something else that can be made reactive (state.updated), or
  3. If the “Vue” object is present, the library could use it and take care of making the right things reactive itself, or
  4. The library has some way to notify of updates (an update callback function), and in the Vue-world, you let that callback be a function that updates something that IS reactive already.

Regardless of this little problem it is a much better situation than the Vue2-way of adding external objects in data and hoping for the best.

What Vue3 Components are updated?

Now that we know what data outside of the component that is reactive, the questions are:

  • what changes trigger the component to be updated?
  • when do child components update?
  • can any number of components, independently, be triggered by the same reactive variable?
  • if a reactive variable is used in a method, does that trigger an update
    • even if the method is not always called
    • even if the variable is not always used in the method (only some branches)
    • even if the result of the method does not change
    • even if the result of the method is not rendered
    • when the method called on any other occation (like polling)
  • is there any risk that some components are updated multiple times (in one cycle)?
  • in what order are the components updated, and can it matter?
  • what is enough to trick/force a component to update?
  • can a component update only partly?

I do not really want to know. I just want a way of designing my components so they work predictably. What I have found in the past is that when I write one big Vue-component (or application) I have no problems. But when I start modularizing it, with components that are sometimes but not always nested, that is when problems start. I have asked myself questions (with Vue2) like:

  • can one component override/replace what triggers another component, making the earlier “trigger-subscriber” dead?
  • can I end up with deadlocks, infinite recursion or mutual dependencies?
    (it has happened)

We kind of can not keep all these details in mind when building an application. We need to have a simple design that just works every time.

Single Application

I have written a simple test (test1) application with no child components. I want to explore how little reactivity works.

// Start with a STATE:
  STATE = { lines: [] };

  setInterval(() => {
    updateLines(STATE);  // implemented elsewhere somehow
  }, 2000);

// Make reactive
  STATE.lines = Vue.reactive(STATE.lines);

// Make a simple app (not showing everything)
  Vue.createApp({
    data: {
      function() {
        return { lines : STATE.lines }
      }
    }
  });

// In HTML Template, do something like
  <tr v-for="l in lines">...</tr>

This works (as expected) IF updateLines does not replace the lines array. So I have experimented and found:

Vue.reactive(STATE.lines)updateLines keeps linesworks
Vue.reactive(STATE.lines)updateLines replaces linesweird behaviour
Vue.reactive(STATE)updateLines keeps linesworks
Vue.reactive(STATE)updateLines replaces linesweird behaviour
Vue.shallowReactive(STATE)updateLines keeps linesnot at all
Vue.shallowReactive(STATE)updateLines replaces linesnot at all

The problem here is that when STATE.lines becomes a new array, the data:function in createApp does not re-run, so we keep track of and old array that STATE no longer cares about (the weird behaviour is that updateLines kept part of the old lines-structure and that “garbage” is still reactive).

It is clearly a sub-optimal situation that the implementation of state, and not just what STATE looks like, matters. 4 alternatives do not work, 2 work but are bad design. What about:

  STATE = Vue.shallowReactive(STATE);

// Make a simple app (not showing everything)
  Vue.createApp({
    data: {
      function() {
        return { state : STATE }
      }
    }
  });

// In HTML Template, do something like
  <tr v-for="l in state.lines">...</tr>

This works also sometimes:

Vue.shallowReactive(state)updateLines keeps linesnot at all
Vue.shallowReactive(state)updateLines replaces linesworks
Vue.reactive(state)updateLines keeps linesworks
Vue.reactive(state)updateLines replaces linesworks

The only thing that works regardless how updateLines is implemented, is to make all of STATE recursively reactive and make all of it data in every component. Exactly what I admitted above that I had been doing with Vue2.

shallowReactive is appealing, but it depends on the inner implementation of state, and that kind of design will quite possibly give you nasty bugs later when something changes.

So, making your data embrace STATE, or part of states works only if you know how state updates itself, unless you make exactly all of STATE recursively reactive. I think more people than I find that sledgehammer approach unsatisfying.

How about state signalling that something is updated, by updating a primitive variable (value, to avoid using ref and then ending upp with value anyway)? Note that updated.value is truthy from the beginning, and it will alwasy be truthy (++ only operation on it ever), but Vue does not know that so it needs to read and check.

  STATE = { updated: {value:1} , lines: [] };

// Make just updated reactive
  STATE.updated = Vue.reactive(STATE.updated);

  setInterval(() => {
    updateLines(STATE);
    STATE.updated.value++;
  }, 2000);

// And in Vue.createApp
  data : function() {
           return {
             lines : STATE.lines,
             updated : STATE.updated
           }
         }

Now, we can not rely on

  • lines, because it is not reactive at all
  • updated in data because it is not used in the template

However, there are some things that work. First it seems nice to replace lines in data with a method:

  methods : {
    getLines : () => { return STATE.lines; }
  }

  <tr v-for="l in getLines()">...<tr>

However, that is not enough because lines is still not reactive. But here are 3 simple little hacks that do work (and of course there are or more):

  <-- output updated in the template - not typically wanted -->
  Updated: {{ updated.value }}

  <-- display table (parent of lines) "conditionally" (always truthy)-->
  <table v-if="updated.value">

  // use updated.value in getLines()-function
  getLines() => { return STATE.updated.value ? STATE.lines : []; }
  getLines() => { console.log(STATE.updated.value); return STATE.lines; }
  // assuming devnull exists and does nothing
  getLines() => { devnull(STATE.updated.value); return STATE.lines; }

You can use this.updated.value if you use function() instead of ()=>{}. I find it quite a positive surprise that the above works even if neither lines nor updated is in data:

  STATE.updated = Vue.reactive(STATE.updated);

  data: {}
  methods: {
    getLines : () => { return STATE.lines; }
  }

  <table v-if="updated()">
    <tr v-for="l in getLines()">...</tr>
  </table>

This is beginning to look like something that appeals to my sense of simplicity. The conclusion for simple application, external state, and no components is that you have two (simple to explain) options:

  1. Make all of STATE (the exposed data, not functions) recursively reactive. Use it directly from everywhere.
  2. Make only one variable, STATE.updated, reactive. Make sure to poke (++ is probably ok) that variable whenever you want anything else to update.

Beware of doing things like value = STATE.some.child.value for anything that is expected to work beyond the next “tick”. Please note that I have not build a big single-application-zero-components application this way. So for now, this is just a qualified hypothesys.

You can check out the final result as test1.

Application with components

I split my application into three components. The application itself has no data or methods.

  • Application (test2)
    • Market
    • Portfolio
    • Copyrigh notice (nothing reactive, should fail to update)

This worked fine with no changes to reactivity compared to test1. So I got confident and made components for the lines:

  • Application (test3)
    • Market
      • Market-quote
    • Portfolio
      • Portfolio-stock

This did not immediately work. The template in Market had this content:

  <test-market-quote v-for="q in getQuotes()" :q="q">

getQuotes is still depending on update.value and is called every time, but it “happens” to return the same, modified, quote-lines every time. So the test-market-quote does not realise anything changed:

  APP.component('test-market-quote',{
    props : {
      q : Object
    },
    data : function() { return {}; },
    template: '#test-market-quote',
    ...

So I needed to replace (in a method in the test-market-quote component):

  return API.valueOf(stock) < STATE.trader.cash;
//with
  return STATE.updated.value && API.valueOf(stock) < STATE.trader.cash;

in order to make sure some method in the child component also is dependent on updated.value. This was not needed when there were no child components, becuase the parent component had another dependency on updated.value and that cause the update of the entire component (but obviously not forcing its children to update). That worked in one component, but the other component had no methods to add a dependency to, so I successfully replaced

  <td>{{ s.name }}</td>
<!-- with -->
  <td>{{ upd(s.name) }}</td>

//and added
  methods : {
    upd : (v) => { return STATE.updated.value ? v : 0; }
  }

Reality check!

This is beginning to be ridiculous. How many obscure hacks are we going to use to not have to rely on the reactivity system that is at the heart of Vue? These kind of hacks are also a source of (subtle) bugs and can make refactoring harder. The problem I have experienced with Vue is that I need to understand how things work under the hood. But with these different updated.value hacks the cure is getting as bad as the disease (that said, these hacks are probably anyway things you need to do, if components do not update when you want them to).

So I was thinking about a universal fix for updated.value (test4):

// first a reusable function
  API.yes = () => { return !!updated.value; }

// second every (child) component makes it part of its methods
  methods: {
    yes : API.yes
  }

// third, every component template has a root element, add a v-if
  <div v-if="yes()">
    .. component template body ..
  </div>

This works! It is rather simple.

Two working practial design choices

So, we have arrived at two rather simple (conceptually) ways to build predictable Vue3 applications that rely on external (Vue-independent) state code:

  1. Make all state recursively reactive, from the root
  2. Only make an update-variable reactive, and make all components depend on it

Obviously there does not have to be exactly ONE state. There can be some log-state, some io-state, some user-setting-state, some data-state and they could possibly work differently.

Regardless, it is important to understand that if there is an exposed state, the code responsible for the state may update objects, replace object, reuse objects and move objects around in the state (tree), unless the state is very clear and strict about this.

How is the recursive reactivity-tree updated?

We have a plain object:

  x1.a.b.c.d = 5;

// make it recursively reactive

  x2 = Vue.reactive(x1); 

// we add something in x1

  x1.a.b.c2: {d : 3.14} };

// NOW c2 and c2.d can not possibly be reactive, because if
// Vue could know that we did that to a child of x1, we would
// not need to make a reactive copy (proxy) of x1 in the first
// place. The above operation does not trigger anything in Vue.

// How does it happen that c2 and c2.d *eventually* end up
// begin reactive?, that is
//   isReactive(x2.a.b.c2.d) => true

// Well I think when you do that (isReactive) you are accessing
// x2, x2.a, x2.a.b and eventually x2.a.b.c2. That means, you
// are asking the Proxy b to give you its child c2 - which it was
// not aware of. But now it is!
// So it can find c2, make it recursively reactive before giving it
// to you so you can resolve x2.a.b.c2.d and pass it to isReactive().

That is how I think it works.

Vue2 vs Vue3

I really have not code very much in Vue3 yet. But I have done enough research to write this post. I think Vue3 seems to be MUCH better.

In Vue2 I ended up doing:

STATE = { ro:{}, rw:{}, api:{} };

Component({
  data : function() {
    state_ro : STATE.ro
  },
  methods : {
    stuff : function(
      state_ro.foo ...     // is there any difference?
      ... STATE.ro.bar     // does it matter if I use
    )                      // state_ro or STATE.ro?
  }

This mess is GONE with Vue3. Making things reactive is 100% explicit. data can be used exclusively for local variables to that component instance. methods can be used to get external state data, and if it is reactive that methods will trigger and the component will update.

I can imagine that this can essentially be done with Vue2 as well. But with the implicit reactivity system based on putting external state in data I never managed to figure it out.

When my code is migrated to Vue3 I will never look back at Vue2. I think.

Performance

I get a bad feeling when I think of thousands of lines, where each line is a complex object (like an invoice), and everything is made reactive, recursively. And that there are thousands of components on my web page, that each depend on several objects/properties in every invoice. And that these thousands of lines may just be discarded when something new arrives over the network, garbage collector trying to make sense of it, and new complex lines comes in to be made reactive. Perhaps it takes 0.05s and it is no problem. Perhaps it always works.

To just render everything again is usually no problem, very predictable, and rather easy to optimize if needed.

But I think like I did with AngularJS. Use the reactivity-system inside the components. But do not let the components, or the Vue Application for that matter, be made aware of everything. Give to it what it needs to do, to render everything and to allow for user input/edit where required.

A second thought…

I wrote a minesweeper game (test5) with the intention of abusing the reactivity system and see if performance got bad. It turned out I wrote a too good implementation, and the reactivity system worked perfectly. So I failed to prove my idea, but I learnt something on the way: that the reactivity system is better than I first thought – not the implementation in Vue but the idea, fundamentally.

My fear was that I essentially have two trees of objects

  • Data, nested data, deeply nested data, complicated data and separated data
  • UI, nested components, deeply nested components and separate components

My fear was that data consists of tens of thousands of reactive nodes, and each of them will trigger an update to hundreds or thousands of UI-components. However…

…in reality the data-tree will much resemble the ui-component-tree. Often there will be 1-to-1 relationships. This means that nothing will be updated in vain, and everything (and only that) which should be updated will be updated, typically each triggered by one or a few reactive “events”.

What would be wasteful?

  • If a single small component depends on a lot of spread out data – but that is already wasteful design because everything needs to be calculated every time – which is probably a bigger problem than the reactivity system
  • If the data tree is much larger than needed (for the current presentation). Lets assume we have a game with a few AI players. Each AI player is just presented as name, score and a few more fields. But the AI implementation may be several megabytes of complex data in memory. There is NO reason to make that data reactive out of laziness.

My basic design in AngularJS was:

  STATE ==> Presentation Data ==> Apply Filters ==> Apply Paging ==> Give to Angular

This means that the Presentation data is already structured quite much as the UI and its components, and it does not contain more data than necessary (or it does not have to, if it gives problems).

Disclaimer

I will be doing work based on this “reasearch” in the near future. I will update this post if I discover something relevant.

Apples Mac-lineup finally makes sense

It is great to see not only that M1 seems to be a fantastic chip, but also that Apple finally, after many years, seem to get their entire lineup in sensible order.

iPhone        A15
iPad Mini     A15
iPad Air            M1
iPad Pro            M1
MacBook Air         M1
MacBook Pro               M1Pro    M1Max
MacMini             M1
iMac                M1
MacStudio                          M1Max   M1Ultra
Mac Pro                                    ??????? ???????

I have intentionally omitted the 13 inch MacPro. I doubt we will see much more of it.

So we have all consumer models with M1 standard as only configuration. And the simplified way of understanding the pro models is:

  • M1
  • M1 Pro – “M1 2x”
  • M1 Max – “M1 4x”
  • M1 Ultra – “M1 8x”

The important thing here is that the standard M1 is powerful enough for most everything. It is when you do serious media editing, computations, gaming, or large development projects that a pro model make sense.

MacMini vs MacStudio

MacMini is for consumers, MacStudio is for professionals. I don’t know if we should expect or even ask for the M1 Pro in either of them. Different models of the M1 chip have different USB-port capabilities. I suspect an M1 Pro would be “wasted” in a MacMini, and would not be able to deliver the ports of a MacStudio. I think it is a nice thing that ports are consistent for different CPU models of MacMini and MacStudio. The MacStudio is expensive, but compared to historical Pro desktop macs, it is quite ok.

iMac

iMac is back where it started: an entry consumer model, with an M1. I think it makes much more sense than 27-inch iMac Pros.

MacBook Air

MacBook Air is both the consumer, most afforadable, and most portable laptop. I doubt we will see the consumer iBook back, in colors and everything, but why not?

MacBook Pro

When it comes to Pro laptops, USB-port options and heat becomes more important than for other models. The Ultra probably does not “fit”, and the M1 Pro model offers many advantages to the M1 standard here.

Mac Pro

My guess is that with MacStudio out, the demand for a MacPro is significantly reduced. I would not be surprised if it comes as a rack-mountable industrial Mac.

RAM, SSD and lack of expansion options

I have complained in the past about the lack of expansion options (replacing SSD in MacMini and MacBook for example) in modern macs. Currently M1 can be equiped with 8GB or 16GB of RAM. I think that is just fine for the consumer, working consumer or prosumer. The advantage of the close integration of CPU-RAM-GPU appears to be part of the M1-success, so there is no point in complaining about RAM.

I would have wanted to replace SSD-drives with time. It mostly disturbs me that I cannot repair a broken drive. But on the other hand I don’t know if they actually fail. I have not read that failing SSDs is a huge problem in Macs last years. Fast USB-ports essentially elimate the need for extra internal storage.

Gaming

It seems to me the MacStudio is the suitable gaming computer. How it compares to a similarly priced Windows PC I do not know.

Elemental Dice 1-4

Update 2022-08-09: I got a precision scale that gives me two decimals on the weight in grams. It turned out that my initial weights were rather good, essentially just rounding errors. Total weight of all 25 dice was 3.29 grams lower with the new scale, which gives an average error of ~0.12 grams, and the biggest error was 0.96g. When I obtain Elemental Dice 5 I will make a new post with more accurate weights.

I have received Elemental Dice 4, and will now make a post about all the 25 dice. I have previously posted about 1-3 and Silver. Lets start with a picture of all 25 (it is hard with light and reflections).

I have measured the density of all the dice on a kitchen scale with 1g precision.

EDAtomic WeightElementDens (g/cm)Dice Weight (g)Weight quoteActual Density (g/cm)Quote
46C2.2673.101.7175.62%
12Mg1.73874.031.7198.33%
13Al2.7114.072.6999.46%
22Ti4.5184.004.3997.66%
424Cr7.19283.896.8495.08%
26Fe7.874303.817.3293.02%
427Co8.9353.938.5496.01%
28Ni8.9353.938.5496.01%
29Cu8.96364.028.7998.09%
30Zi7.133253.506.1085.57%
439Y4.47173.804.1592.85%
440Zr6.49264.016.3597.81%
441Nb8.57333.858.0694.01%
442Mo10.2403.929.7795.74%
45Rh14.4352.438.5459.34%Plated
46Pd11.9352.948.5471.81%Plated
X47Ag10.49413.9110.0195.42%
448Cd8.7333.798.0692.61%
50Sn7.31293.977.0896.85%
464Gd7.9313.927.5795.80%
74W19.3773.9918.8097.40%
78Pt21.45341.598.3038.70%Plated
79Au19.25351.828.5444.39%Plated
482Pb11.29433.8110.5092.99%
83Bi9.78383.899.2894.86%

A “4” in the first column is that they are new for the Elemental Dice 4 series and not included in my previous article. Densities seem quite fine, most of them well above 90% (which means I have no imminent reason to think the dice are not what they say they are). Carbon (C) has a lower density than expected (for graphite) but Carbon is not a metal and it makes sense to me that manufacturing method affects the atomic configuration.

The box states “pure elements can change color over time as the result of long term air chemical reactions with the […] air”. I sorted them from darkest to lightest and took a picture:

10 dice, sorted by shade of grey

This is difficult. Pb is more blue/cold. Cr is very shiny. Gd & Y changes position depending on light and perspective. But it gives you a hint.

Fe, Co, Ni (26,27,28) are all magnetic, as is Gd. The plated dice are slightly magnetic due to the material in the core, not the plating.

Elemental Dice Silver vs Silver

I wrote a post about my Elemental Dice a little while ago and the Silver dice got an entire section for themselves. I had owned the plated one longer and it had been in the aluminium stand. This is what they used to look like:

Plated silver to the left, severely oxidized after months, solid silver to the right, somewhat oxidized.

So, my guess was that the aluminium stand did something bad to the silver.

Since then the solid silver has been standing in the “faux leather dice roll mat” (available in E.D.2) and the plated silver has been standing in the aluminium stand. Now, a month and a half later I found that if any of them had any miscoloration it was the solid one, on the 6th face, that had been exposed to the faux leather.

I washed them both carefully in warm water and manual dish washer (which typically is used for utensils of metal), and took a few photos (with my new TX-158 “microscope”):

Solid Silver
Plated Silver

What you can clearly see here is that the solid one is laser engraved leaving the letters matte. The plated one is plated after the laser engraving, so also the letters are shiny. You can see this with your eye if you just look at them so this is an easy way to tell them apart (you can also determine that the solid one is a bit heavier, but it is not so obvious when you have them in your hand).

I took another picture of both of them at the same time.

Solid silver to the left, plated to the right

You can very clearly see that the inside of the “g” shines on the plated one and is matte with the solid.

But I also now see that more things are different. The plated one has had a thin layer of silver added afterwards, and that silver seems to have attached in a naturally shiny (almost liquid) way. The solid die on the other hand seems to have been polished to be shiny, leaving a very fine brushed surface.

To the naked eye, they also do not look exactly the same. The solid one appears to be more grayish and the plated one more warm yellow and perhaps even more shiny. If this is a matter of different age (time in the poluted air), different surface structure, or slightly different silver alloys I can not tell. Also the solid one seems to be blackish on 6th face.

Here is a picture of the 6th face of both dice. The solid die, to the right, has some black stains, and I suppose that is silver oxide (left one has been 45 days in aluminium stand, right one has been 45 days on faux leather).

Plated silver to the left, solid silver to the right.

But for now, it seems I was wrong about the aluminium oxidizing silver. I washed them today and I will put them back as they were, solid on faux leather and plated in the aluminium stand.

Technaxx TX-158 Microscope Review

I just got this idea that I want a Microscope. There are very many to choose from, and the prices vary much as well. I have no professional or real need of a Microscope, I am just a nerd. One thing I wanted to do is to have a close look at my Elemental Dice.

When I was quite young I had a childrens microscope that was 100x, 200x, 300x magnification. It was not so easy to use, and obviously it was not capable of capturing digital pictures. After doing some research I decided to buy a very simple cheap USB/Wifi microscope, knowing that it would probably not be so amazing.

Technaxx TX-158 basics according to marketing:

  • Live view for PC or smartphone (so I can use my iPad as a screen)
  • Photo/Video (I just care about photo)
  • With a stand
  • LED illumination
  • Magnification up to 1000x (as I see it, it is max 40x magnificaiton, see below)
  • Full HD resolution

This is mostly true. What is absolutely not true is 1000x magnification. The stand is on the cheap (light, flappy) side. The pictures are 1920×1080 and then the question is: are they that sharp? You will see for yourself below. All pictures below are straight from the TX-158, no editing.

Basic usage and features

It is easy to get started (with iOS, only thing I tried).

  1. Charge it using USB (cable but no power supply included)
  2. Download the iWeiCamera App from Apple App Store.
  3. Turn TX-158 on.
  4. Connect your iOS device to the unencrypted WiFi network called Cam-something
  5. Start iWeiCamera
  6. Use the wheel on TX-158 to focus
  7. Use the button in the App or on TX-158 to take a picture.

That is kind of it. You export the pictures from the iWeiCamera to Photos (in iOS), and then send them to your Mac with AirDrop (or something else you find convenient).

Optical Capability

TX-158 has 8 LED lights that can be adjusted (pressing the on-button repeatedly). This is convenient. It also has a transparant plastic shell around the lens. I have found that the shortest possible focal depth is “kind of” the distance you get if you place TX-158 on a surface. You may be able to focus on something that is slightly closer, but not much. If a small coin fits inside the plastics shell you are probably fine. My 16mm dice also fit inside, that does not work.

You may however photograph items more far away. This picture of a 16mm metal die is taken (horizontally) from almost 10cm (click the image to open the full resolution).

The noise around/behind the die looks a bit strange, but it is probably reasonable given how I mounted the die between white postit notes. If I open this picture on my computer display the object is about 16cm large (with no digital zoom). The actual object is 16mm, so to me this is about 10x magnification.

I then moved the die as close as possible and focused on “13” in the top left corner.

I would say this picture is about 4x more magnified than the previous one (just measuring the height of “13”.). Compared to the real object I would say we have about 30-40 times magnification. Anything “more” than that is just digital zoom, and I do not think the picture quality allows for much digital zoom.

Zoom & Focus

The box that comes with TX-158 states on the backside: “Up to 1000x magnification / Magnification adjustable with turning wheel”. In the little booklet however I read: “Zooming: turn the focus wheel until you reach the personal best view option”. So it is a focus wheel and the marketing about “adjustable magnification” is a lie. The good thing is that it is obviously a “fixed” or “prime” lens which is better for image quality than a zoom lens. Adjusting magnification is easy (within 10-40x something) by simply moving the TX-158 closer or more far away from the object. But when the object gets too close to the lens it can not focus anymore.

The little booklet also mentions Autofocus. I am not 100% sure, but I don’t think it has any autofocus.

More pictures

All the below pictures are taken by simply placing the TX-158 on top of whatever I photograph and manually adjusting the focus.

Dust on a plastic surface
The surface of a worn Teflon or Ceramic frying pan

An oiled wooden table

One of my hairs
Worn wooden surface
A leaf, cut off from a pineapple (stainless surface at top of picture)
A blanket made of wool
Fake/faux leather
A piece of dirt – wax from a cheese probably – on a stainless surface
A piece of linen cloth
The text TECHNAXX, on the image of TX-158 printed on the box it came in
Pineapple
3cm mark on an aluminium ruler (the lines to the right are mm lines)
A drop of honey on what I thought was a black metal surface (the 8 LED lights reflect in the drop)
An iPhone connector
Tip of a knife
Grains of salt in a blue porceline bowl
A safety match
Letters svERige on a coin

Conclusion

After having played with an analog childrens microscope at 100-300x when I was little, I kind of hesitate to call the TX-158 a microscope at all. To me it is more a macro-photo-camera.

When you get to “real” 300x magnification you can start seing things that this device do not at all reveal. I would say it is 40x magnification (and then I am quite generous), but perhaps that is the wrong way to measure it.

The practical thing is that 40x is not THAT much, so it is quite easy to move around the TX-158, find your object and adjust the location of things manually. For a higher magnification you probably need a much more stable stand, and being able to move the microscope or the sample in a controlled way. TX-158 is more point and shoot.

Anyway, when you read about different microscopes for sale on Amazon and other places, if it mentions magnification in the range of 1000x, just do not trust it. I doubt any real microscope can be 100-1000x magnification or anything like that.

The iWeiCamera-App is very rudimentary. Copying images from the App to Photos gives me a message in Chineese. But connecting the iPad via WiFi and getting started is very simple.

I guess for soldering work or other very delicate work, it is a useful digital magnification glass. Then the stand probably more comes to its right too.

Qnap, SonarQube and Elastic Search

Update 2021-10-20: Solution in the end of the post

I use SonarQube (and SonarScanner) to analyze my JavaScript source code in a project that has almost 200k lines of code.

SonarQube is a non-trivial install and it should be on a server so different developers can access it. Thus, SonarQube is an application that it would make sense to put in a packaged container, easy to set up.

I have a QNAP, with Container Station installed. That allows me to run Docker images and Linux (LXC/LXD) image. To me, this sounds like a perfect match: Just install a SonarQube Docker container on the QNAP and be happy!

Well, that was not how they thought it.

Last time I checked the SonarQube docker image did not come with a database. That would have been the entire point! Most work related to setting up SonarQube is related to the database. Docker support data folders, so it would be easy to configure the docker container with a single datafolder for the database and everything. No. You need two docker images.

The next problem is that SonarQube comes bundled with ElasticSearch which has some remarkable system requirements. Your operating system needs to be configured to support

  • 65535 open file descriptors (link)
  • 262144 vm.max_map_count (link)

Now the first problem is that Docker in QNAP does not support this. However it works with LXC.
The second problem is that QNAP is getting rid of LXC in favour of LXD, but you cant have 65535 open file descriptors with LXD (on QNAP – hopefully they fix it). So I am stuck with unsupported LXC.

But the real problem is – who the f**k at Elastic Search thought these were reasonable requirements?

I understand that if you have hundreds of programmers working on tens of millions of code you need a powerful server. And perhaps at some point the values above make sense. But that these are minimum requirements to just START ElasticSearch? How f***ing arrogant can you be to expect people to modify /etc/security and kernel control parameters to run an in-memory database as a priviliged user?

The above numbers seem absolutely arbitrary (I see that it is 2^16-1 of course). How can 65535 file descriptors be kind of fine, if 32000 are not? Or 1000? I understand if you need to scale enormously. But before you need to scale to enormous amounts of data, it would be absolutely wasteful, stupid and complicated to open 50k+ files at the same time. And if 32000 file descriptors are not enough for your clients big data, how long are you going to be fine with 65535? For a few more weeks?

This is arrogant, rotten, low-quality engineering (and I will change my mind and apologize if anyone can provide a reasonable answer).

All the data SonarQube of goes to a regular database. ElasticSearch is just some kind of report-processing thing serving the frontend. I did a backup of mine today, a simple pg_dump that produces an INSERT line in a text file for every database entry. Not very optimized. My database was 36Mb. So if Elastic Search would use just 36000 file descriptors, each file correspond to 1k of actual data.

I don’t know if I am the most disappointed with the idiots at ElasticSearch, or the idiots of SonarQube who made their quite ordinary looking GUI dependent on this tyrannosaurus of a dependence.

Hopefully the QNAP people can raise the limits to ridiculous values, so nobody at ElasticSearch needs to write sensible code.

And if anyone knows a hack so you can make ElasticSearch start with lower values (at my own risk), please let me know!

Solution!

QNAP support helped me with the perhaps obvious solution. Log in as admin with ssh to the QNAP and run:

[~] # sysctl -w vm.max_map_count=262144
[~] # lx config set deb11-sonarqube limits.kernel.nofile 65535

The first command I already knew. You have to run it whenever the QNAP has restarted.

The second command is for setting the file limit in the particular container (deb11-sonarqube is the name of my container). I guess you just need to do it once (and then restart the container), and that the setting remains.

Pendragon Houserules for Battles

This is a draft!

There are numerous battle systems for Pendragon. Version 5.2 of the standard rules includes a battle system, as well as book of battles. I find the standard rules in 5.2 unsatisfying:

  • they are rather complex, and despite that
  • it does not feel that they are reasonably good att deciding the outcome of the battle (number of soldiers, types of soldiers, level of training and such fundamental things have vague implications)
  • the Army/Battallion/Unit/Personal/Special-event layers are simply too many layers of rules and events, with too little connection between them
  • the Personal mode is still not “in character roleplaying” but some rather abstract melee resolution

I consider Pendragon a roleplaying game. I don’t want it to be a tactical Battle-game (so the Book of Battles is out). What I am looking for in a Battle game is:

  • Plausible, simple, battle resolution – in case winner and loser need to be determined and something is at stake for the players
  • An personal battle experience for the player characters

When I write plausible, I mean that Gamemaster and Players should be able to envision the battle in a theater of mind, and what happens should not be unreasonable or ridiculous. We can ask ourselves questions like:

  • would 10 peasants be able to through a knight off his horse and beat him to death?
  • can you charge through a little river, and with what disadvantage?
  • are a bunch of well equiped peasants going to have any chance against poor knights?

My idea is that the answers to such questions should be decided in a whay that both Gamemaster and players think it is reasonable.

Fundamentals

For most not too large battles, both sides just make up one Battalion each (this is not the way Battalion is used in the rules, and it is probably not historically correct either).

For very large battles, it is fine to let both sides consist of several battalions. The battalions will resolve their battle like separate battles. It is possible in the middle of the battles to evaluate the situation, reorganize (perhaps merge remaining forces) and start over.

Such a battle between two battalions is not divided any further. It is a battle. However, there is a Personal level for the player characters.

The battle is divided in Battle Turns (typically 30 minutes) and between each Battle Turn there is a Personal Turn for resolving what player characters experience. The Player Turn is typically divided into normal combat rounds when needed. If the player characters are in the front line, charging, start the battle with a Personal Turn.

Battle Level

Both battalions are assigned a Battle Value (typically 10). The battle is then resolved as turns of opposed checks against the Battle Values. Each turn will result in losses, and eventually one battalion will be more or less defeated.

Units and Damage

In order to keep track of losses, it is decided how many Units each battalion consists of (can lose). Starting with the smaller force, assume it consists of 5 units, and decide how many participants are in each unit. Then do the math and figure out how many units the larger force consists of if the units are roughly equally big. For a shorter battle, start with 3 or 4 instead.

Each unit can be lost two times

  1. The unit is withdrawing, has suffered some losses, and can not participate in offensive fighting
  2. The unit is fleeing, has suffered significant losses, and can not participate in any fight

What this means is that a Battalion of 4 units can take at most 3 points of damage, and still keep attacking. At 4 to 7 damage, the Battalion can defend itself if the enemy keeps attacking. At 8 damage there is no organised battalion left, the battle rules are not used any more, and if the attacker wants to chase imprison or kill everyone that is a different business.

This means that a battle can often end in an inconclusive result (as in the standard rules), when no side is defeated and no side is capable of attacking.

Resolving the opposed check of Battle Values

The opposed check of Battle Values for the turn (typically rolled by the Battalion commanders) is resolved like this:

Success Tie0 damage on both sides
Success vs PartialWinner decides if there will be 2-1 damage, or 1-0 damage
Success vs Failure2 damage to loser
Failure Tie1 damage to both sides
CriticalAs success, and Battle Value +1 (to maximum 18, otherwise one extra damage)
FumbleAs failure, and Battle Value -1 (to minimum of 3, otherwise one extra damage)

Deciding Battle Values

Battle Value and Unit Count are essentially what decides the odds of the battle. Both Battalions have a Battle Value of 10, plus or minus the sum of their advantages and disadvantages decided below.

A smaller advantage gives the Battalion with the upper hand +1 Battle Value.
A major advantage gives the Battalions +1 and -1 Battle Value respectively.
No significant advantage gives no modifications.

A major advantage (+1/-1) generally requires that all the troops on one side has the advantage over all the troops on the other side.

Standard possible advantages are:

  • Better trained troops
  • Better weapons
  • Better armors
  • More horses (double effect first round)
  • Ranged weapons (only effective first round)
  • More rested
  • Better organization, discipline, motivation, and leadership (not the battalion leader leader)
  • Terrain advantage
  • Ambush
  • Defensive measurements

Both battalion leaders also roll a Battle check where Critical: +2, Success +1, Failure -1, Fumble -2. This modification should be given some in-game explanation, and may be removed/rerolled later in the battle if conditions have changed.

If any side gets more than 18 Battle Value, set it to 18 and compensate with not counting the first hit.

If any side has a very diverse army (like 50 knights and 1000 unequiped peasants), use the guidelines above and make sure everyone kind of agrees on the Battle Value. An alternative is of course to divide the army and make more than one battle. The important thing is that the story makes sense, and that the rules dont create implausable odds and outcomes.

Personal Level

For the player characters, the battle is roleplayed. It is not an abstract melee as in the standard rules, but the normal combat rules that are used. First a reflection: A battle may last for 1-2h or longer. If both sides are roughly the same size, and some participants die, some are wounded and some are quite fine after the battle, it means that most participants do not kill a single opponent in hours of battle. Otherwise the battle would be over in a few minutes. Roleplaying 2h of in-game-battle, stardard combat round for round, would take days and nobody would survive. So I think we need to agree that most of the time, player characters involved in a battle are:

  • Looking for their friends, unit or horse
  • Taking care of someone elses wounds
  • Helping someone else off the battlefield
  • Guarding an ally who is wounded and perhaps attended
  • Taking a breath
  • Considering where are we going to run/charge next
  • Discussing tactics or passing on information
  • Enemies evaluating each other without engaging
  • Move to different part of battlefield

I would assume that things going well, you and your unit are able to pick and engage enemies that you can defeat. Things not going so well, enemies are probably assaulting you in large numbers possibly from behind.

For the personal level, normally assume that all the player characters are included in a unit (as in the standard rules) with a unit leader. This is not one of the Hit Point-units. Keep some kind of normal roleplaying record of who is in the unit, how many they are, and what has happened. The participants of the unit are expected to follow their leader and to care for each other.

Each Personal Turn calculate a Tactical Value. It is based on two things:

  1. The opposed Battle Value roll above
  2. The current unit leader (may be a player character) making a Battle skill opposed roll against a Battle skill of an enemy leader (if the enemy is disorganised, use 5, if in doubt use 15)

Interpret those two opposed rolls using the next table, and add the results (to a value 0 to 10).

Fumble0
Fail1
Partial Fail2
Partial Success3
Success / Tie4
Critical5

In the below table, see what the unit can be doing. If there are multiple options the Unit leader chooses. It is possible to choose from a worse (lower) result if it makes sense.

0Surrounded and engaged by twice as many foes as unit size, no chance of escape
Surrender/Taken as prisoner (if enemy takes prisoners)
1Engaged by stronger enemies
2Engaged by equal enemies
3Can just lay low (no glory for this turn)
4Can withdraw
5Can get into combat with enemy unit of equal strength
6Can do first aid or watch over someone
7Can engage an enemy unit, having the upper hand
Can attempt to find a horse
8Can take a prisoner
Can engage enemy unit leader with bodyguards
Rescue attempt of allied prisoner
9Good assault or assasination opportunity on enemy unit or unit leader
Can engage enemy high commander with bodyguards
10Good assault or assasination opportunity on enemy high commander

Options are to be interpreted by the Gamemaster and other opportunities or threats may be possible.

Gamemaser can decide that the Player events may result in a -1 or +1 modification to the Battle Value, for one or more Turn. Killing or taking as prisoner a high commander may have even bigger effect.

Charge

If the players are in the front line, the first Turn is resolved as a charge. Roll an opposed Unit Battle check as above. What typically happens is:

First (if enemy ranged weapons)Second (lance charge)Third (melee)
Fumble1d6 arrowsLost opportunityEngaged by strong enemies
Fail1d3 arrowsStrong enemiesString enemies
Partial F1d2 arrowsEqual enemiesEqual enemies
Partial S1 arrowWeaker enemiesWeaker enemies
SuccessChoose enemy typeChoose enemy type
CriticalChoose enemy type, +5 first roundChoose enemy type, +5 first round

Glory

Glory is decided as in the standard rules, for each turn of the battle, at GMs discretion.

Passion

The players can get Passion during the Player Turn as during normal. The Passion may last for more than one turn, if there is a continuity of action. A turn without combat typically cancels the Passion.

Simulation

What good is a battle system if it fails to produce likely outcomes? I programmed a simulator (link) to verify the likelyhood of outcomes. Everything about this battle system is quite subjective. It is meant to produce plausible outcomes with plausible probabilities so the result of the battle can be accepted in the story.

Pendragon Houserules for Jousting

This is a draft. House rules are not tested much.

This article applies to Pendragon 5.2. The rules are useful with any version.

We ran a small jousting tournament the other day, using the standard 5.2 rules. We soon found that the rules were not good enough, and we did some quick in-game house-rules. My main objections are:

  • A partial success (success, but still not as good as your opponent) makes no difference.
  • The horsemanship roll to save from Knockdown is far too easy. Jousting can go on for (too) many rounds.

The truth is that I have no idea for how long real knights were jousing. 1 pass? 5 passes? All afternoon? But I do not care – I and my players have seen Ivanhoe – we have an idea what we expect, and we want it to be quick.

Suggested House Rules

The suggested house rules are not that different from the orginal 5.2 rules. Both knights roll opposed Lance checks.

OriginalHouse rule
Both fail/fumbleTieTie
FumbleGM decidesSee table below
Same success (or both crit)TieBoth falls off
Winner vs Fail/fumbleDamage and Horsemanship rollsLoser falls
Winner vs PartialDamage and Horsemanship rollsIf difference in success is
1-4: Damage and Horsemanship rolls
5+: Loser falls
CriticalReal damage and Horsemanship rollsDeal real damage, Loser falls

This should avoid too many passes/rounds.

Type of Win

Here is a random table to decide what the victory looked like, in case anyone is curious. This is for dramatic effect. If it is a real battle no one should be penalized by this table.

  1. Hit to head, helmet removed, dizzy for a while
  2. Loser stays on for for a dozen feet but can not hold it
  3. Hit to head, rolling backwards over horse
  4. Shoulder hit sends loser spinning off the horse
  5. Loser thrown off, lands on back with a noise
  6. Loser falls off backwards, manages to land on feet
  7. Loser seems to make ut, but lance hits ground and he falls of
  8. Loser is left dangling to the side of the horse, can’t get up or down
  9. Losers horse made a weak rush, making him an easy target
  10. Loser hits shield, then ground and is pole jumping off his horse
  11. A corner of the shield comes off
  12. Hit to head, on his back on the horse, then rolling off
  13. Hit to head, dizzy for a few moments, fails to stay on the horse an falls off moments later
  14. About to be hit in neck, evades, fails to stay on the horse
  15. Loser delivers a solid shield hit, but it is him losing the balance
  16. Loser is pulled down by his shield (being hit by the lance)
  17. Loser lifts shield to protect from head head, gets shield in the head
  18. Tries to dodge a head hit, taking hit to upper torso
  19. Hit to shield is just too powerful to recover from
  20. Tries to dodge sideways, falls off doing so
  21. Comes off rolling into the middle fence, comes to sudden stop
  22. Shield hit, lance slides hitting the lance arm, pulling the knight off
  23. Light hit to side of head, enough to lose all balance
  24. A rare lance-lance hit sends knight off spinning
  25. Loser, sitting high, manages to get lance under him, ejected out of saddle
  26. Violently thrown off, helmet comes off, face buried in mud
  27. When about to recover from impact, thrown off by horse
  28. Rider and horse falls by the force of the impact
  29. Falls off, landing on the fence, not pretty
  30. Looking bad, landing on head, but rolls up nicely finishing on his feet
  31. Breaks lance when landing on it. Score?
  32. Ridiculously flapping with arms, throwing shields and lance, for no gain
  33. Never taking determined eyes off opponent, until afoot again
  34. Both horse and knight falls backwards
  35. Losing breath, taking a few minutes to recover
  36. Hit by horse kick when falling off
  37. Pushed backwards by impact, falling off behind horse
  38. Shield hits face with some blood spilled
  39. Horse comes back quickly, licking his master in the face to get him up again
  40. Horse comes back quickly, kneels down, and helps knight to his feet
  41. Horse runs away
  42. Crashes into the mud on opponents side of the fence
  43. Seems confident for a while, then just falls off
  44. After impact, horse makes a few jumps, throws knight off forward
  45. Pushed out of saddle by impact, tries to recover sitting on the rear of the horse, but fails
  46. Hit to head, leans numbly forward for a little while, then falls off
  47. Saddle comes off, knight has no chance
  48. Clings to the mane of the horse to get back up, but has to surrender afoot
  49. Gets splinters in face and eyes, takes a while before walking off the field
  50. Knight gracefully slides sideways out of saddle, ending up on knees and hands
  51. …you are welcome to suggest more…

Fumble

Fumble is 1/20. For two knights that is almost 1/10. I think that is way to often for some kind of critical or disqualifying event. So this table is somewhat forgiving.

  1. Hit opponents horse, dealing normal damage. Disqualified
  2. Horse tries to get rid of rider, Horsemanship or fall off before impact
  3. Blinded (by dust, sun), and makes no proper attack attempt
  4. Horse tries to run off in another direction (roll horsemanship or disqualified)
  5. Too voilent charge, can not direct attack at all
  6. Lowers lance way too late
  7. Lowers lance way too early
  8. Horse stops suddenly, just before impact (horsemanship or fall off forward)
  9. About to hit opponents horse, throws lance on ground to save
  10. Cracked lance, not even an attempt
  11. Hesitating start, no power, easy target
  12. Lose grip of lance, trying to recover as it hits the ground (DEX or fall off)
  13. … you are welcome to suggest more…

Elemental Dice 1 – 3

There has been some Kickstarter projects under the name Elemental Dice. Backers get dice made of “pure” elements, well as pure as possible. When it comes to very valuable elements (like gold) the dice are just plated with pure gold.

The first 3 Elemental Dice projects contained 15 different elements:

I decided to weight them and present some stats:

Atomic
Number
ElementDensity
Real (g/cm)
Dice Weight (g)Density
Actual (g/cm)
Quote
12Mg1.73871.7198.33%
13Al2.7112.6999.46%
22Ti4.5184.3997.66%
26Fe7.874307.3293.02%
28Ni8.9358.5496.01%
29Cu8.96368.7998.09%
30Zi7.133256.1085.57%
45Rh14.4358.5459.34%Plated
46Pd11.9358.5471.81%Plated
47Ag10.494110.0195.42%
50Sn7.31297.0896.85%
74W19.37718.8097.40%
78Pt21.45348.3038.70%Plated
39Au19.25358.5444.39%Plated
83Bi9.78389.2894.86%

The side of the dice are 16mm. But there are cavities and roundings so their actual volume is slightly smaller.

The plated dice all weight 34-35g, and they probably have the same interior. Their weight is rather uninteresting.

When it comes to the “as pure as possible dice” most of them are more or less within the error margin of my 1g resolution scale. Iron (Fe) seems to be an alloy with something lighter and Zink (Zi) even more so.

As expected, Nickel (Ni) and Iron (Fe) seems to be magnetic.

Silver

2021-10-14: I wrote separate post about the two silver dice and questioned some of below conclusions.


Silver is a noble metal, but everyone who has owned silverware knows that it gets blackish after a while. After a while I had the feeling that my silver dice were the ones that had deteriorated the most since I received them. I happen to own silver dice: one solid and one that is just plated.

Today someone who should know told me: pure silver does not oxidize like that in air. I had a closer look at them, and decided to take a photo:

This has obviously been a gradual process. The one to the left is the oldest die and is plated. The left die actually is that much darker on its 6th face. Since they are next to each other you can see it is just not a light reflection phenomena. The dark corner on the right dice IS the left die being reflected though.

As you may be aware of, the 6th face is opposite to the AG-face. I have kept my Elemental Dice in the aluminium stands, with the 6th face downwards, in contact with the aluminium. As you can see on the 3rd face, the stain/oxidization is triangular, being larger on the side that has been more down in the aluminium stand. And on the 2nd face, you can see kind of a line where the dice has touched the aluminium.

I feel quite confident that there is a reaction between Al and Ag, and that the silver dice (or silver in general) should not be in contact with Aluminium at all.
Not so sure about this any more, see separate post liked above.

Also, the little “holes” in the left (non-solid) die have turned yellowish. I don’t think is an optical phenomena because it has not happend (yet) to the solid silver dice, and there is nothing yellowish about Pt, Pa, Rh.

I am considering to paint my Aluminium stands with clear nail polish. Any other ideas?

Cleaning it!

There is a very simple way of removing the tarnish: link. It just requires sodium bicarbonate and some aluminium foil. The result is amazing, and it is fun do to chemistry in your own kitchen! Basically the Aluminium metal is sacrificed (oxidized) to restore the Silver atoms from Silver Oxide (and perhaps Silver Sulphide) to metal form.

Wishlist

There is a new set of Elemental Dice 4 with 10 new dice coming. The most missed ones after that would be:

  • Gallium – with a melting point of 29C it poses some practical problems, but including a mold for it would be cool
  • Uranium (depleted) – export restrictions and perhaps someone clever can turn U238 into Pu239