Ossa Sepia

It started, as usual, with players’ activity, this time automated bots and desire to gain access to such, payment concerns and the available avenues to reward useful effort. The conversation got longer than usual and spanning a couple of days, too, but perhaps the snippet below is the best introduction here, since it is quite part of what triggered this publishing of my key now rather than at a later time – if he’s going to play with Vamp on the keys side, might as well give him something specific to play with/against, right?

While the client for Eulora 2 handles fully automatically the whole business of RSA keys and thus uniquely recognized identities, while the environment provides support for a Web of Trust (WoT) as well, the latest activity by players pushed suddenly quite strongly forward the private interactions and even rsa-backed contracts that people might want to have with one another. And since I am best placed to know exactly what is available, how it works and how it might serve this purpose, here’s my public euloran key made specifically for player to player interaction ¹:

my player’s public key in Eulora 2

Simply download the above file, run your copy of vamp to unhex it and then use the result with Vamp as you would any other public key. If you publish or send over in Eulora 2 your key as well, we can try a full back and forth communication out.

Should add here that this is simply a public RSA key like any other – only plainly rather than opaquely stored and passed around. So to the extent that you can extract the actual RSA key out of whatever other software you happen to use ², you can then in principle use that just as well with vamp ³, it doesn’t care.

1. This may or may not be the same public key that I use for my euloran identity. Note that within Eulora 2 itself, the server is the central authority with which everyone has to authenticate and maintain the unbroken authenticated communication in order to appear in game as the respective character that they are handling. So within the game, if any X says something, it is indeed rsa-authenticated X saying that something – at least as long and to the extent that you trust the server of the game, indeed.[↩]
2. Kleopatra most likely if you are on windows, gpg on linux but in either case, attempting to extract *just the key* is a good exercise to see for yourself just how little access to the actual controls the user is supposed to ever have. You know, one of those basic, repeatedly and respectfully cited everywhere Kerckhoffs’s principles, yes? [↩]
3. For completeness, the euloran RSA keys limit the length of the public exponent e, hence that trail of zeroes in the file above.[↩]

~ This continues the Euloran Kronikle I ~

At Preposterously Prosperous Place

In the infinite land of Eulora 2, one can easily get lost if relying solely on the landscape for clues. As one player promptly found out when going to where the others should have been, only to be welcomed by an entirely empty space with no PCs nor NPCs in sight- is this part of the world the one I wanted, the one I needed or merely the one I happen to have stumbled in by accident, when going on auto-pilot and just looking away from the keyboard for a while? Luckily, the chat works from any and all places in and even out of the euloran world, so one doesn’t have to either wonder forever alone or indeed hope for no help at all. All it takes is to tell others of one’s trouble and there’s a good chance to receive some guidance towards finding one’s own way back:

As a wider benefit of both misadventure and telling others about it, the situation finally gave a good reason for the euloran world to give names to places – names that people can refer to, so that they can find their own way around and even tell others where they are, with some reasonable degree of confidence that they might even be talking indeed about the same place! So the world changed indeed and places got named, with the growing settlement where it all started finding itself in the very middle of Preposterously Prosperous Place (or PPP, for short). Some known places around seem to include at the moment the Limitless Ditch of Intoxication, the Cruel Mound of Pluck, the Secluded Course of Verve, the Goatish Hill of Destiny and the Saturnine Lane of Destiny:

As for the explorer, all ended quite well for him too, as he got back to PPP and even found that, getting lost can really truly pay in all sorts of ways, when one is finally not lost anymore:

Life and Death Get Vitals Moving

As PCs and NPCs truly got moving around the infinite lands, the very vitals of each of them also started moving – if in a more limited sense between the usual percentage values of 0 and 100 but decidedly up and down, as everyone noticed. Just as some vitals replenish with rest when at least enough food is had, others seem to drain with it. And then, one day, two of the oldest characters around were not quite that closely around anymore as the towncrier provided their epitaphs that gave perhaps some indication as to what could have done it for them only it didn’t, as well as what actually did it, indeed:

As it turns out, one truly died of too effective ineffectualness, you know? This game might really be noticing something there…

An NPC’s Tease

While the best known NPCs are staying in town and providing services to everyone, there’s a growing number of less known NPCs that are busy with their own trials and tribulations in the vast lands of Eulora 2. One of those seems to have set up, whether intentionally or not, quite the tease for any player:

Despite being thus publicly exposed as the author of the previously unexplained phenomenon of apparently exploding amounts of bags appearing in place, he seems to be still at it. More recent reports suggest he can still be found by the trail he leaves behind:

Merchant Dips Hands in Banking

The official merchant in Eulora 2, the one and only Rainer Tracksnarl recently dipped his hands in banking as well, to further improve the service he provides for his customers. Happily for eulorans everywhere, the official merchant’s hands are quite clean indeed, so that this dipping of his comes at no extra cost, while bringing the wanted benefit of being finally able to exchange between the many denominations of the euloran coin, the ECu. Players being human though, they quickly found, of course, that there is always more that they could want:

One Towncrier Gets Busy: Daily Rankings and Other Notices

It all started – again! – with active players talking of what they did, where they are, what they found and what they think of it. As it happened before with the naming of places, it is the players’ own activity that pushes for some concrete improvement or addition – and in this case, it was the leadership boards that came out of this:

Less than a week later, everything was done and in place, so that the towncrier got quite busy indeed, with a brand new Notices and Announcement board that he is in charge of. So the towncrier is happily busy now, announcing all rankings as they get calculated and even pointing out the juiciest news in the more general, public chatroom:

Better to CLI than to Click: the Stacking Experience

While NPCs benefit from Rainer Tracksnarl’s automated methods for tidying their inventory as they go, human players have had to do it manually until now. As activity increases though, the number of items grows as well and one might find (to their surprise or not) that clicking to move items about may be “very intuitive” but it quickly starts being rather too annoying, as well:

As before, increased activity of the industrious and helpful kind also pushes for increased support from Eulora 2, so players got an improved bot command line so that the full stacking can take as little as one short line in the Console regardless of how many items there are that need moving. Alternatively, it can still take, of course, twice as many clicks as there are items to move, if one sticks to point-and-click rather than learning to use the command line. I’d say it’s far better for you to CLI than to Click but you are certainly free to take as long as you wish to find this out, there’s no rush at all:

What Comes Next?

This one really and truly depends on players’ activity. As for the Kronikle, this part is easiest of them all – what comes next after this II is going to be III! When it will come out and whether it will still be manually compiled by me like these first two or not and what exactly it will contain and reveal from the euloran world is yet an open matter.

WoT ¹ ratings are supposedly a shorthand themselves – just plain, integer numbers between -10 and +10, with every value meant to stand for something. For what, exactly? Well, given how few they are and how diverse the situations can be, the only possible answer is that it… depends and mostly on the rater, really. More to the point, these rating values can be used and assigned in any way one wants but are generally assumed to reflect to some extent at least, the degree to which one trusts one’s own knowledge and understanding of specific others, as they are met and interacted with.

But people being people, plain numbers as shorthand never really work as well as words where any meaning is intended. Hence, in practice, any consistent and systematic approach to actually using WoT ratings ends up quite quickly with at least one, possibly several word-based shorthand schemas for the ratings themselves. And while no such schema can ever be somehow “the one” or definitive or whatever else of this sort, there is perhaps something to be gained at least from making public a first such schema – as an example or maybe even just as a first attempt perhaps, if nothing else.

As to how this first schema even came to be – in Eulora 2, WoT ratings are used not just by players as they see fit but by the NPCs and generally by the game itself. Hence, there was the need for at least one specific schema that the code can rely on to give and interpret at the very least its own ratings – though possibly as well those of others in contexts where it is meant to interpret them. And it turned out in fact quite fun to attempt a consistent approach in finding meaningful shorthand names for all those rating values! So here is the current result, with negative values simply adding a “mis” prefix in front of the same word to mark the mis-alignment between rater and ratee:

• 0 remembered (no negative here, it’s the one rating stating that one has interacted with this person and they want to keep this marked but they prefer not to give either a negative or a positive rating – hence, the rated person is simply remembered)
• 1 contacted, -1 miscontacted
• 2 acquainted, -2 misaquainted
• 3 perceived, -3 misperceived
• 4 encountered, -4 misencountered
• 5 believed, -5 misbelieved
• 6 known, -6 misknown
• 7 trusted, -7 mistrusted
• 8 respected, -8 misrespected
• 9 admired, -9 misadmired
• 10 fated (the main meaning of “fated” that I am using here is that of “determined” as in unchangeable in fact because this is pretty much what I see a 10/-10 rating validly standing for – the ratee is clearly and fully determined now as in the future, whether this is for instance because they are a known deterministic code bot or perhaps simply dead and thus not further able to either act or change at all, in any way), -10 misfated ².

This is all, the first known public shorthand schema for WoT ratings, feel free to agree, disagree or even just argue with it, whether quietly on your own or more wordy in company, in the comments section below.

1. Web of Trust, see what it is for, how it works and how to use it.[↩]
2. According to the Oxford dictionary, the word “misfated” is “obsolete” and “last recorded around 1600s.” So I suppose I’m reviving words here, even if I didn’t set out to do this on purpose. I’m not even quite sure how or why would a word obtained via a perfectly plain and common prefix ever be obsolete but in any case, here it is then “last recorded” again, quite more recently than the 1600s.[↩]

A ton of tubers a day keeps hunger at bay – or at least at a small cove, perhaps

Adventurous explorers in Eulora 2 reportedly found that there is at least some benefit to eating the tubers one digs. Even if not all around nutritious as it might be desired, they are at least not poisonous either and can even give a much needed (if at times rather small towards negligible) boost to one’s hitpoints (hp) and bloodpoints (bp). Imagine then if one could one day perhaps cook them into something even more useful than this…

Crafting supplies are in but who has the money for it?

The long-awaited crafting supplies are indeed fully and freely ¹available at the one and only official merchant, Rainer Tracksnarl. He duly advertised them in chat, players duly checked them out and barely managed to buy anything at all from all the piles:

One-legged craft-table reportedly crafts just fine

Active eulorans have recently spotted a one-legged craft-table in the wild, apparently crafting nevertheless just fine. As precarious as the whole thing looked at first sight, its contents proceeded to transform as expected and the output came in quite good looking too, so all is fine and in good euloran tradition – after all, if the table had two (or more!) legs to start with, what leg would there be left (or even right) for further improvement?

How many clumps of grass does it take to make one coarse, frangible thread?

This is the question on eulorans’ lips, as crafting gets a slow but quite determined start. Opinions on the matter are diverse but also changing quite often, it would seem. From a reported starting 1 to anything between 4 and 5 currently, there seems to be no limit to it. And it all seems quite similar to an earlier public discussion on the little bits of nothing required to build a single tiny claim:

Merchant gets a grip on his runaway inventory

The prominent merchant of all things euloran, Rainer Tracksnarl, recently got a large shipment of crafting items of all sorts, neatly packed and carefully stacked by type and quality. The shipment is holding well but the stacking reportedly went quickly wild with all the players’ attention going through it, so that the merchant found himself with thousands of items scattered around in his inventory. While nothing was lost, lots was thus misplaced and even more was just taking up space, pushing desired items so far away that some said they could not even find them at all anymore.

Confronted with this unexpected issue of his runaway inventory, Tracksnarl finally took matters in his own methods and invested in a reliable re-stacking after each attempted exchange. Results so far look tidy, compact and utterly worth it, especially as players get to use the neat compact packing for their own inventories, too:

NPCs ² wonder out loud

As NPCs are increasingly active providing their services and answering questions in chat, it emerged that they may on occasion engage in conversations of their own. On one such occasion, they seem to be quite curious as to what humans might even be:

1. Possibly “Free as in free speech, not free beer” or more plainly and aptly put: publicly traded, not gratuitously given.[↩]
2. Non-playing characters. Because they work in the game, they dont’ just play it like PCs do, obviously.[↩]

~This is a work in progress, to be discussed and expanded as the game progresses further. This article brings together and builds on the work already done and the preliminary concepts that were already described in previous articles, including a first draft of a data hierarchy, its subsequent refinement and an initial brief discussion of how it works in practice.~

To support players in their quest to explore, make their name and write their own history in the infinite and infinitely expanding world of Eulora2, the game’s client acquires and maintains at all times a dynamic view of the game’s world, as it becomes accessible and known to each player and as it responds to their actions or as it changes otherwise, with time or due to other players’ actions and to the game’s own internal rules.

The above means specifically that the game’s client successfully retrieves and makes use of any new data in its relevant context on the fly, as it becomes available and without knowing it upfront – because it simply can *not* be known upfront, since it’s the players’ actions that decide the very evolution of the game’s world! Playing Eulora2 truly means exploration and discovery in full, not just a pretense kept alive by some sort of agreement between server and client to merely not show or not use some data until the server says it’s “available” and the client is “updated” to have it and be able to handle it. In Eulora2, the player doesn’t need to avoid for whatever reason to even look at the files on their own disk. Quite on the contrary and unlike in any other game to date, in Eulora2 the player is warmly invited to look at the files on their own disk, to make full use of all the data and knowledge that they can access at any time, to write or use their own bots and anything and everything else that they can gather or even think of.

The game’s own client as I made it to date supports the above by design, as it is entirely and fully dedicated to serve the player with all it has and all it can actively and continuously acquire. These are not empty words but fundamental principles of mine and thus I made the client according to them, quite on purpose: it continuously checks, discovers and acquires new data and new knowledge of the world as it becomes available and it makes full use of it and of any new assets on the fly and as unobtrusively and quickly as it can.

How is such continuous discovery of knowledge and on the fly use of new assets even possible? In short, it’s made possible by knowing the very syntax of the game’s world representation – thus, instead of trying to enumerate upfront the world entire and getting stuck as soon as a new element is added, my client for Eulora2 simply starts off knowing how to discover and make sense of new elements as they appear.

My client starts without any of the game data but with the full ability to acquire and make sense of any and all such data, as soon as it has a working connection to the server. The way it does this is by knowing the rules of how the Euloran world describes itself, the very syntax of world knowledge in Eulora2. Unlike the usual game clients that start by having upfront a ton of data and graphics assets, my client starts without any of those but with a full working knowledge of the solid structure that contains and gives meaning to such data within the game. In other words, my client starts knowing how to obtain and make sense of data and then it proceeds to do exactly that, for as long as it runs and handling without any trouble all sorts of new situations as they appear, supporting thus the expansion of the player’s own increasing knowledge of the game’s world as it evolves with active play.

Knowledge of the game’s world as seen by any given player in Eulora2 is at all times a tree – a finite tree for sure but one that can have any number of branches and any number of levels, changing continuously as well, in response to the player’s actions and to the evolution of the game’s world as the time passes. To support the player, my client repeatedly explores this tree, pruning dead branches, growing new ones as relevant, updating and further interrogating parts of current interest and showing to the user the corresponding world view and its changes as they are obtained from the server in response to specific requests ¹. Such showing of the world view is done through the graphical user interface (GUI) by default and through command line on demand. Playing the game relying entirely on the GUI alone is certainly possible but like all and any exclusive reliance on GUIs alone, this is a very limiting proposition really. Up to each player though how they play the game at any given time, for sure, but if you choose to limit yourself in some way, don’t expect that everyone else will necessarily limit themselves the same way, that’s all.

The above approach works to make sense of new content as it appears for a very simple reason: while the exact tree of knowledge for each player will be different and will keep changing throughout the game, its structure will always be syntactically correct, obeying thus at all times the known rules of describing the Euloran world. And since the game is by design and with intent fully open and encouraging players and developers to make or tweak their own clients as it serves them best, this syntax is public and will remain so at all stages. Moreover, any new additions to it will expand its capabilities as needed but without breaking at any point the compatibility with what came before – meaning that there is no requirement to “update” anything at any time. There is the option to do so or not, as and if it suits, nothing more. Like all Euloran evolution, even the world’s own language and corresponding syntax may certainly expand but in an organic manner, opening up new options on top of and building on existing ones, not contradicting nor “obsoleting” anything. In Eulora2 and as a fundamental principle, experience is an asset that keeps on giving – if one builds it up and uses it for all its worth, of course.

As for this knowledge tree itself, let’s illustrate it with an actual small example first and see how it describes the Euloran world or, more accurately, how it describes what one player happens to know about the game world at one given time:

(null, null)
- (Self, 23523903281)
-- (PlayerID, 123503920)
--- [10950238522]
-- (Salt, 8908319)
--- [2a891d0f] 
- (Sector, 513250013)
-- (NameVal, 120945693)
--- [Waypoint]
-- (Ground, 935410)
--- (CSModel, 10853092)
---- [ea3420d8982]
-- (Sky, 1930582)
--- (CSModel, 8273509)
---- [8ff24351ab92c]
-- (PC, 10950238522)
--- (NameVal, 82082501)
---- [Edward Wealthgore]
--- (Cal3DModel, 98357102)
---- [183cca82bf82e]
--- (Image, 125935601)
---- [1f98eb246caa28]
--- (PosRot, 2795927491)
---- [101, 252, 114, 124, 42, 90]
--- (Item, 9873592011)
---- (NameVal, 873798211)
----- [Coarse Cordage]
---- (CSModel, 17349272)
----- [ff32ea1d89cb0]
---- (Image, 72985711)
----- [91a0b3f28ea8d]

Reading the above would yield the following description of the world: starting from the root of the tree (that null,null first line), there is first of a all a Self (with ID 23523903281) and a Sector (ID 513250013). Further asking the server as to what exactly that Self with id 23523903281 contains yields as children nodes a PlayerID (ID 123503920) and a Salt (8908319). Both PlayerID and Salt are leaf types in our tree and this means that upon asking the server to expand further on these two IDs (123503920 and 8908319), the response will provide directly values rather than further tuples (type,ID): the actual ID of the player’s own character is thus revealed to be currently 10950238522, while the value of the Salt turns out to be 2a891d0f, standing for a file with this exact keccak sum ³.

Going back up in the tree and asking for further information about the Sector (ID 513250013) reveals that it contains a NameVal (ID 120945693), a Ground (ID 935410), a Sky (ID 1930582) and one PC with ID 10950238522. At which point, the client will have found therefore the player’s own character in game, since this ID is exactly the one indicated by that earlier PlayerID node. Given that there is currently no other PC in this sector, it seems that for the time being, this player is either alone in the world or at least not yet seeing anyone else – possibly others are somewhere in the world but not yet within interacting/seeing range.

Drilling deeper into this PC node will reveal that the player’s character goes by the name of Edward Wealthgore, is located at some specific point as given by the value of that PosRot node, carries a Coarse Cordage item and uses as 3D representation as obtained from the graphics assets packed in the file with keccak hash 183cca82bf82e (the value of the Cal3DModel node) and as 2D representation what can be obtained using the file with keccak hash 1f98eb246caa28.

Repeating the same sort of exploration as above for the remaining nodes, in turn, there will be detailed information about each, as relevant, including any contained nodes as well as graphical representations and additional characteristics. I’ll leave the detailed description of the remaining nodes in the above example as an exercise for any reader wishing to test their understanding with a practical application.

While the above may seem tedious when written down in full detail, note that it’s done at all stages internally, automatically and extremely quickly by the client code – it’s exactly the perfect task for computers anyway, using a well and clearly defined structure to hold and process data repeatedly. As the player moves about, they are likely to encounter others and perhaps items too and thus more PC and Item nodes, each with their own IDs, will appear as children of that same Sector node above. If the user drops the Coarse Cordage that they are currently carrying, the corresponding Item node will simply move from its current place as child of the player’s own PC node to become a direct child of the Sector node and perhaps other characteristics of the PC node (not shown in this minimal example) will change to reflect the lighter load carried. Similarly, if the user picks up an item, that item’s node will move to become a direct child of the player’s own PC node and other values may change as well. When the user starts some work, a corresponding node will appear, holding the relevant information and allowing thus the client to provide feedback to the user as to the effect of their action in the world etc.

As to obtaining new data and assets as they become available, the mechanism is the same throughout: on-demand discovery followed by explicit request. For instance, when the client encounters in the world tree a filename that it doesn’t currently have, it will simply request it from the server according to the lower level communication protocol that fully supports such requests and then proceed to use the file as soon as it’s fully downloaded and checked to match the expected hash. Similarly, when it encounters a new node where previously there was none, it will request further information drilling down repeatedly until it gets to the leaves and it knows thus that there is no further information to obtain.

Following exactly that earlier mentioned principle of the client aiming to fully serve the user and empower them to make use of any and all information whenever available, the player can directly interrogate and explore themselves the current tree at any time, simply via an ls command in the game’s own console, quite similarly to how one explores the tree of files on disk from the command line on any computer. Note that this is made available without being either mandatory to use nor in the way of play otherwise – the whole point is to enable and support users at any and all stages, not to force on them anything and especially not to overwhelm them with more information than they request or are able to handle at any given time. Unless asked otherwise, the client will happily do all the above in the background and simply present the results in graphical form as accurately as possible but whenever the user wants to dig deeper and take advantage of the additional flexibility and power that a command line always offers over a graphical user interface, the option is and remains entirely available.

It’s worth noting that the graphical user interface (GUI) is always and at all times a simplified and thus reduced set of options for interaction, never the reference as to what can be done or accomplished. This is simply because it can never be any other way really – the way computers work is always through a set of rules that are quite unaware and unimpended by whatever limitations are introduced by the GUI that has to pick some set of shortcuts essentially out of the full set of real possibilities. Hence, while the game can certainly be fully played through the graphical interface alone and the GUI – or at least the one I make and maintain – will at all times aim to support the user as much as possible, it’s really unlikely that any implementation of a GUI will be ever able to provide in full the same flexibility as the command line offers. For this reason, my client at least has and will always have the command line integrated, alongside the GUI, as the more flexible and ultimately more powerful way to explore and act. Moreover, since the command line is always the reference as to what can be tried and attempted too, be aware that if you limit yourself to the GUI alone, you are more likely than not to miss out.

As for the syntax of world knowledge in Eulora2, the current set of node types and their possible direct children is the following:

In addition to the above, some constants have a fixed assigned meaning in their respective contexts:

The above syntax has been in use successfully for a couple of years already so it’s not going to change fundamentally. New node types are likely to be added as the implementation proceeds further but they will be added to this list, as needed. Even at this time, I don’t quite see the case for removing some node types and even less so for altering them since that would indeed be the only way in which compatibility is broken. Nevertheless, until access to the client is widely open to everyone, consider the list above as a work in progress rather than fixed and otherwise as an invitation and opportunity to get involved perhaps, if you do your own implementation and have any questions related or otherwise relevant to it.

Any related discussion is welcome and can best happen in the comments below, as usual.

1. Note that the server for Eulora2 serves essentially as an oracle for the game – it answers any and all queries but it never pushes information unasked. This is by design, fully intended as such and entirely unlikely to ever change. There’s a wide scope for client implementations to compete though on different approaches to best make use of the server oracle for their users and thus provide an in-game advantage that players will be willing to pay for.[↩]
2. This as all numbers in here are given as example only and as such, rather shorter than the actual values.[↩]
3. Given here in hex for easy distinction of file hashes vs other values so it’s easier to follow with an actual client at hand, since the client uses this hex string to name the file on disk. Otherwise the value of that keccak sum is sent from the server directly as a number as obtained from keccak, of course.[↩]
4. This is by convention the root of the tree and there is always at all times one single root.[↩]
5. Expiry date meaning the in-game time until when current sustenance lasts.[↩]
6. birth date, if known[↩][↩]
7. This is because some items can contain other items, of course.[↩]
8. Currently used masks over this are 0x10 for Locked, 0x02 for Inaccessible[↩]
9. referenced object, if any, e.g. keys reference the item they unlock[↩]
10. This was an early test and it works fine but meanwhile my design moved away from pretending to have “dialog” with bots and towards an altogether more promising quest system. For now though this node is still possible to encounter, indeed, hence it’s shown in here.[↩]
11. 0x10 for locked, 0x0C for approved[↩][↩]
12. This is the approximate size of one unit of whatever the parent is, given in some consistently-used unit across the whole game at any given time.[↩]
13. This is the approximate capacity of one unit of whatever the parent is, given in some consistently-used unit across the whole game at any given time.[↩]
14. A faster but more restricted view of the items contained in something – the server decides at all times whether this is used or not.[↩]
15. Increased by at least 1 and at most 255 at each change.[↩]
16. Shorthand code, unique across basic items in Eulora 2, obtained as upper case letters as found in order in the item’s basic name excluding any additional prefixes and suffixes[↩]

‘Why?’
Because I need and use it.

‘What?’
The full, C-only code for zip archive operations of all sorts, entirely standalone and free of autotools and the like, ready for my intended use directly from Ada code and easily extendable for any other specific use from either C or Ada. It produces and uses standard zip archives. It comes with all needed headers, bells and whistles, a minimal .gpr file for compilation with GNAT as a static library and some commented out examples, too. The heaviest part of it is, unsurprisingly, the code for zip operations that weighs in at 10130 lines in miniz.h. The rest of the code adds about 2400 lines more in total.

To expand a tiny bit on the above, I’m using this exact code as part of the fully automated graphics pipeline that generates on demand any and all graphics that Eulora2 needs, as it needs it. I haven’t bothered to “clean” the code to any specific extent beyond the very functional – it either serves or at least stays out of my way. As such, I think the code as it is currently makes, if anything, a good place to start for someone wanting to learn to read effectively code, perhaps – it’s reasonably big without being too big and otherwise written and packed at all points by people focused on their own needs for it, not on ticking something off some check lists or using up some time at work.

I’m publishing the code as a 1st edition of MiniZipLib, in VaMP format, of course, since it can be perhaps useful to others if/when they want to avoid depending on external code for any zip-related needs.

Note also that the client for Eulora2 relies currently on something else, essentially external zip code even if this external dependency happens indirectly, via CrystalSpace. This is because all graphics assets are stored and used as .zip files that group together the various parts and pieces that are required at times to make a full model or item. While my current main interest and use for this lib is mainly serverside, the client could certainly benefit as well from reducing its dependency on external code and integrating this. Currently I don’t have the time to do it though as the further development of the game itself takes precedence but I’m making the VaMP tree for it public via this 1st edition, so that others can pick it up if they need it.

As usual, feel free to ask relevant questions in the comments, below. If you don’t know and need to find out where the code is thus published, it’s likely though that you are still missing an earlier step, namely interacting with people so read perhaps a bit more around and see what pulls you in so that there is some better starting point for it all than mere code ever was or ever will be.

As the game‘s development is progressing beyond the emergence of time, past the addition of vitals and into enabling player activities, all the design and implementation work done so far feeds as well into clarifying and refining the game-related parts of the communication protocol that were previously tentatively and incompletely stated ¹. Specifically, it’s again that ‘Character Actions’ section 7 that comes into focus but this time the changes go beyond just simple additions and move things forward from where the previous effort towards specification stopped. Consequently, I have to bring together the different parts and restate the current take on the protocol in full, in here, where it can be further iterated and discussed as needed:

This is the current take on Eulora2’s communication protocol, last revised June 13th, 2023.

1. Overall Goals:

• 1.1. All communications between clients and server to be encrypted.
• 1.2. Clients to be able to receive from server any data they lack (including maps, skins, sound or video content etcetera), on demand.
• 1.3. Clients to be able to choose and adjust both the level of security and their volume of communications with the server, as they will ultimately have to pay for the load that they generate.

2. Explicit Dependencies :

• 2.1. Eucrypt for RSA with Keccak-based OAEP and Serpent symmetric ciphering.

3. Data Structures :

3.0. Basic types :

• char / uint8 (1 byte) ;
• uint16 (2 byte) ;
• uint32 (4 byte) ;
• uint64 (8 byte) ;
• float ² (4 byte) ;

3.1. Special types:

• hash (128 bits) ;
• chunk [of file] (bitfield, 11760 bits) ;
• serpent-packet (1472 bytes) ;
• rsa-message ³ (1872 bits ⁴) ;
• rsa-packet ⁵ (1470 bytes) ;
• object (size of 104 bits ⁶: uint32 ⁷ followed by 3 uint16s representing position ⁸ followed by 3 uint8s representing rotation ⁹ ) ;
• legacy-text (size of n+n/256+1 bytes ; where the leading byte is the bytecount of the 2nd segment and the 2nd segment is the bytecount of the third segment) ¹⁰.
• text (2 byte hearder containing the ~total~ byte length ; up to 1470 bytes of text ).

4. Serpent Packets ¹¹ :

4.1. Serpent Key Set:

• uint8 (type ID, =100), followed by
• uint8 (count of keys in this set, n), followed by
• n*(4*int64 + uint32) (32 bytes each key followed by a 4 byte ID calculated through crc32 ¹² ), followed by
• an uint8 flag (LSB bit set — keys to be used to talk to client ; MSB set — key to be used to talk to server ; client-set MSB is ignored), followed by
• uint16 (message count ¹³), followed by
• padding to Serpent-message length.

4.2. Serpent Keys Lifecycle Management:

• uint8 (type ID, =102), followed by
• uint8 (count of server keys requested), followed by
• uint8 (count of client keys requested), followed by
• uint8 (id ¹⁴ of serpent key preferred for further inbound Serpent-messages), followed by
• uint8 (count of burned keys in this message), followed by
• n*int8 (id of burned key), followed by
• uint16 (message count), followed by
• padding to Serpent-message length.

4.4.a. File Request, manifest

• uint8 (type ID, =3), followed by
• hash (corresponding to the sought file ¹⁵), followed by
• uint8 (manifest packets sought count, 0=all), followed by
• n* uint16 (manifest packet index sought), followed by
• padding to Serpent-message length.

4.4.b. File Transfer, manifest (always sent and only sent in response to ID 3)

• uint8 (type ID, =4), followed by
• uint16 (count of manifest packets for this file ¹⁶), followed by
• uint16 (index of current packet in list above), followed by
• uint8 (fragment count ¹⁷), followed by
• n* uint64 (hash of the nth fragment of manifested file).
• uint16 (keccak hash of foregoing), followed by
• padding to Serpent-message length.

4.4.c. File Request, chunks

• uint8 (type ID, =5), followed by
• hash (corresponding to the sought file), followed by
• uint8 (file chunks sought count), followed by
• n* uint64 (the hash of fragment sought), followed by
• padding to Serpent-message length.

4.4.d. File Transfer, non-last chunk (always sent and only sent in response to ID 5)

• uint8 (type ID, =6), followed by
• chunk.

4.4.f. File Transfer, last chunk (sent at most once per ID 3)

• uint8 (type ID, =7), followed by
• uint16 (bytesize of useful part of the chunk following ¹⁸, followed by
• chunk ¹⁹.

4.5. Client Action ²⁰ :

• uint8 (type ID, =8), followed by
• text (fully specified action, see section 7), followed by
• uint16 (message count), followed by
• padding to Serpent-message length.

4.6. World Bulletin ²¹:

• uint8 (type ID, =9), followed by
• uint32 (id of top level item ²²), followed by
• uint8 (count of objects), followed by
• object list ²³, followed by
• uint16 (message count), followed by
• padding to Serpent-message length.

4.7. Object Request:

• uint8 (type ID, =10), followed by
• uint8 (count of objects), followed by
• n*int32 (id of object), followed by
• uint16 (message count), followed by
• padding to Serpent-message length.

4.8. Object Info:

• uint8 (type ID, =11), followed by
• uint8 (count of objects), followed by
• n times uint32 (id of object) and text (object properties, as per extant game structures, including art files needed and so on ²⁴), followed by
• uint16 (message count), followed by
• padding to Serpent-message length.

4.9 Line Request

• uint8 (type ID, =12), followed by
• uint8 (count of lines), followed by
• n times uint32 (id of chatroom), uint64 (lowest line number requested), uint64 (highest line number requested), followed by
• padding to Serpent-message length

4.10 Line Info

• uint8 (type ID, =13), followed by
• text (line content), followed by
• uint32 (chatroom ID), followed by
• uint32 (speaker ID), followed by
• uint64 (line number), followed by
• uint64 (keccak hash of the line’s content and number), followed by
• padding to Serpent-message length

Updated 30 Oct 2024: ratings are now fully integrated and used in-game, being fully handled via the relevant Rating node in the data hierarchy. Consequently there is no need anymore to have dedicated message types for discovery and retrieval, so the “rating request” and “rating info” message types below are removed entirely. Rating someone remains done as an action (see the action types further down) and discovery happens as part of the usual game play.

4.11 Rating Request

• uint8 (type ID, =14), followed by
• uint8 (count of requests), followed by
• n times uint32 (source ID), uint32 (target ID), followed by
• uint16 (message count), followed by
• padding to Serpent-message length

4.12 Rating Info

• uint8 (type ID, =15), followed by
• text(rating comment ²⁵, followed by
• uint32 (source ID), followed by
• uint32 (target ID), followed by
• uint8 (rating value ²⁶ ), followed by
• uint16 (message count), followed by
• padding to Serpent-message length

5. RSA Packets ²⁷ :

5.1. RSA key set ²⁸.

• uint8 (equal to 251 to indicate packet contains a new RSA key), followed by
• uint8 (protocol version), followed by
• uint16 (subversion), followed by
• uint32 (IP of server ²⁹), followed by
• uint32 (IP of client ³⁰), followed by
• uint64 (keccak hash of client binary), followed by
• uint64 (e of RSA key), followed by
• uint8*490 (N of RSA key), followed by
• uint64 (preferred padding — the magic value of 0x13370000 requests random padding ; all other values will be used as such, bitwise, ie like an infinite-length OTP consisting of the value repeated), followed by
• uint16 (message count), followed by
• padding to RSA-message length, 1424 (5616-8-8-16-32-64-64-3920-64-16) bits exactly.

5.2. Serpent key set ³¹:

• uint8 (equal to 157 to indicate packet contains new Serpent keys), followed by
• uint8 (count of keys ³² in this set, n; n<=19 ³³), followed by
• n*(4*int64 + uint32) (32 bytes each key followed by a 4 byte ID calculated as crc32 on the key itself), followed by
• an uint8 flag (LSB bit set — keys to be used to talk to client ; MSB set — key to be used to talk to server ; client-set MSB is ignored by server ; server will set LSB on keys requested by client for its own use thus supporting clients with no trustworthy random generators of their own), followed by
• uint16 (message count), followed by
• padding to RSA-message length.

6. Protocol Mechanics :

6.0. All communications between server and client will consist of messages. These messages may be encrypted either via eucrypt.RSA or eucrypt.Serpent. All RSA-encrypted messages will be exactly 1`470 bytes in length ; all Serpent messages will be exactly 1`472 bytes in length ³⁴ . The server will handle Serpent messages in preference of RSA messages (which are processed on an as-available basis). Clients that send garbage will be punished ; the costs involved (encryption/decryption ; generating entropy ; lookups and whatnots) will be pushed onto the client, for which reason writing the clients lightly pays off.

6.1 The handshake works as follows:

• New client issues 5.1 packet keyed to the server’s public key, including its own RSA key.
• The client’s IP is recorded, and will have to be explicitly changed by the client later if needed. Server replies with 5.1 packet keyed to the client’s announced key, including its private RSA key for use by that client ; and with 5.2 packet containing key material for client’s use in keying messages to the server. If the client fails to provide its own set of serpent keys, the server will further issue it a set of serpent keys ; thenceforth the server will send more serpent keys mirroring the client’s supply, and will similarily mirror key burning and select operations on its own set.
• Should the client’s IP change, it will issue a 5.1 packet keyed to the server public key immediately followed by a 5.1 packet keyed to the server’s original private key. The server will then update the client’s IP accordingly (this also trashes the extant Serpent keyset and triggers 5.2).
• The bulk of communication is intended to go through the Serpent system ; outside of identification and bootstrap handshakes RSA isn’t used. Should either party believe the Serpent keysets’ve been FUBAR’d, a 5.2 packet will reset that keyset.

6.2. The server will issue type 4.6 packets in response to relevant type 4.5 packets received — these can either signify the acceptance or the rejection of the client action, and the client must adjust its internal state accordingly.

7. Character Actions :

7.0. Lock:

• uint8 (type ID, =0), followed by
• uint8 (count of objects), followed by
• n* uint32 (object ids). Defaults to currently targeted item.

7.1. Make ³⁵:

• uint8 (type ID, =1), followed by
• text (title of quest), followed by
• u64 (count of how many different times can this quest be completed – note that the reward will be divided accordingly), followed by
• uint32 (arbiter id, defaults to nearest town crier), followed by
• uint32 (object id of a sample of the required item), followed by
• uint64 (wanted quality, defaults to 1), followed by
• uint64 (wanted quantity, defaults to 1), followed by
• uint8 (expiry day, defaults to 1), followed by
• uint8 (expiry month, defaults to 1), followed by
• uint64 (expiry year, defaults to next year), followed by
• uint32 (object id of reward item stack, no default)

7.2. Attempt ³⁶:

• uint8 (type ID, =2). This is a request to start the chosen activity (see next field), followed by
• uint32 (object id, indicating the intended activity, defaults to explore ³⁷), followed by
• uint32 (object id, defaults to current target or location, as relevant), followed by
• uint32 (object id, defaults to currently equipped method, followed by ³⁸)
• uint32 (object id, defaults to currently equipped tool)

7.3. Exchange:

• uint8 (type ID, =3), followed by
• uint32 (object id, the other party), followed by
• uint32 (object id, the trade itself ³⁹), followed by
• uint8 (count of objects), followed by
• n* uint32 (object ids) and uint64 (object count), followed by
• uint8 (flag, set to 0x10 to lock a trade and to 0x0c to approve a trade previously locked by both players).

7.4. Attack:

• uint8 (type ID, =4), followed by
• uint32 (object id, the other party), followed by
• uint32 (object id, the battle itself (server set, exactly in the way trade works). This not currently implemented, except player setting itself the bomb results in instadeath.

7.6. Move:

• uint8 (type ID, =6), followed by
• uint32 (destination id, defaults to current target), followed by
• uint32 (slot id), followed by
• uint32 (object id, of the item being moved), followed by
• uint32 (quantity moved).

7.7. Train:

• uint8 (type ID, =7), followed by
• uint32 (object id, the other party), followed by
• uint32 (object id, the train session itself (server set, exactly in the way trade and battle work). This not currently muchly implemented, except some NPCs train for money — but will get greatly expanded asap. Meanwhile, it actually got both expanded and implemented, see the relevant comment for more details.

7.8. Relocate:

• uint8 (type ID, =8), followed by
• object type, containing new client position.

7.9 Say ⁴⁰:

• uint8 (type ID, =9), followed by
• text (line content), followed by
• uint32 (room ID), followed by
• uint64 (keccak hash of the line’s content)

7.10 Rate:

• uint8 (type ID, =10), followed by
• text (rating comment), followed by
• uint32 (target ID)
• uint8 (rating value)

Please leave your comments below.

1. This type of iterative refinement and interaction between design and implementation is neither new nor surprising to me, really. The only difference is that I’m doing now out of necessity all sides of this. Experience helps *a lot*, of course, even or perhaps especially beyond and above what one ‘expects’ or what one ‘wants’ or what one ‘signed up for’ and so on and so forth. It might even help in the sense that it makes it possible at all, at that, even if it doesn’t make it easy by any definition of the word.[↩]
2. Floating point item deliberately not specified[↩]
3. Each such message is OAEP-padded and then encrypted with a (3920 bit) RSA key. Three such messages are strung together to form a RSA packet. Because of the significant overhead involved (both in terms of space and time), Serpent-encrypted comms are preferred whenever feasible. [↩]
4. See TMSR-RSA OAEP padding for the principle and this discussion for details.[↩]
5. This is the total size of a packet containing RSA-encrypted material. The useful size (ie payload) of such a packet is merely 702 bytes.[↩]
6. We really really want to keep this down. 13 bytes is the lowest I can conceive of, but I would so not mind halving it.[↩]
7. Representing the identifying hash of the object in question.

   We’re using the narrower size to save on network traffic — all the expenditure of another 32 bits here would buy us is de-ambiguation for cases where the count of objects around makes 1 in 2 billion collisions relevant. It doesn’t seem likely a client could support such abundance of objects.

   Note that the hashes used here are client-specific, the server doesn’t leak its own internal representation of objects to the clients.[↩]

8. Coordinates X, Y and Z in that order. Because the map goes from -512 to +512, the relationship between the given figure (GF) and map coordinates (MC) is GF / factor_coord – max_coord = MC, where max_coord is 512 and factor_coord is 65535/(2*max_coord).[↩]
9. As a full rotation is 2 pi, the relationship between the given figure (GF) and object rotation (OR) is GF / 128 * pi = OR.[↩]
10. This arrangement permits the representation of arbitrarily large textfields (2nd segment can represent up to 115`792`089`237`316`195`423`570`985`008`687`907`853`269`984`665`640`564`039`457`584`007`913`129`639`936 bytes, which is more than enough space for all the text ever produced — or likely to ever be produced — by humanity) at the modest cost of a fixed 3 byte header.

    Unfortunately, it has no longer any utility for Eulora, since we’ve moved to fixed packets. I’m preserving it here because I really like it in the abstract and it has no other place to go.[↩]

11. These packets consist of 92 successive 128 bit chunks, Serpent-enciphered individually. To extract the payload one splits the message into 92 16-byte chunks, deciphers them then collates the output into a final result. To produce the packet one cuts a 11`776 bit payload into 92 128-bit chunks, Serpent-enciphers them, and collates the results into the outbound packet.[↩]
12. Polynomial generator 0x04c11db7. Keys with null IDs are discarded and regenerated.[↩]
13. Each client and the server will keep a count of messages they sent each other. This value must be incremented on each subsequent message sent by no less than 1 and no more than 255.[↩]
14. Keys are maintained by both client and server in an ordered ring buffer 256 elements long. The server will not send more keys than the total count of 0(absent)-keys in the respective buffer, irrespective of request count. If the message contains an unknown ID or otherwise is unprocessable, the issuance of a 5.2 packet is adequate response.[↩]
15. This is the keccak hash of the actual file contents. By convention this hash rendered as a 32 alphanumeric character string is also used as the filename for the file in question.[↩]
16. This system allows up to 65`536 manifest packets, adding up to potentially 11`993`088 (65`536 * 183) fragments representing a file of up to about 140 Gb (141`038`726`624 = 11`993`088 * 11`760 + 11`744 bits exactly). This will have to be sufficient.[↩]
17. From 1 to 146 inclusive.[↩]
18. This also means the protocol does not allow the transfer of files of certain sizes (within 8 bits of a multiple of 11760), which is fine with me.[↩]
19. The final fragment of the file will have to be padded to length as per this spec. [↩]
20. This is never issued by the server.[↩]
21. This is never issued by the client.[↩]
22. As discussed in comments, the world is a hierarchical structure of objects within objects.[↩]
23. This portion will get more clarification later on! [↩]
24. The complete list of these is currently exposed by the extant client, but in any case we’ll publish a complete schematic. The server will set the “target” of the player on the last object in the list.[↩]
25. Limited to at most 1445 characters, matching the maximum length of a chat line.[↩]
26. Valid rating values are integers between -10 and 10. For a given rating value here GR, the corresponding actual rating value RV is therefore calculated as: Min(GR, 20) – 10.[↩]
27. These packets consist of three 490 byte successive chunks RSA-encrypted individually. To extract the payload one splits the message into three 490 byte chunks, RSA-decrypts and de-OAEP-pads each one, the collates the results into a final result. To produce the packet one cuts a 5`616 bit payload into three 1`872 bit chunks, OAEP-pads and encrypts them, and collates the results into the outbound packet.[↩]
28. This is the manner in which new clients register their RSA key with the server (thereby opening a new game account). Later replacement of a registered key IS NOT POSSIBLE. Keep your client’s RSA key safe.

    This is also the manner through which IP changes for an account are registered with the server. See the Protocol Mechanics heading for details.[↩]

29. This is used by the server when signalling to the client to talk to a different server (which is a thing for scaling, because different sectors will be handled by different servers).[↩]
30. If the client doesn’t know its own IP, it’s acceptable for this to be zero. [↩]
31. This permits either client or server to declare Serpent keys via RSA. It is not mandatory (as there exists a Serpent-encapsulated mechanism for the same end) but entirely legal. The server will always respond with at least one 5.2 packet after an accepted 5.1 packet creates a new player account, consisting of 40 Serpent keys to be used to talk to the server. Should the client respond with any other packet than 5.2 or 4.1, the server will send a 2nd 5.2 packet, containing 40 Serpent keys for the client’s use. [↩]
32. Keys obtained through a 5.2 packet are always indexed in the client’s buffer in the order they were found in that packet, starting with the first position.[↩]
33. A RSA packet has 702 total bytes available, of which 5 are used otherwise and the remainder of 697 are available for packing serpent keys, which take 36 bytes each (crc32 id inclusive).[↩]
34. Length being actually how they’re sorted on the server side.[↩]
35. This is meant as a production order, essentially. I expect it will get further refined as its implementation gets nearer. It already got further refined and more specifically defined as a way to issue/create Quests or “wanted” posters fundamentally, see the relevant comment on quests.[↩]
36. This is a generic initiation of player activity and as such literally an attempt, with the contents defining the exact activity. It replaces both Explore and Repair from earlier versions of this protocol but it further stands in for *any* game-defined activity even ones that may appear only at a later time. It’s as generic as it gets and quite on purpose, since this is the network layer, not the game layer. For more details on the game-defined activities, see the description of the data hierarchy.[↩]
37. Known activities are obtained like everything else in game as part of the data hierachy representing the client’s view of the world at any given time. The relevant grammar for it will be made public as it serves as the in-game protocol specification just as this serves as the network-level client-server protocol specification.[↩]
38. Known in Eulora 1 as ‘recipe’ and ‘equipped in mind’. At this level, the protocol for Eulora2 is really more generic than that, without any loss otherwise whatsoever.[↩]
39. This is set by server through a type 6 message for both players involved, the trade is an object like any other that the OP has to request. The server will also expire trades, enforce them etc.[↩]
40. Note that this is an action and as such just a part of a 4.5 message, Client Action, where the overall message structure is specified.[↩]

The quickly progressing work on euloran vitals and physical characteristics is pushing already the design – and the fun, obviously! – into previously unmentioned and thus entirely uncharted areas. This time it all started easily enough: given that at least some vitals certainly drain with activity, what does unrest truly do to one’s wellbeing, what is rest going to even look like and what can one really do -or not do, rather- about it for best results?

As all good questions, the above has, of course, a common-enough answer that isn’t much good really but still has to be properly considered, first of all: unrest tends to do more to one’s worsebeing rather than to one’s wellbeing and rest is certainly needed so introduce a ‘rest’ action that the player can choose to do whenever they feel like and the game permits! Which sounds reasonable enough and doable enough, to the point where I even sketched out a new addition to that section 7 of ‘character actions’ in the communications protocol, since it’s really not all that difficult to add or use: have another ID, give some duration in hours now that time is ticking away at everyone’s lives and use otherwise the existing infrastructure without much trouble at all. It would certainly work too, so what’s the problem with adding it, right?

Well, the problem starts with that ‘adding’ really, since the whole point of having a flexible and generic communications protocol is exactly to have a set of messages and structures that can serve a wide range of uses while being preferably as short as possible ¹. So any addition to the protocol itself comes with a non-negligible cost and thus with a strong requirement for considering first whether there is indeed enough of a fundamentally significant difference compared with already existing structures to justify a new one ². Unsurprisingly perhaps, it turns out that where euloran rest is concerned, there isn’t that strong a case for a new action type as such – or at least not yet!

So then, if resting is both possible and needed in Eulora2 but it’s not to be done in the common style of being an action, how is it going to happen? The very simple answer is that it will happen by *effect*. Meaning, specifically, that different items will have a resting effect when consumed or otherwise used (and their use or consumption might take some time, too, possibly).

Further, the above approach to rest implies, of course, that one has to have such an item to even be able to rest at all, which might, at a first encounter, seem quite the alien and possibly harsh imposition (everyone can rest whenever, all they have to do is go to sleep!!), except it’s not really – just try it and see how well it goes when you try to rest without having at the very least some reasonably safe (quiet and cosy don’t even come into it) place, enough peace of mind and enough food to keep hunger at bay. Rest is indeed basic in the sense that it’s a basic requirement for survival not in the sense that it’s somehow effortless or a given at all times.

As a side effect of the most positive kind from the above, it follows of course that one would do better to keep an eye on their levels of tiredness – at least in Eulora2, since this is what the context is here. Because if they fail to rest when needed, things aren’t likely to go that well and for sure they aren’t going to go forever just because it’s a game or something. Past a certain point of tiredness, the body would naturally shut down and thus rest indeed of sorts, only it’s not all that clear if, when or how one still wakes up from such last-resort rest that is indeed guaranteed and a ‘natural right’ of everyone ³, certainly.

In summary, in Eulora2 you’ll live either responsibly or very, very briefly indeed! Practical learning, at its best.

1. And seriously, I can still fully recall the spidery mess of a ‘protocol’ that PS originally had and what a pain it was to first work with it at all, then attempt to clean it and finally sideline it enough until one could entirely get rid of it. That experience certainly is more than enough to teach one to NOT rush into adding stuff just because it’s possible.[↩]
2. For the record, such was indeed the case with the Chat additions – while they *could* be fit into the already existing structures, such fit was a very poor one because the types of use are quite different fundamentally and have thus very different requirements.[↩]
3. Weeell, maybe just about everyone? I don’t promise that there won’t be any immortals/vampires/rest-impaired creatures in Eulora2![↩]

The latest development in Eulora2 is the emergence of time itself, quietly but definitely ticking away at the hours that became days, then months and years of the very first era that eulorans ever knew. Euloran time is already past the half mark of the first month and it follows its own rules, whether anyone is aware of them or not. So far, there are at least some signs that some people have indeed noticed something new:

back in, and noticing a new euloran clock.

It’s possibly best if one starts becoming aware of the rules of time or at least aims to figure them out sooner rather than later, because the time in Eulora2 is definite indeed: definite in the same way that Maths is definite but also, perhaps of more pressing interest for eulorans, in the same way that Death is definite. On the more reassuring side, so far at least, Death is yet to be met with in Eulora2 but that’s about as much knowledge as anyone has on the matter.

As to the durations and even structure of euloran days, months and years, these are still to be observed. What I will let slip is that Eulora2 has several moons that might be abstract or concrete but that certainly have very concrete effects on the world as a whole. To some extent, it might perhaps be not even false to say that the very ticking of time is just one of the more visible such effects – the rest yet to be noticed, observed and perhaps made some sense of. Not that there is any rush to do or even to notice any of it – at least there isn’t anything to rush one just yet. It’s a young world after all, still emerging, unhurriedly but unstoppably, too.

The whole first era of Eulora2 will cover in fact exactly the interval when the core structure of the world and of its interaction principles is brought in and settled in place, piece by piece. Those present and active in this first era will be essentially the actual ancestors and prime movers quite literally – after all, they are taking the risk on a nascent world and so they get also, by rights, a special status and the unique chance to leave their inprint on each part as it emerges. And there certainly are quite a few parts in the works, with next on the list the actual vitals and physical characteristics of player (PC) and non-player characters (NPCs) just the same.

Time, in this sense of Eulora2 emergence, is quite literally only the beginning!

Back when I started programming in Ada, I trusted the GNAT implementation of the Ada standard, mostly because I had no choice ¹. A few years and a lot of experience with said GNAT implementation later, I know for a fact that the I/O packages of GNAT such as Direct_IO and Sequential_IO are broken and merely obfuscating rather than helping in any significant way.

By the time I discovered in 2021 just how broken and uselessly complex these packages truly were, there were already several places where the game‘s client relied on them. Unpleasant discovery for sure but even so, given that there was plenty more pressing work to do and I had managed at least to restrict the use of such packages enough so that their bugs didn’t get a chance to manifest in my code at all, I left the existing code as it was and simply avoided using these packages in code written *from that point on*. After all, the client is anyway open source and thus easily changed by anyone who cares enough about it – if anything, this sort of known and well understood issue makes exactly for a low hanging fruit to pick, something that can even help newcomers to get more easily and more satisfyingly involved.

Recently though, as other parts get finally integrated and the client is getting ever closer to release, I reviewed this matter again, especially as VaMP came into the picture as well. As a result, it turns out that there still is a place where I can’t quite leave hanging this exact sort of fruit, namely when it comes to reading and writing cryptographic keys to the disk. First, this is quite clearly a sensitive operation and as such one where the fewer dependencies and the greater the clarity the better at all times. Second, this is integrated into the client indeed but it’s part of a base layer that is not really client-specific and as such I would really keep it as clear from any unwanted GNAT dependencies as I can ². So I took the time to review again all the i/o code and then to sort it out in the most straightforward way possible.

The solution turns out to be both short and sweet – all the sweeter for being in fact so obviously well supported by Ada as a language and by all the rest of the code that I have implemented so far. All it took was one short new package that takes advantage of the very thin wrappers I wrote for the read/write C library functions (over which GNAT wraps layers upon layers of obfuscation more than usefulness) and uses otherwise direct memory mapping to convert between any given type to its raw representation and back.

Such direct memory mapping for composed types relies in turn on a very tight specification of how such type should be represented in memory but this was absolutely no trouble at all for me currently since… I had already taken the time when I defined the needed types to fully specify their representation as well! So there it was, my own work done well in the past quite directly and obviously paying its dividends in the present and compounding the dividends for the future, too.

As for the relevant code, here’s the new mmap_io package, helpfully formatted already by my own VaMP ³ for publishing on the blog:

eucore/src/base_layer/src/mmap_io.adb

6_1 

	-- DC, 2023

6_2 

6_3 

with Ada.Directories; use Ada.Directories;

6_4 

with Interfaces.C; use Interfaces.C;

6_5 

with System;

6_6 

6_7 

with Raw_Types; use Raw_Types;

6_8 

with Raw_IO; use Raw_IO;

6_9 

6_10 

package body MMap_IO is

6_11 

	sz: constant size_t := T'Size / System.Storage_Unit;

6_12 

	procedure Write(tval: in T; fname: in String; append: in Boolean) is

6_13 

		local: aliased T := tval;

6_14 

		--for local'Size use T'Size; -- this would be static as required only for scalar types

6_15 

		data: aliased Octets_Buffer_Pkg.Elem_Array(0..sz-1);

6_16 

		for data'Address use local'Address;

6_17 

	begin

6_18 

		Write_Octets(fname, data, append);

6_19 

	end Write;

6_20 

6_21 

6_22 

	function Read(fname: in String) return T is

6_23 

		local: aliased T;

6_24 

		data: aliased Octets_Buffer_Pkg.Elem_Array(0..sz-1);

6_25 

		for data'Address use local'Address;

6_26 

		ptr: Octets_Buffer_Pkg.Elem_Array_Pointer;

6_27 

		fsz: size_t;

6_28 

	begin

6_29 

		if not Exists(fname) then

6_30 

			raise Failed_IO with "inexistent/inaccessible file " & fname;

6_31 

		end if;

6_32 

		fsz:= size_t(Size(fname));

6_33 

		if fsz < sz then

6_34 

			raise Failed_IO with "file " & fname & " too short (" & fsz'Image & " vs expected " & sz'Image & ")";

6_35 

		end if;

6_36 

		ptr:= new Octets_Buffer_Pkg.Elem_Array(0..sz-1);

6_37 

		Read_Octets(fname, ptr);

6_38 

		data := ptr.all;

6_39 

		Octets_Buffer_Pkg.Free(ptr);

6_40 

		return local;

6_41 

	end Read;

6_42 

6_43 

end MMap_IO;

eucore/src/base_layer/src/mmap_io.ads

7_1 

	-- DC, 2023

7_2 

	-- memory-mapped I/O for types that are explicitly and fully specified with representation clause given that they are read/written as raw octets directly memory-mapped.

7_3 

7_4 

generic

7_5 

	-- any type but the user of this package is responsible to ensure that a direct memory mapping works correctly and reliably for T both ways and at all times

7_6 

	type T is private;

7_7 

package MMap_IO is

7_8 

	-- write the value tval of type T to file fname either appending or overwriting (append=false)

7_9 

	-- this creates the file if/when needed

7_10 

	-- raises exception on error

7_11 

	procedure Write(tval: in T; fname: in String; append: in Boolean);

7_12 

	-- reads one value of type T from given file fname

7_13 

	-- raises exception on error (eg inaccessible file, wrong size, failed mapping etc)

7_14 

	function Read(fname: in String) return T;

7_15 

7_16 

	-- reads the idx-th value of type T from file fname

7_17 

	-- function Read(fname: in String; idx: in Natural) return T;

7_18 

end MMap_IO;

With the above done, the actual writing and reading of rsa keys was actually *simpler* than it was when relying on direct_io and the likes. As a result, the udpated code is shorter by about 30% – the relevant keys_io.adb implementation went from 471 lines when using Direct_IO to 152 lines when using my own MMap_IO and this doesn’t even take into account the dropped dependencies and how much additional code they brought in.

For anyone interested in using the client whether now or at any future date, the good news from the above is that the previously low hanging fruit of switching client i/o to a more straightforward non-gnat implementation is now even lower hanging, seeing how there is the MMap_IO package to rely on and/or to use as example for the case where something slightly different might serve better. To further help in this vein, note that the client still makes use of Sequential_IO mostly for the ‘torrents’ part, meaning the read/write of files obtained at run time from the server – essentially game assets of all sorts.

Possibly a slightly different package would serve better to replace that use for game assets since the MMap_IO package isn’t aimed specifically at sequential i/o – one might perhaps make a generic package receiving both the file and the type desired, reading the whole in memory and operating from there. It would certainly be a faster and more reliable solution that GNAT’s imagined ‘control’ over multiple simultaneous accesses to the same file on disk. I’ll leave this for another day though and possibly, even preferably for another person, too, so feel free to pick it up if it’s of any interest to you.

If you set to work and have something to show or to ask, I’ll be happy to hear of it as well, so use the comments below confidently, there’s nothing to lose for it for sure.

1. Perhaps it’s truly very naive to trust this way but at times it is also unavoidable – what you don’t know yet, you have to take on trust, there is no third way available. At best, you get perhaps the choice to trust a person based on what you know *of them* but at worst, as in this case, all you ‘get’ is to trust an unknown entity, pretty much, the ‘code itself’ aka all 360M of it or an ‘organization’ aka Adacore with all its changing history and multitude of people that you can’t ever know or get to know in any meaningful way anyway. So you trust, if and when you must but hopefully you then work as well towards reducing your own need for such blind trust. As you learn more, it’s worth remembering to revisit, reevaluate and correct or adjust misplaced trust, where necessary – this is exactly what this article describes and documents, my reevaluation and correction of previously assigned trust, as I got to know better what it was exactly that I ended up relying on.[↩]

2. Especially since on review, I realised that even Direct_IO and Sequential_IO packages from GNAT *still* rely on the ugly and gnarly “streams” even though they avoid the broken ‘finalization’ and although there is both no need for such reliance nor any use for it. The very code in question states clearly in places that the streams abstraction is meaningless for the task at hand but nevertheless it’s brought in and adhered to because of the need to fit a predefined form, a need of comformance and uniformity across the board basically, that’s it. For instance, directly from s-direio.adb:

   — The following is the required overriding for Stream.Read, which is
   — not used, since we do not do Stream operations on Direct_IO files.

   In other words, it’s most likely a deeper issue at core – the GNAT implementation values uniformity and ultimately fungibility above everything else as it sets purposefully to shield the user from the requirement of deeper understanding and actual grasp. It’s a perspective entirely at odds with my own and so it’s no surprise its fruits are unpalatable to me.

   [↩]

3. Compounding dividends yet again, see?[↩]

Since the question in the title comes up with some regularity, I’ll write out the answer here for everyone to see and for myself to have it at hand when next needed:

It’s most likely for your own sake that you’ll need to run some sort of Linux, especially if you never ran it before, but otherwise sure, Eulora2 can serve as a good motivator for it, too.

To elaborate on the above, note that *all* you need to run Eulora2 is an environment where you can compile C, C++ and Ada code from scratch ¹. Arguably, any and all operating systems are capable of such a basic feat as this, since it is, quite literally, what “operating” ² a computer system is supposed to be about – making it process (“compile”) written instructions (“code”) into a form (“binary”) that the machine can then follow (“run”) to do exactly what you told it to do. And if you don’t like what it does or you change your mind or you simply want to play around and tell it to do something else, all you need to do is to tweak the code and have the machine process it all happily again, as many times as you please. Hence the importance of *all* the steps in that process, not just the last one, not just “run this”, but absolutely all of them, from first to last.

Does your current operating system allow you to do all and any of the steps above, routinely and easily? Then you don’t need anything else and you are set to go, nobody will mind you running Eulora2 there or anywhere else and you’ll find running it just as easy as running anything else. Moreover, I’d be very glad to hear from you how it goes, what you are running it on and what changes you are making to it, too – after all, it’s meant to be *your* client to play Eulora2, not in any way someone else’s.

If your current operating system doesn’t really make it easy to even know all that much, let alone perform and control one or several of these basic steps, then you’ll probably need to try out something more useful. What exactly might that be is entirely your choice but it is indeed more likely to be some version of a unix-based system. And if you truly want to have an easier time compiling and running everything as well as perhaps changing it to better fit your needs at some point, I suggest you pick an older version and never ‘upgrade’ it with all the bells and whistles that might or might not do anything useful for you but will likely break the toolchain and leave you stranded while also eroding to various degrees those hardly ever mentioned attributes of access, control and consistent return on your own learning efforts ³.

There is no reason at all and no intention even for there to ever be just *one* client for Eulora2 or otherwise put “the” client. Currently there is indeed only one, for the very simple reason that I made it and nobody else made theirs. As a result, my client is and will remain the reference client but it’s still not meant to remain the only one. Quite the opposite, I’m open to any number of developers and/or maintainers of clients coming forward to make and promote their own versions, getting paid for it, too. The way I intend to set it all up, developers and maintainers of clients will get paid for their work based on how many users choose to run each developer or maintainer’s client and for how long, as all this information is directly visible from the serverside. While this is still some way into the future currently, count this as the heads up on it – you won’t be able to say later you didn’t know it or didn’t have time to get ahead of others with it.

As for the reference client that I made and maintain, I would recommend currently that you run it on one of Debian 8 (Jessie), Ubuntu 10, CentOS 6 or Gentoo ⁴. This is not because the client “requires” these or it can’t otherwise run in a different environment but simply because it is already known to run smoothly directly out of the box with as little effort as downloading and starting *one* single script that does it all. Of the four versions mentioned, I don’t have any particular favorites, as they all have their own specific pluses and minuses, but I’d say they are all fairly easy to try out, too. Depending on your machine though, you might want to pick one that plays more nicely along something else and possibly out of the list above, it’s Ubuntu that is more likely to do so.

As mentioned previously, currently the entry point for Eulora2 remains through interaction with those involved, on this blog or on others. And there is help available as well, just read around, follow the links and you’ll find both the people involved and ways to interact – it’s the meta-game, if you wish, happening in plain sight, even if it seems invisible to some. If it’s not invisible to you though, just make and pick your quest(s), explore it all leisurely and when you’re ready, start commenting and interacting with people, too, it helps. In short, ask and you’ll get an answer. Better yet though, ask a good question and you might just get more of an answer than you even hoped for!

1. More precisely, this means specifically that gcc 4.9 runs fine and the whole toolchain is not broken, either.[↩]
2. For all the quotes, operating computers is not even all that far removed from other types of operating that may be more familiar, since they all come, of course, from the more direct physical operation aka use of tools of all sorts – after all, computers are merely more complex tools, basically tractors for plowing the information bitfields, nothing else. For this same reason, operating computers has in common with operating any other tool further requirements that don’t get mentioned explicitly nowadays all that often, most notably the ones related to requiring some amount of study that actually pays off and offering full access and control over all its parts.[↩]
3. Convenience that caters to your lack of knowledge *always* costs more than is directly made visible and its hidden costs are quite often the ones that you’ll regret paying in the long term. Yes, it gives you a boost in the short term – quite often “now”- and it robs you of ~everything in the long term. At the very least it gives dependency, too. Just like any other drug of choice, you know?[↩]
4. For Gentoo, there is no versioning possible even, since it’s always and by design a sort of mix-and-match, so you’ll need to pick your versions of everything in there. There is however a neatly written summary of a successful install of Eulora on Gentoo, so you might find some help with it, if you ask there.[↩]

Promptly and on demand, that’s how things are moving in Eulora2. To wit, one day in Eulora2, the discussion turned suddenly and quite literally to the skies above and whether the speakers knew it or not, the demand was thus made and fully heard:

Diana Coman: what, does that sky look flat to you?!
Vivian Sporepress: haha
Vivian Sporepress: Diana Coman: certainly not flat, possibly not even any sort of crystalline sphere; it seems to have some axial tendencies, perhaps an ellipsoid; and I have no hypotheses yet for the nature or causes of its cloud patterns though they appear unchanging to the unaided eye
Vivian Sporepress Diana Coman: ah, the ‘axial tendency’ looks more like a bilateral symmetry across a vertical plane, suggesting either a peculiar optical phenomenon or a decidedly nonrandom process behind the cloud formation
Diana Coman Vivian Sporepress – well, the clouds have to fit the sky’s …geometry and that one is indeed quite regular
Vivian Sporepress Diana Coman: the geometry of the sky might not be possible to infer with the present euloran technology level, for instance a sufficiently large cube shaded just right can be indistinguishable from the inside from a sphere!

Finding itself under such interesting scrutiny, the sky clearly took notice. Only a couple of weeks later, among many other improvements and developments, there was also this confirmed change:

To be fair, there are quite a few other movements of things and of people happening at the moment in Eulora2, even if very little of it made it on to the blog. As always though, movement is the hardest to capture in pictures so the best way is to be there to see it happening as it happens, perhaps finding ways to be an active part of it as well. Second to being there, read along and comment underneath, perhaps, as I’ll aim to let it spill on to the blog in bits and parts at least from time to time, why not. There’s certainly plenty interesting and ready to move in there, from the multiple moons orbiting around Eulora2 and their impact on the grounds below, to the more prosaic issue of reconciling local movement with server’s view of the same.

The best part about it all is that the solutions, when found, turn out to be so easy to implement currently, given the supporting environment and a very much cleaned client code that it really doesn’t take long for something new to become visible in game once articulated clearly and meaningfully enough. This might change in the future perhaps but for now it is exactly so and turning gradually into a lot of fun, too.

How many other games do you know of, where truly all it takes to make a visible change is to speak up convincingly enough, without having to argue for it, without even having to frame it as a request? It’s enough to make sense and to pick at an interesting problem, that’s all.

This article builds up on the existing, well-iterated specification of the communication protocol, aiming to detail the new developments and to provide a place for current and relevant discussion going forwards. For the core structure of the protocol though, the linked article remains the reference and although the discussion of that part moves out of necessity here as well, I see no need at the moment to copy its content too. If your question concerns the parts that are not directly described here, simply link precisely the part you are talking about, as needed.

The first further addition to the communication protocol enables chat in Eulora2 and is currently implemented and fully working. Worth making it explicit and right from the start that the chat in Eulora2 is by default encrypted ¹ whenever in transit and effectively authenticated as well, as it fully benefits from the whole existing infrastructure supporting the game’s world ². The WoT layer that is currently in the works will further provide the means to seamlessly keep out any automated noise, spam and the like while simultaneously enabling all users to effectively retain both control and accumulating benefits for everything that they put into participating. To the extent possible, I fully intend to further align the incentives as much as I can to support meaningful conversations that are worth re-reading, too – without any unnecessary restrictions and with fully owned responsibility as well as benefits for each participant, too. It is to my eye the only way in which having a chat capability is even worth it in the first place.

To add the chat capability to Eulora2, there are two new message types added in section 4 (Serpent packets), to request and receive chat lines, respectively, as well as one new action type added to section 7 (Character actions) describing the “Say” action. Using the same specification format, the newly added sections are the following:

4.9 Line Request

• uint8 (type ID, =12), followed by
• uint8 (count of lines), followed by
• n times uint32 (id of chatroom), uint64 (lowest line number requested), uint64 (highest line number requested), followed by
• padding to Serpent-message length

4.10 Line Info

• uint8 (type ID, =13), followed by
• text (line content), followed by
• uint32 (chatroom ID), followed by
• uint32 (speaker ID), followed by
• uint64 (line number), followed by
• uint64 (keccak hash of the line’s content and number), followed by
• padding to Serpent-message length

Updated 30 Oct 2024: ratings are now fully integrated and used in-game, being fully handled via the relevant Rating node in the data hierarchy. Consequently there is no need anymore to have dedicated message types for discovery and retrieval, so the “rating request” and “rating info” message types below are removed entirely. See in any case the protocol specification for the full protocol.

4.11 Rating Request

• uint8 (type ID, =14), followed by
• uint8 (count of requests), followed by
• n times uint32 (source ID), uint32 (target ID), followed by
• uint16 (message count), followed by
• padding to Serpent-message length

4.12 Rating Info

• uint8 (type ID, =15), followed by
• text(rating comment ³), followed by
• uint32 (source ID), followed by
• uint32 (target ID), followed by
• uint8 (rating value ⁴ ), followed by
• uint16 (message count), followed by
• padding to Serpent-message length

7.9 Say ⁵:

• uint8 (type ID, =9), followed by
• text (line content), followed by
• uint32 (room ID), followed by
• uint64 (keccak hash of the line’s content)

7.10 Rate

• uint8 (type ID, =10), followed by
• text (rating comment), followed by
• uint32 (target ID)
• uint8 (rating value)

A line of chat in Eulora2 has a maximum length of 1445 characters. This is fixed and unchangeable as it is the maximum that fits in a 4.10 message (which has the least space for the line’s content out of all the messages relevant to chat lines and therefore effectively decides the *maximum* allowed line length). This limit is unlikely to be perceived all that often in practice but even if it is, note that it’s anyway more generous than most other existing chat protocols, irc included. Any client implementation is however entirely free to take its own approach as to how it handles this – whether it splits some user input into several lines if needed or whether it restricts input to this maximum of 1445 characters to start with, to give some concrete examples.

Beyond the above specific characteristics, for all intents and purposes chat rooms in Eulora2 are otherwise like any other game entities and thus the above additions to the communication protocol itself are both minimal and all that’s truly needed for a practical, working implementation. The speakers themselves are also characters (whether player controlled or not) in the game, hence fully described otherwise through the existing messages.

Messages 4.10 (Rating Request), 4.11 (Rating Info) and 7.10 (Rate) provide, respectively, a way to request and obtain from the server any desired ratings between two known entities in the WoT and to register/update one’s own rating of another. The comment part of a rating is meant to provide some context for the chosen value but as the value itself, the actual meaning and use is up to each individual and likely to be different from one person to another.

Worth noting that messages 4.10 and 4.11 are provided mainly as a basic and potentially last resort means of requesting and obtaining specific ratings. They are however quite unlikely to be the best choice for exploring or obtaining the full set of existing ratings, especially across a relatively large WoT, since each rating will require its own message and the traffic thus generated is to be paid for by the requesting client. A much cheaper and more convenient way to explore and update a local copy of the WoT will be provided in-game through an abstract object providing the full representation of the WoT in a single file and taking thus advantage of all the existing infrastructure, without requiring any new types of messages or other changes to the existing protocol.

Feel free to ask any relevant questions in the comments section below.

1. Serpent keys[↩]
2. Obviously, any of the users can otherwise make public the chat logs they have when and as they see fit but if you rely on something outside Eulora2 for that, it’s strictly between you and that provider, nothing to do anymore with either Eulora2 or the support and protection it provides.[↩]
3. Limited to at most 1445 characters, matching the maximum length of a chat line.[↩]
4. Valid rating values are integers between -10 and 10. For a given rating value here GR, the corresponding actual rating value RV is therefore calculated as: Min(GR, 20) – 10.[↩]
5. Note that this is an action and as such just a part of a 4.5 message, Client Action, where the overall message structure is specified.[↩]

~Referencing, of course, the previous version of EuCore and even that very beginning of creating a useful structure to it all.~

As I’ve opened up a test environment for helpful people to give a go to the latest client, they are likely to benefit as well from an updated and more comprehensive overview of the full client code, as an initial map of sorts, at the very least. So this is what I’m aiming for with this article – to provide an up to date map of the current client and a place for questions and answers on it all, in the comments.

While the previous article focuses exclusively on the EuCore part, meanwhile I really had to deal as well with the GUI part, as there wasn’t anybody else doing anything about it otherwise. So the GUI part got significantly trimmed, mostly overhauled and otherwise changed from inside out to provide the sort of flexible and reasonably structured functionality that I need as opposed to the assumptions-ladden and spaghetti-shaped sort of “service” that was previously available. As a result, out of all those half a million lines of code and countless files, there are now… 40308 lines of c/cpp code in total remaining. More than half of this (27584 lines according to a wc run currently) is in fact the only remaining sprawling mess that got now at least insulated in its own directory, namely the PAWS horror. In more practical terms though, there are 11 classes that are almost entirely re-written and make up the bulk working part of the GUI, 2 classes (one entirely new and one adapted) for providing the whole set of views, windows and overlays that Eulora2 needs and otherwise a bunch of the remaining “utility” classes that are quite often simply dragged in by various spidery includes of the PAWS variety. Here’s the full remaining tree of the GUI (ie the C/CPP part of the client):

~/client20/src/
├── client
│   ├── err.cpp
│   ├── err.h
│   ├── euaction.cpp
│   ├── euaction.h
│   ├── euloader.cpp
│   ├── euloader.h
│   ├── eumovement.cpp
│   ├── eumovement.h
│   ├── globals.h
│   ├── meshattach.cpp
│   ├── meshattach.h
│   ├── paws
│   │   ├── gameviews.cpp
│   │   ├── gameviews.h
│   │   ├── pawsborder.cpp
│   │   ├── pawsborder.h
│   │   ├── pawsbutton.cpp
│   │   ├── pawsbutton.h
│   │   ├── pawscheckbox.cpp
│   │   ├── pawscheckbox.h
│   │   ├── pawscombo.cpp
│   │   ├── pawscombo.h
│   │   ├── pawscrollbar.cpp
│   │   ├── pawscrollbar.h
│   │   ├── pawsframedrawable.cpp
│   │   ├── pawsframedrawable.h
│   │   ├── pawsimagedrawable.cpp
│   │   ├── pawsimagedrawable.h
│   │   ├── pawslistbox.cpp
│   │   ├── pawslistbox.h
│   │   ├── pawsmainwidget.cpp
│   │   ├── pawsmainwidget.h
│   │   ├── pawsmanager.cpp
│   │   ├── pawsmanager.h
│   │   ├── pawsmenu.cpp
│   │   ├── pawsmenu.h
│   │   ├── pawsminimalslot.cpp
│   │   ├── pawsminimalslot.h
│   │   ├── pawsmouse.cpp
│   │   ├── pawsmouse.h
│   │   ├── pawsnumberpromptwindow.cpp
│   │   ├── pawsnumberpromptwindow.h
│   │   ├── pawsokbox.cpp
│   │   ├── pawsokbox.h
│   │   ├── pawsprefmanager.cpp
│   │   ├── pawsprefmanager.h
│   │   ├── pawsprogressbar.cpp
│   │   ├── pawsprogressbar.h
│   │   ├── pawspromptwindow.cpp
│   │   ├── pawspromptwindow.h
│   │   ├── pawsradio.cpp
│   │   ├── pawsradio.h
│   │   ├── pawsselector.cpp
│   │   ├── pawsselector.h
│   │   ├── pawsstringpromptwindow.cpp
│   │   ├── pawsstringpromptwindow.h
│   │   ├── pawstabwindow.cpp
│   │   ├── pawstabwindow.h
│   │   ├── pawstextbox.cpp
│   │   ├── pawstextbox.h
│   │   ├── pawstexturemanager.cpp
│   │   ├── pawstexturemanager.h
│   │   ├── pawstextwrap.cpp
│   │   ├── pawstitle.cpp
│   │   ├── pawstitle.h
│   │   ├── pawstree.cpp
│   │   ├── pawstree.h
│   │   ├── pawswidget.cpp
│   │   └── pawswidget.h
│   ├── pscamera.cpp
│   ├── pscamera.h
│   ├── pscelclient.cpp
│   ├── pscelclient.h
│   ├── pscharcontrol.cpp
│   ├── pscharcontrol.h
│   ├── psengine.cpp
│   ├── psengine.h
│   ├── psmainwidget.cpp
│   ├── psmainwidget.h
│   ├── smgdata.cpp
│   └── smgdata.h
├── common
│   ├── placeholder
│   └── util
│   ├── command.h
│   ├── consoleout.cpp
│   ├── consoleout.h
│   ├── fileutil.cpp
│   ├── fileutil.h
│   ├── heap.h
│   ├── log.cpp
│   ├── log.h
│   ├── psconst.h
│   ├── pserror.cpp
│   ├── pserror.h
│   ├── psstring.cpp
│   ├── psstring.h
│   ├── psutil.cpp
│   ├── psutil.h
│   ├── psxmlparser.cpp
│   ├── psxmlparser.h
│   ├── README
│   ├── singleton.h
│   ├── stringarray.h
│   ├── strutil.cpp
│   └── strutil.h
└── placeholder

4 directories, 104 files

The main method is in psengine.cpp ¹ and that starts and initializes everything needed, then enters the loop provided by the graphics engine and at the end cleans up whatever is left. The first initialised is the graphics engine, CrystalSpace and that comes with its own “object registry”, configuration and initialisation dances that have been however trimmed to a minimum and corralled into a single method (and a single, shared configuration file, too!) that is hopefully reasonably easy to read. After that, the Ada part of the client, namely the EuCore library (see below for more on its role) is given the green light to start and provided all goes fine, the next steps are to simply initialise the GUI logic that is in psengine itself and then to enter the CrystalSpace loop that runs for as long as the game is running.

The GUI part has the following main components:

1. psengine – the central part that provides access to everything else and otherwise registers with the graphics engine to receive regular callbacks on events of interest. Such events of interest include each frame drawing and all user input. The callbacks on each frame drawing act effectively as a sort of heartbeat of the client as a whole and thus coordinating the different parts of the GUI. User input is generally received and then passed on to the relevant action handler (see euAction below) or to further potential handlers where relevant.
2. pscelclient – a class ² that is meant to keep track of and otherwise provide all logic and management related to game entities. This is one level above the graphics engine and acting as a sort of bridge between the data as obtained from EuCore and its translation into the graphical format that the user gets to see. So pscelclient uses what the graphics engine provides, asking it to create, move, change and delete any graphics in the game’s world to match the information it gets from the data available from EuCore.
3. pawsmanager – meant to keep track of and otherwise provide all logic and management related to “widgets” aka the various windows, views and overlays that make up the game’s interface rather than its world as such. This relies especially on the various views and overlays that are specific to Eulora2 and are defined in gameviews.h/cpp. This has most of the original mess intact but mostly sidelined and otherwise the useful bits and parts wrote in. The trouble cleaning this up is that ~all the paws calls back home to this and quite often with hardcoded include and calls too so it really wasn’t worth yet my time to clear it all up on top of everything else.
4. pscamera – a class that provides and maintains the available ways to view the game’s world as it is otherwise populated by pscelclient.
5. controlsManager – a class holding all the mappings of keys and mouse buttons so that they work as set in the configuration file and otherwise allow the user to provide input and interact with the game.
6. euaction – a hierarchy of classes that provide the required input, processing and output capabilities to enable the user to perform all relevant actions in the game. The central psengine initialises a full set of objects from this hierarchy and then simply passes on to the relevant one the request for execution with any parameters as provided by the user at that point.
7. euloader – a static utility class providing ways to create on the fly any graphics entity of the required type and using the assets indicated simply by a path. This includes creation of very simple elements such as textures but also quite complex ones such as animated characters that require a rather long list of calls to fully make when starting with just a bunch of files. While the creation of such graphics is quite tedious, at least it’s enough to have it packed this way once and then it serves endlessly, effectively providing useful defaults for all the “parameters” that aren’t actually needed or even known at start. The main user of this class is pscelclient.
8. smgdata – a static utility class that imports all the Ada methods made available by EuCore and wraps them up for transparent use by CPP code from anywhere else in the GUI. Basically all requests to EuCore are made through this class.

While the above GUI part focuses exclusively on the interaction with the user, it relies on the separate EuCore library to communicate with the server and to exchange and obtain all required data. The EuCore library handles everything in this respect, including creating a RSA-based identity and account, initiating and maintaining fully encrypted communication with the server, obtaining and updating all data related to the game’s world as available at different times to the player, retrieving from the server through the same encrypted communication any missing files and managing existing local files including their use as temporary defaults when needed and where appropriate. The full EuCore weighs in at about 27000 lines including tests and the mpi part that has about 8000 lines of code by itself. Here’s an updated full picture of all Ada package dependencies:



Compared to the previous version, there is a striking change at the top where EuInterface is now the “entry” package instead of EuCore. This reflects actually better the meaning of the two packages and by now the whole code matured enough so that the refactoring was quite obvious, too. Basically EuCore is the starting package for the whole library, while EuInterface literally provides an entry point for any C code that wants to use the library and this includes now the previously missing C-compatible wrappers for EuCore’s Start/Stop methods themselves. Thus any Ada code that uses this library can entirely discard EuInterface and just start with EuCore, while any C code using this library goes entirely through EuInterface and doesn’t need to see or know of anything else.

Further comparing with the previous version of EuCore, there are also a few new packages, most notably Mgm_Cache that comes now between Heartbeat and EuCache, as well as C_Buffer at the very bottom. The C_Buffer package is literally for interfacing with C code so that Ada code can take advantage of faster writing to files mostly. The Mgm_Cache package does what the name suggests, namely provides the higher level logic to oversee the data cache that is EuCache itself. In fact, the Heartbeat package serves as on overall coordination mechanism across the whole of EuCore and as such it effectively provides regular calls as required to various parts such as the communication link (Comm_Link), the data cache (EuCache) and the assets downloader (Torrents). As the communication link is both the most critical and the most demanding component of these, the Heartbeat really grew first of all as a manager of Comm_Link and only once that was fully working the rest could be developed as well. At the moment, the management of EuCache grew big enough to make sense to extract it in a separate package of its own but otherwise I don’t see a lot of benefit in doing the same for Torrents for instance.

Note that all dependencies in the graph above remain hierarchical as they should always be. The automated layout of the graph tends to make it look as if there was some nonsense going on perhaps with that seemingly horizontal line going from OAEP to Keccak, but that’s just an artefact of positioning. In reality, Keccak is on a lower level than OAEP, being simply a hashing utility, although one that is most useful indeed. At any rate, OAEP uses Keccak and there is no dependency going the wrong way, as Keccak itself uses only raw_io and raw_types.

Hopefully this gives enough of an overview to have some idea as to what is where and how the whole fits together. If you have though further questions on it, feel free to ask in the comments below and I’ll gladly answer.

Finally, if you made it all the way here and would still rather see a less schematic picture as well, here’s a fresh one of the client in action at a meeting of like-minded creatures of Eulora2, surprised as they were by all the screenshooting commotion:



1. Despite the name of the file and of the class, there is very little indeed left in there from the original code. I suppose I could have changed it all to euengine or something more appropriate but given how it’s one of those included from just about everywhere due to the original “design”, I didn’t really consider all the resulting noise worth the trouble.[↩]
2. This is also mostly re-written with only very little indeed remaining of the original “gem” pain. It could still do with a haircut at least, I’d say.[↩]

The prize for having a clean environment (not merely code, nor even limited to code) is refinement of precisely the most intellectually pleasing sort: getting to uncover and solve interesting as opposed to tedious problems. In other words and as far as I can tell from direct experience, even coding really doesn’t have to be at all “like plumbing” if the sewers are properly cleaned and it doesn’t have to be sterile either if the willfully blind focus on idealia is discarded. In a reasonably clean – not perfect, nor even “best possible” – codebase ¹, there is both space for experimentation (aka introducing new things) and support for refining existing solutions. Arguably, there is even space and support for literate collaboration but this does tend to grow more slowly being as it is a fully organic culture in its own right. There is time, there always is… until there isn’t.

The most recent concrete example of what made for me quite an interesting problem brings together knowledge representation, data caching, remote synchronisation over a lossy channel and even matters of time representation across different contexts. Then again, arguably one’s problems can only get as interesting as one is able to make them to start with so perhaps it’s all tailor-made indeed. Either way, I’m neither boasting nor complaining, merely describing so here’s an attempt to sketch out the problem in its context:

1. The game‘s client has to obtain, maintain and represent (including graphically but not only in such form) as accurately as possible the knowledge of the game’s world as accessible to the player and as it continuously changes as a result of the player’s own actions and as a result of others’ actions or even simply the passage of time. In all cases, the actual changes are not known upfront nor automatically obtained – while the server decides at all times what and how is in the game’s world, it’s entirely up to the client to *ask* for whatever it wants, whenever it considers it needs it. Quite on purpose, there is no information pushed from the server to the client at any time and although all questions receive an answer, there is no guarantee that all answers make it back to the client in any given timeframe or even at all. Hence, the problem here is to find an effective way to find out as quickly as possible all that is new but also, arguably even more difficult, what has become obsolete! And possibly the most difficult part here is to even define what “quickly” means since there are at least several definitions of time itself in this context: the user’s own time, the time in the game, the time as kept by the client, the time as kept by the server. What does “quickly enough” mean and when is something “too old” or even obsolete? What is the meaning of “1 second” in the game-world, what is its meaning on the network and how does one reconcile these two?
2. The communication protocol defines the rules for a hierarchical structure that provides effectively the support for representing all the knowledge mentioned above but this structure is an ever-evolving one and with no specific limits to either depth or breadth at any given time, beyond a basic “it’s always finite” guarantee. Moreover, any request comes with a cost and that’s not even limited to time – arguably the resulting traffic is costlier, both as it *is* going to be included in the bill the user pays in one form or another (most likely directly wired into game mechanics) and as it can easily have undesired consequences clogging the client’s communication pipe for instance or even… triggering undesired changes because yes, in some cases, merely asking for something means that something will change ². Hence, the direct, brute-force approach of “explore the whole knowledge tree at regular intervals” is not much of a solution to anything or not a long-term one, at any rate. And if one doesn’t explore the whole of it then how does one figure out the holes in one’s knowledge, those things one doesn’t even know yet one doesn’t know?
3. The desired graphical user interaction (GUI) clientside adds some potential troubles of its own since it’s quite difficult to provide meaningful immediate feedback to an action when its actual results require in the best case a confirmation from the server (when guessed correctly) and in the worst case a search for and figuring out of how the world changed (when the guess is merely incomplete perhaps, although it can even turn out to be entirely wrong). Sure, one can *hide* this and pretend that everything is known upfront, arguably making it thus more convenient or something of the sort but pretense aside, the reality of it is simply that the GUI is at best twice-removed from reality and as such always kind of struggling behind: the reality it can directly access is at best a local cache and that cache is in turn at best a fragment (perhaps already obsolete in places) of the remote world that is at all times on the server and ever evolving even there ³. So how can the GUI be as truthful and responsive as possible when providing the user with a representation of the game’s world, without limiting them either? Because the whole point of a GUI is to enable, after all and moreover, the game itself is quite on purpose as open as possible – the scope of what one can do depends on what they have already done, not on some predefined and fixed laundry list that some uppity GUI takes upon itself to enforce on behalf of the server.

The above is the overall shape of the problem and as complex or “that’s not how these things are done” as it may sound, the core of it is already solved and working in practice. What still remains to be done, is really the refinement of this core of a solution. How interesting and rewarding such refinement turns out to be or not depends mostly on the person asking and working on it, as always.

As for myself, I certainly have even more interesting problems to solve on the serverside so I don’t particularly intend to pursue more than absolutely needed anything clientside. The client is open source after all and it will only ever be as good or fit for your own purposes as you make it to be. Does this sound like a downside or an upside to you?

1. It’s always improving though and the cleanliness really has to do with how supportive of improvements it is, not really with some perfection or best anything. First of all, lots of requirements, constraints and even actual extent of the problems to solve got clearer only with practice and the corresponding code reflects this. Second, I learnt a lot in the process too and this also shows – yes, the 2nd time one does something it will probably be better done than their 1st and the 100th time even better than that. Cleanliness though doesn’t mean nor require skipping the first step nor the first 99 – that’s just a way to get stuck and it’s still silly even if very common – but simply creating that path that enables all the steps that may still come. So no, there wasn’t nor is there some perfect anything, code included, to be “fully solved” or achieved in some entirely ideal form and then either worshipped or blown to pieces, depending on inclination. There’s only sustainable growth, gathering up momentum and opening up new possibilities as it evolves, that’s the best possible meaning of clean – it enables the growth of new animals and plants, not that of new fungi.[↩]
2. Does it ring a bell, at all?[↩]
3. Are you *sure* that this is all that different from the actual “reality” of what you see with your own eyes even when no computers nor games are involved as such?[↩]

Like everything else in Eulora 1, the tips greeting newly connected players brought new life to an old form, generally turning common and stale anything on its head quite irreverently and with great effect. Since some of these tips still get quoted at times, I’m publishing my list of them here for vicarious enjoyment and, possibly, for easy reference as well:

1. Welcome to Eulora! May your stay be preposterously prosperous.
2. Do not think of yourself as an ugly human. Think of yourself as a beautiful monkey.
3. The early bird gets the worm, but the second mouse gets the cheese.
4. Better late than pregnant.
5. You should probably do the laundry…
6. Silence is golden, but duct tape is usually silver.
7. Time flies like an arrow, but rotten fruit flies fly like flies.
8. Everyone has a photographic memory. Some just don’t have any film for it.
9. Mr. Spirover maintains a positive attitude, even though he knows it won’t work.
10. If the shoe fits, get another one just like it.
11. You can’t have everything – where would you put it?
12. All things nobody else wants come to those that wait.
13. A fine is a tax for doing wrong. A tax is a fine for doing well.
14. In Eulora, it does not matter who is right, but who is left.
15. The best space shuttle is but a large pile of chairs for the head.
16. Happiness is having a large, loving, caring, close-knit family in another city.
17. Fear not your own death – just try to not be there when it happens.
18. Learning is not compulsory. Neither is survival.
19. There are no rules here – we’re trying to accomplish something.
20. Oh, the Vinu will love you. There is no sincerer love than the love of food.
21. Anything that is too stupid to be spoken is sung.
22. The first rule of tinkering is to save all the parts.
23. Some are wise; others are otherwise.
24. The bonds of matrimony are like any other bonds – they mature slowly.
25. When a NPC marries, it exchanges the attentions of many players for the neglect of one.
26. The most you can hope for is ending up with the right regrets.
27. Everyone started out with nothing. Plenty still have most of it.
28. An unbreakable toy is still useful for breaking other toys…
29. Does the name Pavlov ring a bell?
30. The best way to lose weight is to eat naught but inspirational posters.
31. Old eggs are generally rotten; old hopes are generally delusions.
32. To find out just how windy it is on the hill move there to escape the damp in the valley.
33. If you fail to spend enough time laughing at stupid children, you will spend all your time going to war with stupid men.
34. Your worst enemy has always slept in the same bed as you.
35. The minnow aspiring to be a whale was stuck in a puddle that did not aspire to be an ocean.
36. The best things in life are actually quite expensive.
37. All tattoos are temporary.
38. The secret of teamwork is that none of us is quite as dumb as all of us.
39. Hard work pays off in the future. Laziness pays off now.
40. The power of accurate observation is commonly called cynicism by those who have not got it.
41. By the time you swear you’re his, shivering and sighing; by the time he vows his passion is infinite, undying… better make a note of this: one of you is lying.
42. A cynic is that unrepentant blackguard whose faulty vision sees things as they are not as they ought to be.
43. The world keeps ending, but noobs keep showing up as if the fun just started.
44. The large print giveth and the small print taketh away.
45. The worst misfortune that may befal your enemy is a large following of true believers.
46. Poverty is the sort of suspect virtue one can very readly teach oneself.
47. Rejection of praise is sometimes humility and some other times holding out for better praise.
48. It is comparatively easier to make heroic gestures than to abide by the results.
49. When logic leads to any humiliating conclusion, the human reaction is to discredit logic.
50. The strongest indication that you lost your way is to find a large majority in agreement with you.
51. Out of the mouths of babes come bubbles.
52. The best possible world is the one you can’t live in.
53. True democratic feeling is reserved for drunken men.
54. If you can make a woman laugh, you can make her do anything.
55. What will retrospectively be called will always finds a way.
56. Most people love because they tried hating and found it requires too much effort.
57. The very essence of romance is uncertainty.
58. Man may have discovered fire, but women discovered how to play with it.
59. Thread carefully when the nude offer to sell you shirts.
60. Love at first sight is common; love at last sight is comparatively rare.
61. Love cautiously, enjoy vicariously, dream reasonably, tread lightly and die quietly.
62. The trouble with being poor is that it doesn’t allow getting into any kind of trouble worth the mention.
63. Gravitation is not responsible for your great tumble – after all it tried to prevent your climb every step of the way.

It has meaning. As it brings to life a fully working and fully interconnected environment where *nothing* is created out of thin air or without clear, mathematically defined causes and consequences, each and every action done (or avoided) in the game *means* something – in other words, it… matters! Yes, it matters and means something first of all within the game itself but that’s no hard limit in any way and moreover, even considered solely within the game, it still means way more than it might seem at a first glance. This is not by accident and what follows might give some solid pointers as to why and how, so read on.

It is practically infinite in more than one dimension. To give just a few examples ¹:

• Your exploration generates (on demand!) new maps and there is more scope for such distinct maps than you can cover in a lifetime. So step in and see the world expand as you explore further and further. As you explore, note also the resistance of the medium, not constant but related to you and to your actions, ever present and ever giving meaning to the choice of the next step, because your exploration in this game *is* creation and not just a meaningless stroll through the endlessness. How far will you go and what will you create?
• Your crafting, exploring, fighting, child rearing and various other game activities generate new items (and this means all sorts, computer controlled characters included) and the scope for these, too, is wider than you can cover in a lifetime. While the potential items are practically infinite, it’s your actions that pick from this infinite potential some specific item and then bring it into being. If you don’t act then no item will exist at all and the potential will remain just that, a waiting but never manifested possibility. So what are you going to make and who will you meet?
• Gains are potentially infinite, too, as they aren’t capped at any random value, nor forced into any sort of artificially diminishing returns model. The only limit, here as everywhere else, is the player’s own capability and otherwise the whole of what there is in the game, nothing else. How much can you gain and what is your gain even going to look like?
• The intricate connections and complex underlying laws of the game’s environment are statistical in nature and never directly exposed but ever present through their effects – or more precisely said, through what you are able to observe of them and, moreover, how much you are able to make of what you observe at any given time. How much of it all will you observe, how well will you understand it and what are you going to do with that knowledge gained?
• The game promotes creativity ² and it rewards applied, practical learning with full freedom of choice as to direction or means. The game’s environment reliably provides feedback and the unbending structure to test your hypotheses (and your mettle) against, while allowing otherwise any and all approaches you can come up with. Who will you turn out to be?
• The game provides opportunities for meaningful action well beyond playing. The only limit with respect to opportunities available is defined by the players themselves, as they can literally interact with the game in any way and to any extent they want. From building up their own town and governing it the way they see fit or setting up shop somewhere in game to making their own client or their own graphics to be used – whether for free or for pay – by other players, the game’s environment simply provides just the right amount of structure to support it all but no restrictions as to what “should be done” or not otherwise. What do you want to do and how well will you do it?

All the above combined mean that it is your actions, observations, data gathering and even client development or meta-game that increase both the richness of the game’s world and your practical, applied knowledge that is not even limited to playing the game itself. In this sense, too, the scope is wider than you can cover in a lifetime. In this game, like in no other but exactly as in life, you can never really step in the same river twice. No “walkthroughs” and no “cheat sheets” can ever “solve it all” (aka spoil it all) for the next player who is neither the exact same as the previous player nor in the exact same place or time as them, nor even interacting with the game’s world in quite the exact same way. Your character in game ages and dies, too, and their children may continue so that your own experience of the game is ever changing and your play literally writes the history, whether through small or big deeds, still writing nevertheless. What part of the game’s history will you write?

“And will this game happen?”

“By itself, you mean?”

1. For more on it all, see for starters the S.MG category on trilema.com, the Eulora category on this blog, quite a few of the articles in the trolloludens category on trilema.com as well as various other articles that are quickly found if you follow the links.[↩]
2. Creativity is, at core, a successful cross-pollination (or weaving if you prefer) of sorts, the result of making viable new links between matters that had seemed until then separate or at the very least evolving independently, each in its own direction. As such, discipline, structure and a solid knowledge of many different fields are the support and ally of creativity, not at all a barrier or the enemy as they might seem at a superficial look.[↩]

The initial work only expanded in scope in the intervening years to the point where it ended up covering pretty much everything, from end to end encryption, rsa-based authentication and a new protocol for client-server communication, to flexible file transfer torrents-style, a full graphics pipeline operating on demand, user interaction (both GUI and CLI) and various intricate mechanics that I won’t even start detailing here if I am to keep this introductory paragraph from taking over the article whole. Nevertheless, as all this extensive ground has been covered in at least one fully working iteration and the swamps have been all but drained, the core structure is now reliably in place and so the time has come to document publicly at least the very Core of what will be the most widely available part of it, namely Eulora’s Client.

Looking at the dates, I notice only now that it’s almost exactly two years since I published the first version, higher level map of client’s core. It’s been two very productive years though, so that almost all of the User Interface part got trimmed to a more reasonable size, eviscerated and squeezed like the paste that it was into usefulness, while the Core part grew into providing full services on top of the barebones, raw elements that were originally listed.

The client’s Core is still a library but it has a clear single entry point in the EuCore package that manages all the various parts and provides the means for a C/CPP main to start and stop the whole in a controlled manner, without being otherwise aware in the least of any of the Core’s own internals. Basically EuCore serves as a control interface, ensuring that even a C/CPP main can take advantage of Ada’s neat mechanisms ¹ for clean and tidy multi-threaded execution. On receiving the signal to start everything, this control interface initializes (aka asks them in turn to load whatever they need from the shared configuration file, already) and starts all the components that it manages. On receiving the signal to stop, EuCore passes it on to each of the components it manages and otherwise doesn’t have any qualms about killing off (via abort) if and when required any tasks that can’t or won’t stop in a less abrupt manner.

The most important components managed by EuCore would be, from the lowest level up:

1. The sender/receiver tasks for RSA and Serpent packages simply provide in-memory queues that can be made therefore larger than the IP stack provides otherwise, for both outgoing and incoming UDP messages so that losses are kept to a minimum and callers from the rest of the code don’t need to wait. They are both based on the same generic Snd_Rcv package simply instantiated with the corresponding package size.
2. The Comm_Link package handles all the practical details and inherent complexity of keeping in sync over a lossy communication channel. This includes keeping in sync the two buffers of Serpent keys as well as providing everything required for overall key management. While this sounds little, in practice it’s quite the opposite of little, no matter what you measure there. Note that this package provides everything required and handles its own internal logic but does not attempt anything beyond its station – the higher logic for communication management simply can not be at this level and so you’ll find it in HeartBeat, further down this list.
3. The EuCache package maintains and provides access to the knowledge tree of the game’s world aka that boundless although finite data hierarchy. The role of EuCache is that of a librarian essentially: it accepts all new data as it becomes available, it integrates it with what it already knew and it aims to provide on demand more than just the raw data since raw data is rarely directly useful as such. What is more useful instead and what EuCache aims to provide in addition to the raw data is at least one level of integration on top of it, basically trying to take any useful tiny steps that it can towards that ideal known as knowledge. How far it gets and therefore how useful it turns out to be depends more on you and what you figure out to ask from it in due time. For now and for starters, the possibility is there, the examples are also there, the rest remains up to you.
4. The Torrents package handles the rough as well as the fine mechanics of file assembly, storage and access. This includes receiving and fulfilling requests for retrieving files (whether local or remote), handling all the different bits and pieces of chopped files as they arrive over the network, checking each of them and asking for any corrupted or missing parts, as well as assembling the full file, storing it in a convenient manner (currently neatly ordered by type) at the path specified by the user in the configuration file and pointing any caller to the exact path for any specific or default file ², as requested.
5. The HeartBeat package coordinates everything in Core at regular intervals. This contains also the higher level logic for it all, since that requires almost always repeated and/or time-based decisions, from requiring an update of the world’s data to repeating a request that is still pending or deciding on resetting the link entirely when no other measures manage to recover the synchronization with the other end.
6. At the outermost edge of Core, the EuInterface package wraps up and exports with the C convention (so that any C/CPP code can use it directly), all the functions and procedures that modules built on top of this Core may use – from asking the server for assets or information to sending back to the server any of the user’s actions and everything in between, even building up and accessing a full local history of all user’s console commands.

In addition to the more prominent packages briefly described above, there are also quite a few utilities packages that provide a common language of types used across the whole Core lib as well as the lower level tools required and employed by those higher level packages. At the very base of EuCore, there is thus the Raw_Types package that all the others rely on, since it defines all the data types required by the communication protocol, as well as structures, subtypes and conversion utilities that rely on these types and are widely needed otherwise for various mechanics. On top of Raw_Types but focusing on structures and utilities supporting knowledge acquisition rather than the low level protocol mechanics, there is Eulora_Objects that provides for instance the records and hashmap types for storing any euloran object as well as the full known hierarchy of the world at any given time.

In between the above two data structures packages and the higher level packages listed previously, there is a middle layer of tool providers basically, from simply logging something or obtaining raw octets from the currently set source of entropy to Keccak hashing, RSA-OAEP encryption or message packing/unpacking and checking.

A full graph of the dependencies between all the Ada packages in the client’s Core current version shows quite naturally the top (EuCore) and bottom (Raw_Types) two packages as well as the strictly and clearly hierarchical structure overall: while there are indeed many links between packages as they are rather intensively working together ³, there are no cycles and moreover, no dependencies going the wrong way, meaning from bottom to top. All the links go clearly and as they should, always and forever from top to bottom (the red rectangle surrounding Keccak is there simply to mark that Keccak-Hashing is its child package):

1. Core’s code currently makes use mainly of protected objects and task types/variables.[↩]
2. Eulora’s client will be quite independent in deciding what it uses as defaults for any and every thing. There are no externally imposed or defined defaults because that doesn’t solve anything since one can then simply not have the officially declared defaults and so what is that supposed to solve really, you’ll end up with defaults for defaults or what exactly? So the cut made there is deeper but cleaner: the client will simply pick as default the first (as in oldest by its own timestamp) file that it has for each type and that’s that. Yes, this means that different clients can easily have different defaults and it also means that you can even pick your own defaults if you care – just change the timestamp for the file you want so that it’s oldest and that’s all.[↩]
3. Yes, they *could* be further separated but at *the cost* of additional significant verbosity that really doesn’t make anything clearer nor easier to follow – there is nothing “easier to follow” in introducing a few layers of indirection in there just to provide separation that otherwise is not really meaningful nor needed in any way.[↩]

This past week I worked on a significant refinement of Eulora’s data hierarchy, that core structure used to fully describe for the client the game’s endless, complex and ever-changing world. As it happens, this refinement was made possible as a result of a lot of previous work ¹: having recently gained full control over the creation of all graphical elements as I successfully grew my own mountains alongside GUI elements and literally everything else involved, I was also finally able to break up into more useful pieces and ultimately get rid of that sore anomaly of an “Outdoors” object that had previously catered to the requirements of the now-discarded “terrain plugin”.

For the easy part in getting rid of that bulky and spurious “outdoors” object, I had at least already in place the natural building blocks that would get used, namely the CSModel object as well as the ways to position and even name it, if desired. Even so, a change such as this, touching as it does the game’s own way of structuring knowledge essentially, can never be a very easy thing to get right, as there are many different connected pieces that have to fit – at least to some working extent – at all times. So I was a bit apprehensive about the amount of work it might end up requiring in practice and I made therefore a padded estimate of the time it might all take.

At first, I made the needed changes on serverside, where everything is defined and created in the first place anyway. There was initially more work than expected, indeed, but mainly as a side effect, a sort of slightly hurried growth, rather than anything else: while the change to the hierarchy itself was quite straightforward, the details pushed into being other parts that weren’t yet quite ready otherwise, although they were somewhere further down on the list for later, anyways. So I took more time than I had initially estimated to design and then add the needed embryos of these parts too, even though they still miss a lot of other parts that they in turn require and as such, they are sure to further change as they develop. This is expected and unavoidable though – it’s how everything else on serverside currently came into being as well, after all.

As the serverside work stretched even beyond my padded estimate for it, I was increasingly thinking that I’ll have no choice but to revise the overall estimate entirely, as the remaining time for the whole clientside work shrank and shrank. But then, when I finally got to update the data hierarchy in my own EuCore component on clientside, there was indeed very little required: simply the addition of the new object types, the deletion of the old one and a few updates (flagged automatically, too!) to take them as well into consideration when looking for broader categories such as “graphics vs non-graphics objects”. The rest of it – and moreover, the *more significant* and difficult rest of it simply worked and not by accident either: it was simply my previous design and implementation of both EuCore and its interfacing with the GUI saving me days of work now, as it handled entirely new types without skipping a beat and without requiring otherwise any change *at all*. How pleasant is this as code to work with and when exactly is the last time you encountered such ease when making significant changes to the code you are working on?

The second code change that made its way onto my list this past week was in principle a very simple thing to do, clientside entirely: as the water was now simply a CSModel like any other item in the world, it ended up nicely rendered but nevertheless surprisingly…solid, despite the data hierarchy otherwise holding enough information as to its “water” nature. In other words, there was clearly a need for the GUI part of the client itself to become a bit more discerning and create water as water (not solid and also reflecting things around, for instance). Since I had already written the code that successfully created water as such, this change was in principle just a matter of adding and using a flag, nothing more.

In practice though – in hindsight unsurprisingly, as it touched the remaining PS code – the simple change turned out to be not that simple and especially not as straightforward as expected: first, the water was rendered reflecting quite nicely everything around, so that it was clear that the discerning part worked as expected but… this “water” was still a solid, more like frozen ice perhaps than any water. Then it all got even more puzzling: the water was still solid *despite* my loader specifically *not* setting collision detection on it (in graphics terms, this solidity is simply a matter of whether one bothers to check /enforce any bumping into the object in question or not). Moreover, this unexpected solid was not even reliably solid but rather a weird half-assed sort of solid: one would walk on water indeed, for all the incredulity one might have as to the possibility of such feats but then, unexpectedly (a loss of faith, perhaps – whose faith, though?), one would sink deep into it and then… oh, then, one would get *stuck* in there, too, unable to move in any direction, if able nevertheless to spin as much as desired! Basically I had inadvertently created in there a sort of treacherous quicksands for all their watery looks otherwise.

Both the cause of and the resolution to the above unexpected wtf turned out to be of the same sort as previously encountered: the cause was a remaining bit of planeshift code and the resolution was to discard it entirely. Basically there was a spurious “psSolid” wrapping of the engine’s own collision detection object doing nothing other than getting in the way – it literally added *nothing* of its own other than the perpetrator’s name at the top of the file ² and otherwise another indirection layer in the way of anyone trying to make sense of the code overall. On top of this, some other bit of remaining PS code *also* took it upon itself to decide and add this half-assed psSolid thing to *everything* that went through it, just like that. As a result, there was this funny situation where simply bypassing it all solved the problem entirely – as usual, not playing along with the stupid has this magical effect of making all sorts of problems just… disappear. So I further deleted some of the increasingly less but sadly still remaining PS code and as a reward for it, I had my water being water again, nicely yielding rather than solid and otherwise letting one freely move through it at all times, instead of randomly trapping unaware swimmers in it.

Having previously trimmed and trimmed again at these same planeshift tendrils, this latest trim was otherwise quite effortless too, basically a very pleasant and rewarding way of improving the code from all points of view. How is this for coding work – effortless code *reduction* for added benefits and increased functionality, too. How does this compare with your current coding work and experience as to what coding even involves, hm?

1. This most recent work merely added, in turn, on top of full years of cleaning up all sorts of strata upon strata of a huge mess.[↩]
2. And I have to say that by now I had even guessed correctly the exact “author” name in that file, despite there being quite a few names scattered otherwise around the CS and PS codebase, you know?[↩]