Michi (molp)

In the previous week's devlog #547 I presented the idea of a NEWS command. It was just a rough sketch and I found some time this week to make some progress on it. Here is what it now looks like:

The news command is now based on in-game events and manual additions. Right now we have the following news types:

• Devlog and economic reports: These two are added by the team manually whenever a devlog or economic report is published. Clicking on them will open a new EXTLINK buffer that leads to the blog or forum.
• Naming: I already covered them in last week's devlog. The news item tells what planet/system was named by whom.
• Colonization: The first base on an uninhabited planet will trigger this news event. If a planet has been deserted for over a year and someone settles it again, that will also create the event.
• Population: Once a planet's population has its first engineers and/or scientists, a news event will be created.
• Infrastructure: The completion of a planetary project creates a news event.
• Gateways: Once two gateways are linked, a news event will be generated mentioning both gateways and planets.

I also added a filter section at the top. It will allow filtering events based on their location in faction space. If a news event happened in faction space it will have a small faction badge to its right. Events outside faction space and events that don't have a location, like devlogs for example, won't have that badge. The filters are persisted on the server. They will also influence the indicator in the top bar that tells how many unread news events there are.

Here is a short video of the filters in action:

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

Fabian is back from vacation, so it was time to deploy the routes feature to the test server for him to have a proper look and give feedback. That also means that Star-tier supporters and above can try it out. Ship speed on the test server is vastly increased currently, making it easy to watch the entire route being executed within minutes. If you have any feedback, please let us know.

I also added a handbook page for the routes feature that mirrors its current state of implementation.

Our current plan is to ship the routes feature as a named release later this year, once it is stable. It will be accompanied by a few bug fixes and tweaks.

While I wait for feedback, I have some time to work on smaller issues and features. One command we have always wanted is a global (universal?) NEWS command. It should work like the notifications NOTS command and show a list of important events. As a proof of concept, I implemented planet and system namings as well as first colonizations of planets. Here is a work-in-progress screenshot:

As you can see, we envision a new indicator next to LIC. It will show a steady (non-blinking) green light while there are unread news items. We also want to add a few simple filters that let you narrow the list down to the news types that interest you. One difference from NOTS is that parts of a news item can be clicked individually, for example to open the USR command.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

The work on routes progressed well this week. I was able to implement the remaining steps and even a pair of steps that weren't part of the game design document.

The load and unload steps are now functional:

Each of these steps lets you define a material, as well as a minimum and maximum number of units that should be transferred. For a load step, setting the maximum to "capacity" will load as much as fits into the hold. Conversely, for an unload step, it will try to unload as much as possible, limited only by the amount carried and available space at the waypoint. Similarly, a minimum set to capacity will try to fill the entire cargo hold. If for any reason a load or unload step cannot be executed, it will be marked as blocked. Once the required materials or room becomes available, the step will be executed.

I also added a simple wait step that just waits at a waypoint for the specified amount of time.

I imagine that the wait step could be improved in future releases by providing more options than a simple timer.

The game design document for routes was only specified for materials, not shipments. But it didn't feel right to leave them out. So I added another pair of steps:

The load shipment step will try to load as many shipments as possible that are to be delivered to any of the following waypoints. The ones with the shortest deadline will be loaded first. If the route is looping, it will also load shipments for the waypoints that came before the current one, so they can be delivered in the next execution of the round.

The unload shipment step will just unload all shipments for this waypoint, given there is enough room at one of your stores at the waypoint. If a shipment cannot be unloaded the step will be marked as blocked and automatically executed once there is enough space. Alternatively, it is also possible to fulfill the delivery condition to move the shipment to the recipient directly.

The shipment steps do not interact with the contract system. You will have to fulfill the pickup and delivery conditions yourself.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

This week I was visiting simulogics HQ. Usually Martin, Fabian and I use these rare in-person meetings to talk about technical topics and game design, but this time we welcomed a new team member. Ipek joined simulogics as an intern! Welcome! She will work on an AirlineSim map feature, and you can read about it in AirlinSim's weekly devlogs.

I spent the remainder of this week on smaller issues.

The server project of Prosperous Universe now has roughly 1200 automated tests in its suite. They range from small unit tests to larger actor tests and even full integration tests. A unit test covers a very small part of the code base, for example making sure a behavior like the fleet behavior correctly processes certain elements of space flight. Actor tests are way larger: They spin up a test universe with a handful of systems and their corresponding planets. They can be used to test the behavior between entities within the game. A typical use case is for example: start the world, set up a company, gain PRO license status, build an admin center, run for office, vote and make sure we actually become a member of parliament. Integration tests go even further and spin up a database, so we can validate that the correct data is written to the database. We use them very sparingly though.

As you can imagine, the actor tests, while extremely helpful, take quite some time to run. On my development machine the whole suite takes about ten minutes to run. In and of itself this wouldn't be a big problem: I can just run the few tests that belong to the feature I am currently working on, but eventually I want to check that I didn't break anything outside the feature's scope.

So I took the time and dove into the performance of the tests. I was able to reduce the runtime to about five minutes on my machine by optimizing test-related settings and reduce polling retries. For example: an admin center tries to determine its currency once it is built. If the first try doesn't work, it'll retry five seconds later. On production that is no issue, but potentially waiting five more seconds in every automated test that contains an admin center quickly builds up. I was also able to fix a handful of flaky tests that failed sporadically.

I also looked into the INFL command again. There was a discussion on Discord a few days ago, that the inflation reports are off. It seems that a clearing of the order book caused a massive spike in the inflation data and on the next day the prices went back to normal. Since the weight of a period (day in that case) was based on the trade volume the spike disproportionately increased the inflation values. Even when prices went back to the previous level the next day, that period has a much smaller weight, because it didn't have that volume behind it. The change I made, and this is already live in production, is to not use the period's trade volume as a weight, but rather a sliding window of the last 30 days' worth of trade volume. This should buff out these huge spikes. The change was applied retroactively, so the spike from last week should be gone now. Check out the INFL command and let me know whether you think it more accurately represents the actual inflation.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

The work on routes continued this week. I implemented a new command (RTE - route executions) that keeps track of all ships that are currently assigned to a route. Here is a first draft of that command:

For each ship that is assigned to a route, it shows the route, its status, progress through the route's waypoints, current destination and current step. I added a small indicator so it is immediately visible if the route execution is blocked by something. In that case the indicator will be yellow. In other cases it'll be green. As usual the list is updated automatically as the execution progresses. Clicking on the ship's name will open the RTE command with that ship's transponder code and show a more detailed view of the execution:

In the upper section we have the same information as in the list view, but with an additional flight field. Clicking it opens the ship flight controls SFC and thus the current flight of the ship. The progress section is a similar to the route editor, but without the buttons to actually edit the route. An indicator on the waypoints and steps shows where the execution is currently at. Right now the command doesn't really tell why a route execution is blocked, it could be missing fuel for a flight, no funds for a gateway passage, not enough fuel to refuel, etc. I am pretty sure that we can make this more specific in the future.

I also implemented a lot of smaller details, for example: the normal ship controls, like aborting a flight, setting 'unload on arrival' etc., will not work while a ship is assigned to a route. Additionally routes now loop, if the corresponding flag is set for the route. If a user loses PRO status while a route is being executed, the route will finish the current execution, but not start a new one.

We also have the latest economic report for you:

Click the image for the full report

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

It has been a while since the last devlog: I have been on vacation! Now I am back in the office and continue where I left off. This week the work on the route feature continued. I implemented the logic that actually executes a route. After a ship is assigned to a route it creates a copy of the route and starts executing it. It flies to the respective waypoints, executes all steps, continues to the next waypoint, and so on. Right now only the happy path works, ie the route execution is not blocked by any issue. By the way: We use a copy of the route, because we don't want to lock the route while ships are assigned to it and allow changes. Once a ship finishes the assigned route and the route is set to repeat it will create a new copy and thus execute all the changes that have been made in the meantime. This is a compromise, of course, but it removes a lot of edge cases and confusion.

I implemented the refuel step as an example to test the execution of steps. Similar to custom contracts, I decided to use an overlay to allow players to edit the steps. Here is an example:

The refuel step is defined for either STL or FTL fuel (if both are needed, two steps are necessary) and the source of the fuel can either be a local store or the ship's cargo hold. It is possible to specify a minimum and maximum amount of fuel that is being transferred. In order to not have to worry about different fuel tank sizes of the assigned ships, it is also possible to select "capacity" for either value. That means that the refuel step will try to fill the tank to its capacity.

There are cases when a step cannot be executed: In this case for example when the selected store doesn't have enough fuel to transfer the minimum amount specified. We haven't decided exactly what to do in such a case, but the options would be:

• stop the route execution and send a notification about the issue
• continue anyway
• wait until fuel becomes available

Depending on how one is using the automatic routes and depending on the actual step type, all three might make sense in some circumstances. I am still thinking about how to best implement that.

Here is a video of a small test route with a refuel step. You can see that the flight is planned and started automatically, the ship consumes fuel, takes fuel from the station's warehouse, and then plans and executes the flight back to Umbra:

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

I have written a lot about inflation and dynamic market makers over the last few weeks, and this week it was finally time to let them loose. All market makers that are based on a closed bracket, meaning they have a standing ask and bid order, are now adjusted dynamically based on the price development of the last 10 days. I described the concept in more detail in devlog #538, if you're interested in finding out more. So far we haven't encountered any major problems — there was just a small rounding error. Usually the price band of a broker gets adjusted when the market maker order changes. In some cases this adjustment was rounded in the wrong direction, and until we fixed it, it wasn't possible to match the market maker order because the price band was a cent lower or higher than the ask or bid order.

Currently, a group of players is using government motions to set the base establishment fee to its maximum (10 million currency units for planets in non-faction space) to effectively create "private" planets, making it very hard for regular players to found new bases. The base establishment fee was once introduced to compensate players, or groups of players, for their effort in building up infrastructure and workforce populations on new planets. It was not meant to be a means to lock out other players entirely. From what we have gathered so far, this group is trying to do exactly that. We are monitoring the situation and might reduce the maximum of 10 million to a lower value.

Besides the elevated amount of community work I have done this week, I also looked into a new feature: shipping routes. It has been on our roadmap for a long time and there is also a game design concept for it. Over the course of the last few days I built a first prototype of the UI. The routes and their waypoints and steps are already stored on the server, but they lack detail, and the steps are not executed yet. I still felt like sharing what I have so far, in order to spark a discussion about the feature and get early feedback.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

An already short week (I had a couple of days off) got even shorter due to database issues. After a regular maintenance update, the servers' performance was unusually bad. It took a while before I realized that the database was also struggling. Sometimes one of the three database instances would even get killed due to failing a liveness check (a regular check that makes sure the database is still there and responding). That of course didn't help with the performance, as losing a database instance means that a third of all game objects (users, companies, admin centers, planets, ..) have to be reloaded as well, putting additional strain on the system. In the end I found out that there was a rogue game object that kept writing to the database in a tight loop. I admit, that was a bug I introduced, and it was somehow enough to send the database over the edge. After fixing the underlying issue, I looked into the database configuration and found room for improvement. We'll change how much memory is allocated for various parts of the database and will also reduce the load introduced by the liveness checks I mentioned. It turns out these checks are not free at all, the way they are wired up right now. I'll deploy these configuration changes over the course of the next updates.

We are currently also ramping up our marketing efforts, looking for YouTube channels willing to add a sponsored segment to their videos, similar to what we have done in the past. This of course also takes away a chunk of time from actual development work, but will help the game as a whole in the long run.

A new month just started, so there is a new economic report as well:

Click the image for the full report

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

This week I deployed the change in the retention factor I mentioned in last week's devlog #539. After a few days we saw a drop in the number of taken plots. It is not much, but it is a beginning. Just today, in the weekly team meeting, we discussed two other measures we will roll out later this year.

I also deployed the new inflation index command INFL:

In devlog #537 I described how its controls work and what the graphs show. You can now give it a try yourselves.

Besides the dynamic market makers, we'll also use the inflation data for two other control mechanisms: starting capital and faction contract rewards.

Similarly to the market makers, we have adjusted the starting capital and contract rewards every once in a while to account for inflation. I implemented a mechanism that takes the inflation data and adjusts these two values once a week. Instead of being based on a single commodity or basket of commodities, as makes sense for a single market maker, starting capital and rewards are based on an average across a given currency.

We'll collect a bit more data and then activate the three control mechanisms.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

This week Martin, Fabian and I met in person in the simulogics HQ. It has been a while since we last did that, so naturally there was a lot to talk about. Right now I don't want to go into the details, but I can say that we reprioritized the upcoming features a bit. While we still think that the faction influence feature would be a great addition to the game, we reduced its priority to look into a few other things before that. Fabian will now start working on a design document for a feature that will redefine the very start of a company. We are thinking about letting all new players start in a specific location (this might be the remaining generation ships) and only once they've gotten to know APEX's interface, have to make a decision where to build their first base. This actually helps with two issues we face: The learning curve is a bit more gentle and the whole plot situation is defused as well. This is now in the idea stage and I am eager to see what Fabian comes up with.

Talking about plots. Given my limited time this week, I decided to work on the automatic company liquidation. Usually, depending on the license status, we allow a certain amount of inactivity before we announce and execute the company liquidation. The announcement happens in the form of an email, as this is the only way to reach the players. With players coming from Steam this doesn't work in many cases: Steam doesn't provide an email address for the players and if they don't deliberately choose to complete their simulogics account, we have no means of contacting these players and telling them about the upcoming liquidation. Hence, we decided that we'll allow 200 days of inactivity and a 30-day deadline for these players before actually liquidating their inactive companies. This is obviously a very long time. There are many players who just start the game and notice that it is not for them. In the worst case they might block a planetary plot for more than 200 days.

To combat that, I implemented a new retention factor that is based on actual activity. For example, if a player's last activity is on the day they joined, the 200-day retention is cut in half. If they never built a base or started a flight: cut in half again. That way I hope to vastly speed up the liquidation of actual inactive companies. The change is already live in production, and we should see first results in about a week.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

In devlog #535 I announced that we are looking into implementing dynamic market makers. Today I want to show you what we have so far.

So, to recap, the status quo is that we have around ten static market makers that have both an ask and a bid order placed. I tend to call them MMs with closed brackets. The commodities are basic consumables, basic prefabs, fuels and mineral construction granulate. Since these commodities are essential for all players and especially for new players these market makers have two goals: provide unlimited sell orders, so new players will always be able to buy these commodities at any given time. On the other hand they also provide unlimited buy orders so that new players actually can find a buyer for the items they produce.

Then there are the what I call open bracket market makers. There are 56 of them and they all just have the unlimited buy order. They can be found in many material categories, from basic stuff like ores and agricultural products to high-end categories like drones, energy and electronic systems. Their purpose is two-fold: for one, they provide means for new players to sell their products and be able to make money, just like the closed bracket MMs. Secondly, the MMs for high-end products provide a money faucet where new money is introduced into the economy and also encourage some players to build the necessary production chains and run the logistics to build these items.

Since the economy is inflationary for the most part, it happens every once in a while that the upper bracket of a market maker is reached. Usually that means that no one is producing the commodities anymore, because the margins get razor thin. There is no more room to increase the prices to cover production costs. In the past we adjusted these MMs manually. Note that these adjustments are global, for all MMs of this type, no matter the faction/currency.

Now we want to switch to a system that is more dynamic, both in terms of automatically changing the orders as well as only changing the orders in the currency where the limits are actually reached.

In our opinion the best closed bracket MM is one that players never need. Ideally, they should sit at the edges of the order book and their orders should not get matched on a regular basis. So, with the dynamic we introduce we take the average price of the last 10 days and the average between the upper and the lower bracket. The difference between these two values is how much "pressure" the market maker is subjected to. If the 10-day average price sits close to one of the brackets, the pressure is high; if it sits right in the middle, the pressure is low. We do this comparison every day and depending on how large the pressure is, multiply the upper and lower bracket by a factor. If there is pressure on the upper bracket, this will widen the bracket and also increase it, giving the average price new room. We'll do this until the average price sits back in the middle between the two brackets. To prevent too drastic swings the daily change is limited to 2%.

These changes are already live on the test server, but given the low CX activity, not much is visible yet.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

In devlog #535 I mentioned that I am working on the Dynamic Inflation Adjustments concept. The first step in this concept is to actually visualize the inflation, so we have a proper foundation to base everything else on. We decided to make this data available in an in-game command called INFL. Here is a quick preview of the work in progress:

The chart features two graphs: the inflation index is the yellow line, and its values correspond to the right y-axis. The graph always starts at 100% for the set time interval. The bar chart shows the relative changes from period to period. Values above the center line mark inflationary periods, those below deflationary.

At the top of the chart you can see various settings.

The first one sets the interval and allows you to choose between daily, monthly and yearly. Depending on the selection a series of periods is shown. There is no support for custom periods right now.

The controls in the middle select the currency.

The controls on the right allow you to select a set of materials. "All" will use every material and thus show an overall inflation index. It can also be limited to a selected material or material category. The last option, "basket", has a set of predefined baskets that differ from the material categories. While material categories alone already result in interesting data, the really interesting baskets do not align with material categories. To get started, I added consumable baskets for each type of workforce that contain basic and luxury consumables. There is also a basket for each type of production prefab. The agricultural produce basket contains everything produced in farms.

The command is available on the test server, but there is little data right now to view.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

Summer has us in its grip. Europe is reeling from a heat wave. Thinking is hard in this heat, but we made some progress nonetheless. But before I dive into it, let me remind you that PRO licenses are 15% off until the end of the month! There is not much time left.

In last week's devlog #535 I talked about dynamic inflation adjustments. I did start working on this, but there is nothing to see yet, so I'll postpone that to another devlog.

Instead, I want to quickly highlight what I also worked on this week. If you are a regular reader of the devlogs, you know that I regularly look into performance issues and try to fix them. The release of the last maintenance update uncovered a performance degradation in our data persistence system. That is a bit unusual, so it piqued my interest.

A quick reminder, we don't have a relational data model where entity data is stored in tables in rows, but rather an event-based one. Each "thing" in the game is an entity and for each entity we store a stream of events that alter its state. We do regular snapshots every 10k events, which greatly helps with restoring the state from the database. Only the events after a snapshot have to be applied to get to the current state.

The current universe is now 1952 days old. In the past, if we have been generous with the size or number of events, it hasn't been a problem. Now, some entities have collected so many events that the database runs into issues. The pacemaker is a prime example. The pacemaker is a central entity in the system that reminds entities to check if they need to update their state. If a company starts a new production order for example, the production behavior goes through the list of all production orders, finds the one which will finish next and sends a simple message to the pacemaker: wake me up once we reach this specific timestamp. The pacemaker persists these "ticks", as we call them. It now has well over 720 million of them. The pacemaker also uses snapshots, but I noticed that sometimes they would not be persisted. That was an easy fix, but the events themselves, even the ones before a successful snapshot, are not deleted. The main reason for that is that, if we ever introduce an update that renders the snapshots invalid, we can simply ignore the snapshot and restore the entity from the full event stream. If we had deleted the events, that would not be possible and fixing such an issue sounds like a nightmare.

Now we reached the point where we cannot ignore having millions of events for a single entity anymore. So we decided to implement a new system that not only keeps the latest snapshot, but also every snapshot in a retention window of 10 days. Every event before the oldest snapshot gets deleted, creating some breathing room for the database. In case we run into an issue, we can fall back on an older snapshot. In the beginning we will not roll this out to every type of entity, but only a few selected ones, like the pacemaker. The change is deployed on the test server and I am currently monitoring if we run into any issues.

I admit, that was pretty technical... but sometimes game development is just that. Thanks for reading if you made it that far :D

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

On Wednesday we shipped maintenance release 2026.06. As usual, you can find the full release notes in the forums. Here are the major changes:

Screen variables is a new feature that allows you to define a set of typed variables per screen. This can be used to build dynamic screen setups: for example, one could build a commodity exchange screen that has the order book, chart, order mask etc. Changing the commodity variable would change the contents of each command simultaneously.

We also added post-tutorial contracts. New players joining after the release date will receive another set of contracts that help them work towards a second base.

The PROD command was overhauled and now gives a way better overview of your production lines.

The update itself didn't go as smoothly as I expected this time. A few database performance issues surfaced, impacting the overall performance of the game. I have identified at least two separate issues that I want to address in the coming week. So far the game is stable and playable, but improvements have to be made.

I also looked into a concept document Fabian wrote a while ago, called Dynamic Inflation Adjustments. As many of you have stated countless times, having static values for the market maker bids and asks, which can only be updated manually, might not be the best option going forward. We are now looking into more dynamic options. The document basically has two parts.

The first one is about measuring inflation and visualizing it. This will be the foundation the dynamic part is based on. We might even make this data available in-game, we run an economic simulation after all. I take it many players would be interested in that.

The second part is about adjusting three things dynamically: the market maker orders, the faction contract rewards and the starting capital for new companies.

As usual, I will go into the details once I start with the implementation. I just wanted to leave this as a heads-up on what's coming.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

A quick update from Martin on the supporter packages: The ones that have tracking links have almost all arrived at their destinations. A few are still in US customs (looking at you FedEx). We are still working on getting the necessary buerocratic puzzle pieces into place to be able to send packages to the United Kingdom. Fingers crossed.

Martin also updated the perks page. It now shows the status of the perks and helpful links.

A while ago there has been a discussion in the forums about alternative Sodium recipes and other adjustments. Fabian got to work and added a few alternative metallurgy recipes that involve Sodium. They will be part of the upcoming maintenance release. Thank you very much for the suggestions!

I spent most of my week on a new feature that will make it into the maintenance update as well: screen variables.

This PRO-feature allows to define variables of various types per screen. The variables can be used in commands. Each variable has a selector that allows to quickly change its value and thus also the commands it is used in.

This can be used to build dynamic screen setups: For example one could build a commodity exchange screen that has the order book, chart and order mask etc. Changing the commodity variable would change the contents of each command simultaneously. Here is a quick example, as a video says more than a thousand words ;)

A variables can be referenced in a command by putting its name between % characters. Right now there are four types of variables:

• string: holds a string
• material: selects a material using the default material selector
• commodity exchange: selects a commodity exchange code
• location: uses the default location selector to select the natural id of a location

Many commands work with these variable types, but I already found a few commands that do not. The workforce command WF for example expects an id and doesn't work with the location, like the base command BS for example. If you find more, please tell me!

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Japanese has long been one of the most requested languages from our players, and seeing it come to life is a real milestone for us.

Prosperous Universe is supported in a growing number of languages beyond those we officially maintain, and that's only possible because of the players who generously give their time and expertise. Translating a game as detailed as ours is no small task. It takes a deep understanding of both the language and the mechanics, plus the patience to get every term just right.

To everyone who contributed: thank you. Your work opens the door for a whole new group of players to explore the game, build their companies, and take part in our player-driven economy.

If you spot anything that could be improved, or if you'd like to help translate Prosperous Universe into your own language, we'd love to hear from you. Our translation community is always open to new members, and every contribution makes the game more welcoming for players around the world.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Martin

Last time I made an appearance in an issue of the devlog was in week 529 and the topics are exactly the same. So let me cover the key points in the same order, too:

Firstly, I implemented exclusive download access for digital perks. Since last Thursday, supporters at the Galaxy tier and above should see a download button on the perk info page that allows them to download the secret soundtrack uncompressed and in high definition. As stated in issue #529, everyone else will be able to stream the soundtrack on all the usual platforms starting September 1st.

Secondly, Michi and I got together at simulogics HQ to pack and ship the 80 to 90 packages of the final batch of physical perks. Even though we upgraded our setup from "manually fighting the DHL online store" to "hacking together scripts talking to a shipping SaaS's API", this process did come with a few of challenges:

1. Needless to say, the...uhm..."change in policy style" in the US made shipping there incredibly more complicated and costly compared to last time. Apologies to anyone for whom this is causing trouble on your end. We tried our best to get everything in order, but it's a bit of a gamble and we can't really do much about the import fees charged by UPS/FedEx. Kudos to the people at the FDA helpdesk I had to call Friday night, though: They were really friendly and helpful ;-)
2. Apology number two goes out to our backers from the UK: Brexit means we get the worst of both worlds in that there are now customs checks (and duties) and EU-style bureaucracy. While the packages are ready, I'll have to apply for a UK VAT and EORI number before I can label and ship them...
3. We did actually run out of inventory towards the end of packing boxes because yours truly apparently has difficulty counting. For the less important items we packed a replacement instead. For the bigger ones Michi and I will be in touch with the affected supporters soon to discuss options. So...apology number three, I guess?

Anyway, I am glad this chapter will be closed soon. And finger's crossed I won't receive too many additional emails from customs agencies around the world!

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

I just came back from a vacation, so naturally this will be a short devlog. Nonetheless, there is something to report:

In the days before the vacation I have been implementing a small feature that is originally from the faction influence game design document. It was a self-contained feature with a small scope, so I decided to implement it anyway, although I am currently working on the upcoming maintenance release: faction com channels. There will be four new communication channels, one for each faction. Players will be joined automatically to the channel of their respective faction. The channels cannot be left, as they are auto-assigned, but they can be muted. The feature is available on the test server as a preview.

In my absence Fabian came up with a few additional recipes for RE and WHR that will make it in the maintenance release as well. The rationale behind the new recipes is to add new sinks for these materials, as the current ones are limited and mostly only for gateway related materials.

And, of course, there is a new economic report:

Click the image for the full report

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

After the recent election turmoils, multi-accounting and exploits, I was looking forward to do some "regular" development. Our backlog has quite a few bugs and quality of life entries that we want to release in an upcoming maintenance release. I created a topic on the forums for it.

One of the quality of life improvements is the overhaul of production overview command PROD. Right now it just shows a simple list of all the bases and their production lines. Taking heavy inspiration from refined PrUn, this is what it will look like:

The basic structure stays: It is a list of all bases, but the individual production lines show more information. The efficiency column helps to find production lines that run suboptimally, for example due to missing workforce consumables or other production efficiency factors. The slot column color codes how many slots of a production line have an active order. Green indicates that the production line runs at full capacity, yellow that at least one slot is unused, and red if there is no active production order. The last column has links to show the individual production line or the order management.

The production lines of a base can be collapsed into a single row, especially handy for players with a lot of bases.

Another helpful tool is a new toggle in the SFC command that allows to enable and disable the 'unload on arrival' flag, even during flight! This will be a PRO feature, as the underlying 'unload on arrival' is PRO as well.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

What a week! While investigating a potential multi-account issue with over 10 alt-accounts on Monday afternoon, I noticed that one of the alt accounts had managed to accumulate copious amounts of slower than light fuel in one of their ships' tanks. Since this should not be possible and I had confirmed the multi-account, I deleted all of these accounts. I then went on to find the root cause. After staring at the code for a while I realized that it was possible to create almost infinite amounts of SF fuel using the mechanism that allows transferring multiple materials. I quickly patched the issue and called it a day, since it was already getting late.

Shortly after I left the office I got pinged on Discord about suspicious activity on the Antares SF market. A player was buying and selling enormous amounts of fuel. I suspected that this was another alt-account which created the SF fuel before I patched the issue, but the respective company was just a few minutes old, so there was no way they could have obtained that amount of fuel. So, back to the office, I quickly deleted the account to prevent further abuse. I also started looking into other potential exploits, but wasn't able to find anything.

On Tuesday I didn't have too much time, due to some private appointments. That didn't stop the attacker though and I deleted another account. In the evening I sat down again to find the second exploit. Unfortunately I wasn't able to find it in time. In the early morning hours, while I was not yet in the office, another attack occurred. The attacker not only attacked the SF market, but also used the money to empty other commodity exchange books as well. After deleting that account I kept a close eye on company creations to prevent further damage, while I went through the event stream in the database of the previous attack trying to figure out the exact attack vector. After a while I struck gold and managed to replicate the attack. I won't go into the technical details, but it involved ship flights, which is why it took me a while to find and also why new companies without any PRO status, contracts, LM ads or anything like that were able to use the exploit.

After patching the second exploit we haven't had a similar attack since.

So what is the damage? The biggest outcome is that the SF market maker has created roughly 10 billion AIC during the attacks.

Not all of that has been added to the economy though: Since we deleted the accounts their funds left the game with them. The increase in money supply is visible, but not as dramatic as we anticipated:

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!