Can we easily open the door to better and more reactive integrations?

General Discussion
1

This is a vague idea that I’ve had for awhile but I think I have it worked out enough to bring it to the community. I think we are very close to being able to make more reactive integrations which could solve a host of issues by making it possible to run integrations alongside the main app that automatically react to data changes in your game EDIT for clarity: using an efficient and database safe method.

Imagine if you could:

  • Create a dashboard with pretty charts or reports or just lay out the data in a way that makes more sense to you that automatically updates
  • Have a sound play on a certain event (someone has suggested that before)
  • Trigger an AI agent to write a game summary automatically
  • Automatically hold elections in a government simulator
  • And more

Now you may be asking at this point, what is your actual idea for pulling this off David? Webhooks, dear reader. Webhooks.

For those that don’t know, webhooks are a way an application can react to state changes in another. As you may imagine from the name, they were invented for the web and are therefore primarily used in web applications, but there is no reason why they can’t also be used in a desktop application. It is fairly trivial in most languages these days to host a local web server as part of your desktop app just as it is trivial for a desktop app built on the dotnet framework, like Aurora, to send a http request.

If Aurora could be configured to post to a webhook endpoint when the game is saved, then any integration can listen for it and trigger a db read to refresh its data cache and then react to data changes. This reactivity creates possibilities and that’s what I’m interested in doing.

I think a bare minimum implementation would get us by for a long time, but the system could be expanded in the future with more events. Below, I’ve laid out what I think may be a valid, though a little rough, implementation plan.

Bare Minimum Implementation

First, add a table for the webhook configuration. It could be something like this:

Id
GameId
TriggerEvent - Initially just 'onsave'
Url

It would be empty by default but integration authors could add records here as needed when their integration starts, saving the need for an in-game UI.

Secondly, in the save logic do an http(s) post to any ‘onsave’ webhook endpoints (there can be more than one). Since it doesn’t matter to Aurora whether anything is actually listening at the configured endpoints, you would fire it off asynchronously and not even have to wait on the result, so the performance impact would be negligible.

Suggested ‘onsave’ webhook payload, but additional data could be added here:

{
    'gameId': 1,
    'gameDate': '2026-07-17 13:35'
}

That’s it!

Nicer Implementation

Same as above, but maybe add an in-game UI so users can configure their own webhooks, though that could also be handled by an integration.

For maximum flexibility, I think webhooks should be game specific, but it would be really convenient to have a global default webhook configuration that can be copied when a new game is started since it is likely that you’ll want run the same integrations during most games.

A Case for Autosave

This idea really makes the case for autosave as one of the goals here is reactivity and if the game autosaves AND notifies webhook listeners when it does, any integration can automatically react which will result in a very nice user experience, in my opinion.

Thanks for reading and I hope that others also see the potential in this idea!

2

First of all, have you read Steve’s post? Just in case.

Secondly, we already have some tools for some things. You can create something like that by yourself.

And thirdly, this is my personal opinion and the opinion of other people may differ, but I don’t really like getting into the game in this way, even if it looks pretty harmless at this stage.

Just don’t forget that this is Steve’s personal hobby project.

1 Like
3

One can essentially achieve this with existing tools by simply saving the game and reading the DB.

I realize saving the game can take a hot minute after some time has passed, but by the same token I’m not sure there’s any chartable data that has such urgency that it can’t at least wait until the next 5-day increment. I don’t need a real-time updated chart of mining yields on Omicron Persei VIII in the middle of intensive beam combat, for instance.

4

You can do this already just by polling the db file, and responding to an update.

Or you could add a trigger to any db tables in the db that you want to respond to.

5

CopyOfSatan:

Yes, I understand Steve’s position on mods, but this wouldn’t be a mod. Just adding something simple to add a little reactivity and would require very little, if any, maintenance and no support from Steve. As long as it sends the payload, it’s out of his hands.

And yes, I know that you can already make reports and stuff but updates have to be manually triggered. I’m looking for reactivity so I could just let the game run and a companion dashboard could automatically update from time-to-time, or a government simulator could automatically hold a vote. It doesn’t sound like much, but believe me automatic updates is something that users would appreciate once they have it. Just look at how many people want autosaving.

Also, I think if data integrity is really a concern then Steve could password protect write access in the DB to everything except the webhooks table, so all integrations would be forced to be read only and could not mess up anyone’s game.

Lastly, yes I am completely aware that it is Steve’s personal project as that fact seems to be the default response to most of my suggestions. :sweat_smile:

6

This is not true.

7

It is true if you do not want to riskily modify the database to add triggers or constantly poll it. Polling is not a very efficient way of detecting state changes.

8

“have to be manually triggered” is not the same as “can be automatically triggered by a method that i don’t prefer”

9

Sure. It’s not just about MY preference, though. I’m trying to balance Steve’s wish to not allow mods or risky database edits with the community’s desire to have companion apps with an implementation that would take like an hour of work at most.

Honestly, I don’t understand the hostility, skoormit, or maybe I’m misreading it? Steve is already adding UI color customization and interrupt configuration, two things that previously required mods or database edits, so he’s obviously on board with doing some QoL updates. In my opinion, this is just more of that.

10

I don’t really understand what new capability we are trying to add here.

What do you want to do that something like Aurora Electrons can’t do?

11

You seem nice, and seem to have good intentions, and I apologize if I am coming off as hostile.

Your opening post rubbed me the wrong way. I’d wager half of my empire’s corundium stockpile that Steve knows what a webhook is. Posting a complete introductory guide to the concept, use cases, and basic implementation of them just seems a bit presumptuous. Not to mention the marketing tone of the language, and the highly crafted formatting, with bulleted lists and everything. The post is evocative of some recent highly negative experiences surrounding the game.

Also, I am personally very, very heavily invested in being able to use the database as part of my own gameplay. See for yourself how much db work/play I have done. A suggestion that Steve consider moving to a readonly database strikes precisely at what makes Aurora special for me. And there are plenty of others like me. There are dozens of us!

1 Like
12

I gather that the OP wants, essentially, Aurora Electrons but with real-time, instantaneous updates instead of having to save the DB and refresh the Electrons.

Which I understand the desire for, but Aurora is hardly a fast-moving game, so I’m not sure this is that compelling of a use-case. Particularly since, as a programmer by trade, I’m exceedingly wary of any project that will “only take an hour” that turns into three weeks of unpaid overtime.

Dozens!

1 Like
13

So, clicking the refresh button in Electrons for you?

14

I wouldn’t know, I’m too stubbornly low-tech to use Electrons. :upside_down_face:

1 Like
15

Someone already tried this and its partially what resulted in the tightening of the modding rules anyways.

Hooking into the game state is explicitly against the rules, esp. because the app in question needed to de-obfuscate parts of the code.

Now if you want an actual interface that skips the need for obfuscation. Good luck convincing Steve to do that, I’d be very surprised if he showed interest in facilitating 3rd party tools other than the ones that just hook into the DB.

16

Sorry if my post was off putting. Note that I did not use AI or anything and if it is too well formatted, then I don’t know what to say to that as that is how I try to communicate, especially regarding proposals.

Also, I apologize if the webhooks background came off as condescending. I included it because, as a rule, I try NOT to be presumptuous about the technical background of whomever I’m communicating with and it wasn’t targeted at Steve specifically or anything; I was just attempting to make sure every reader is on the same page, but maybe it was unnecessary in this context.

I don’t think I’ve made the implications of this feature clear, so please bare with me as I try again. The one thing this would do, initially, is make it so you wouldn’t have to click a refresh button in a companion app, which I think the value of is being underestimated here BTW, but I’m also thinking more long-term. While the initial trigger would be limited to when the game is saved, mainly to make the feature easier to implement, the triggers could eventually be expanded to include more events and the payloads could be expanded to include more data so reading the database isn’t required.

For example, if your companion app could receive an event with the relevant info when a character dies, then you could have an alert play and automatically generate an obituary without having to even touch the database. Or maybe you could have an app that generates an AAR and posts it automatically? And if the payloads were expanded to include more context then you wouldn’t necessarily have to be limited to a companion desktop app…you have now opened the door to cloud-based companion apps.

I’m sure there a lot of things I haven’t even thought of. It’s all about providing possibilities in a way that is pretty easy to do, is expandable, and does not compromise the integrity of the game and it’s data. It provides a way for community members to create companion apps (not mods) that enrich the gameplay experience in a way that Steve can control and keep his headaches to a minimum.

Does any of that help explain the idea better?

17

You already don’t have to. Aurora Marvin refreshes by polling for a change to the database file. As an example.

the triggers could eventually be expanded to include more events and the payloads could be expanded to include more data

Look, it sounds fabulous. Fairly straightforward architecture, easily extensible, opens up lots of possibilities.
Maybe he’ll like the idea. Maybe he won’t.
Maybe he’s muttering that he never should have done the UI customization because of course now we’re asking for webhooks. Webhooks!
I like to imagine his wife rolling her eyes at him as he grumbles into his laptop screen. But maybe she likes webhooks. Sounds like a good idea, she says. Maybe you should think about it, she says. And he grumbles a bit more but then two weeks later suddenly decides that it’s a grand idea after all, and the next day he drops the announcement into the changelog and then we all talk about it very excitedly and then he releases 3.0 and we all live hookily ever after.

Now if you’ll excuse me, I think Excel finally finished updating from my last save.

6 Likes
19

Are we sure a plural is warranted here?

1 Like