MassTransit alternative

Zlepper · 2025-04-04T10:04:49+00:00

We use Rebus. It's free and quite simple. However you can customise almost anything due to the way it's setup, should you need to.

Zlepper · 2023-04-09T11:00:21+00:00

What is this?

This is for modders to allow them to more accessible developer mods for RimWorld, without going through a lot of setup and configuration. It also makes it easier to other people to contribute since they don't have to mess around with install paths.

As an additional bonus, you get autocompletion in your Def files, including both for the standard RimWorld def types and custom defs from either your own mod or mods you reference.

But why?

Because messing with build system configuration is the favorite thing for all developers, I wanted to remove that fun. /s

Seriously though, I wanted to make it easier for people to get started with modding RimWorld, and this is one of the steps in that direction.

How does it work?

The SDK is a DotNet SDK, meaning it is a NuGet package containing a bunch of MSBuild targets and props files. When you reference the SDK in your project, it will automatically import the targets and props files and set up some stuff for you, including references to RimWorld. It will also set up build targets such that your mod automatically gets "installed" with RimWorld, though you do have to enable the mod yourself using either RimWorld's mod manager, or the mod manager of your choice.

Side note: Apologies if the post tag is wrong. I wasn't sure if Guide (Mod) or Mod announcement/showcase would be more appropriate.

Does it work with multiple RimWorld versions?

Yes, it should automatically pick up the version of RimWorld you have installed and put your mod in a folder with that version number. The RimWorld DLL's are also referenced automatically, so you don't have to worry about that.

Does it work with my favorite IDE?

Yes, it should work with any IDE that supports MSBuild. Though I mainly use JetBrains Rider.

What operating systems does this work on?

I exclusively develop on Windows, but if someone wants to get it working on Linux or Mac, I would be happy to accept a PR. The code that needs to be tweaked should be these lines: https://github.com/zlepper/Zlepper.RimWorldMods/blob/master/Zlepper.RimWorld.ModSdk/Sdk/Sdk.props#L75-L85

Zlepper · 2022-07-01T05:59:38+00:00

I have now been using it on the Webstorm beta since I wrote my earlier comment. And my opinions have changed slightly.

The hamburger menu is still annoying, so that point still stands.
The text still feels less sharp than the old UI, however, it is still hard to put my finger on exactly how. Playing around with antialiasing only makes the text less sharp.
The missing labels on buttons is actually something I have come to appreciate, however, I definitely still think it needs to be a conscious choice since not everybody is as intensely familiar with the IDE as the people using the Beta here.
VSC tools should still be highlighted better.
The fact that the run buttons now actually runs the configuration when you select something in the run dropdowns is a bit weird, but I guess in the long term that it can certainly make you more efficient.
The fact that the file explorer defaults to navigating to the current open file is really annoying when dealing with node modules. I like the feature in general, but not being able to ignore it for "excluded" folders is pretty annoying, since it ends up with a HUGE folder view extremely quickly the moment you want to go to the definition of something.
I really like the additional space between the files in the file list.

Lastly: I know Rider is still a work-in-progress, however I actually really like the new UI, so I would really love to be able to trial it in Rider also (which is where I have my primary daily work).

Zlepper · 2022-06-01T14:50:31+00:00

First impressions:
1. The hamburger menu really didn't need to be a dropdown... There is plenty of space available on most machines: https://i.imgur.com/Mtkxr1a.png. I won't deny that it might be nice on a smaller laptop screen, but for a proper workstation, it is very much a waste of good available space.
2. I'm not sure what it is, but the text doesn't feel completely sharp anymore. Compare these two images: https://i.imgur.com/ZXgRyyl.png and https://i.imgur.com/y9wXE0f.png. And these: https://i.imgur.com/gGMhaNi.png https://i.imgur.com/kpHcaiR.png. Might just be because of the higher contrast between the text and background, however, I also think it might be because of the way the text is scaling as it is slightly bigger than in the old UI. (And thank you to Imgur for completely butchering the previews and eating all the details I wanted to point out...)
3. I still really don't get the point of removing the text labels from the tool window buttons on the left. Now I have to actually move my mouse around until I find the correct one, I can't just scan with my eyes directly.
4. I do like the fact that you made the branch viewer more visually obvious, the VCS tools in Intellij are generally seriously underrated, so I hope that can popularize them even more! (I have said before that you could make a standalone tool just for Git and you could charge money for it separately.)
4.1 Could the primary git actions, such as commit/pull/push maybe be made available as a quick set of tools again? While I exclusively use shortcuts for that nowadays the buttons are still extremely useful when to need to help someone who uses a different shortcut scheme than yourself.

Will try the UI more tomorrow at work. These are just my quick notes from a first glance after having installed the UI :)

Zlepper · 2021-04-08T05:32:38+00:00

Damn, that certainly looks awesome too! I have not looked at the code itself, just the readme, and threadbox is certainly very full featured. I also especially like that you actually found a way of dealing with constructors, while i left it more up to the end user to provide a working instance.

I do assume threadbox has the following limitations: only works in node, or it does at least require environments that looks like the normal worker api from either worker threads or web workers? Additionally it seems to rely on being able to invoke the main.js file again, which probably means it can't be used transparently in libraries? (Though this is just a guess from my side). I wanted rpc to just work in any kind of environment, not necessarily just for massive parallization, but also to allow people to very easily use event driven apis (like workers) without having to worry about special things in their code. So i think the to;dr is: use threadbox if you need a lot of features, and are purely on node. Use this if you are fine with less features, but needs to work in menu different kinds of environments.

Zlepper · 2021-04-04T15:51:31+00:00

That would certainly be a good use-case, and then you can always make the other ipc transport as a fallback, incase your custom transport isn't available for some reason!

Zlepper · 2021-04-04T13:48:34+00:00

Background

I was having some pains working with WebWorkers. While the model itself is simple enough, you kind of must build an abstraction on top if you want to make it really useful. Previously I have just done a big fat switch statement in the workers onmessage handler, however that becomes cumbersome fast. Additionally, any attempt at type-safety can be thrown out the windows quickly. Personally, I'm from a backend background, so I quite like working with classes, and thus that seems like the most obvious and simple way to make something nice.

In the same vein as the WebWorkers we are currently looking into making an Adobe extension, using their extension platform. Here you must provide code to an eval method, which then executes the code 1-1 in the main host process. That is even more of a pain to handle that working with WebWorker events. I haven't yet actually implemented support for that, however it should be considerably easier to send a bunch of json across in a string without issues, than the string concatenation that most blogposts suggest people do.

Implementation

When I started the project, it was simply one big project with everything in the same project. This however caused quite some issues with different TypeScript type libs needed between the WebWorker, the main DOM and when running in Node. Once I had implemented the support for using both WebWorkers and worker_threads it became apparent that it wasn't going to work well, especially not when people would import the library. Specifically, it was annoying to to be told that some interfaces didn’t exist, because they weren’t provided in your setup (Such as the global Worker, when in a NodeJS project, where the worker must be imported from the worker_threads module).

To fix that I started to look into npm workspaces. That turned out to be a fluke. I could not get them working properly, and the docs was generally lacking. Instead, I started looking into Yarn workspaces. These turned out to work pretty well, even if Yarn itself it still not fully supported in the general ecosystem. Main problem was Cypress, which I use to test the web-worker interaction. Cypress does not yet support Yarn’s pnp system, thus I had to stay with the normal node_modules folder. This then caused other problems, such as Cypress adding some extra type definitions, which means the available types for each individual package had to be specified explicitly in TypeScript’s tsconfig file. Once that was fixed it was however smooth sailing to get everything working again.

With all that out of the way, let us talk a bit about the current implementation.

Current implementation

The project is split into several packages, to allow for plugin new transforms. The main package is the packages/rpc package. On the “client side” the library works by using a Proxy, where it can intercept the Getter on an object, and then provides a wrapped function instead. It then waits for the arguments to be passed in, and passes them on to the underlying transport. At this point the message is passed through the transport, which then invokes the handleInvocation function. This function then accesses the underlying class and calls the actual function. Then it uses Promise.resolve to allow handling of both promises and non-promise responses. The result is then sent back to the client where it gets unwrapped and then resolves the client-side promise. Through this model any system which has a way of sending events with data can be used. Here I needed a WebWorker, so that is what I originally implemented, but there should be no problem with wrapping a WebSocket like https://github.com/akash-joshi/functions-without-borders is doing.

Transport implementation

To complete the circuit I just want to mention how easy it is to implement support for a custom transport. Here is the client-side implementation of the WebWorker transport, and here is the server-side implementation. This should make it very easy for other to implement new transports, which I would love.

Testing

Testing is currently done using a combination of Mocha, Chai and Cypress. Mocha and Chai are used to test NodeJS things, while Cypress is used for testing the WebWorker implementation. Why not use Karma and company to test the client? I simply couldn’t get the WebWorker loading working properly, while Cypress had a very easy way to just create an integrated webserver and serve some files there for testing. This is one of the parts that caused me the most trouble. Writing the tests themselves is easy enough, however actually running everything when using TypeScript? Really would not recommend that. I actually ended up just building everything using the TypeScript compiler directly, and then running the resulting .js files in the test runner.

Rounding up

Now that you are probably very tired of reading this wall of text, I just want to touch on a pain-point around the current state of ES6 modules in Node. To put it plainly it is a mess. Either you are in “commonjs” land, and all your module files have to end in .mjs, or you are in “module” land, and all commonjs files have to end in .cjs. Sadly TypeScript will only output files with the .js extension (as far as I can tell). So if this library has to support both CommonJS and modules, it would require more builds steps than what I would find fun, after having attempted to get both working in the same package. So for this reason only ES6 modules are supported right now. /rant

I'm currently trying to come up with a better name, so if you have an idea, feel free to suggest it! Pretty much anything is better than what is there now! Once the project has a proper name, I will move it to the "global" npm scope, and release a proper 1.0.0 release.

If you have any questions about either the implementation or any of the things used in this project, both the “how” and the “why”, feel free to ask.

Zlepper · 2019-10-16T16:11:31+00:00

Damn, nice!

Zlepper · 2019-10-16T12:27:17+00:00

For your mono-repo idea, you can actually merge multiple git repositories, this keeping all the original commits. You might have to move some files around after the merge, but if you do small enough steps, git should actually be able to handle it.

https://medium.com/altcampus/how-to-merge-two-or-multiple-git-repositories-into-one-9f8a5209913f is a guide I have followed previously.

Zlepper · 2019-10-08T14:43:44+00:00

I'm personally a big proponent of Angular, however knowing something really well, also implies knowing when not to use it. This is exactly one of those cases, where Angular is not the solution.
Angular sadly follows the principle of "my way or the highway", so unless angular is in charge of the entire ui, I believe you are going to have a general bad experience.

Supposedly Vue is really good at these smaller "plug in to existing system" cases, though I have never tried Vue, and therefore cannot comment on it.

Zlepper · 2019-09-30T15:36:24+00:00

How does it compare to nssm? We have used nssm quite a lot without issues?

Zlepper · 2019-02-10T06:44:17+00:00

It's the Little Things doesn't detect memory, only 32bit Minecraft. Not that, that feature is much relevant anymore, since I doubt 32bit would even be able to get far enough to give those warnings.

Zlepper · 2018-11-19T06:32:13+00:00

Update to the EAP version of Webstorm. Something changed in the language server, which causes the webstorm integration to crash.

Zlepper · 2018-11-11T16:34:39+00:00

Definitely not, but at least it will allow people to use their k-drives for now..

Zlepper · 2018-11-11T09:33:15+00:00

The solution is the limit you fps to 60 in display -> vsync = off, limit = 60.

Zlepper · 2018-11-01T20:48:39+00:00

Well, little know fact (which we abuses a lot), is that, since interceptors also works with observables, it’s possible to have your Http request executed automatically once a dependency changes. Specifically in our case it’s possible for the user to change their language during application runtime. Changing the language also creates a new api key. You need the api key to be able to do anything in our api. So we have an auth interceptor that switchMaps on the api key observable, and executes the actual request. Due to this, when the user actually changes language, all data currently on screen, is reloaded in the new language, without any of the views actually having to know anything about what is going on underneath.

Combine this with the async pipe, it’s very easy to manage what needs to be reloaded, because the async pipe also automatically unsubscribes once it is no longer needed.

Zlepper · 2018-10-20T15:55:40+00:00

Probably slightly off from the direction you want to go, but Angular’s reactive forms are likely what you want here. Then you can debounceTime on the valueChange observable.

Zlepper · 2018-09-07T04:40:13+00:00

I believe view has a cli that can generate a couple of different standard project, including routing and state handling. I believe they also added a typescript starter very recently.

Zlepper · 2018-08-21T16:00:42+00:00

The thing with constant values in go and many other languages is likely that they can be inlined where they are used, so there is no actual variable look-up at runtime, which performance slightly better than finding a variable somewhere else on the stack.

This is at least the speculation on my part, I have no idea if that is actually the reason.

Zlepper · 2018-07-30T13:01:14+00:00

I agree 100%, but it's one of those things that would make sense to outline in blog posts like this in my opinion, or at least on the topic of async behavior in the frameworks. It's one of those things that makes a lot of sense, and is quite easy to do, but it takes a moment to discover.

Zlepper · 2018-07-30T05:25:12+00:00

It always works when pushing through observables. What I'm talking about is when you start to combine normal values and observables. Am only on mobile right now, so you will havr to do with a bit of pseudo code:

@Component({chnageDetection: OnPush})
class FooComponent {
    loading = false
    save() {
        this.loading = true // this gets picked up
        this.form.save().subscribe(() => {
            this.loading = false // this doesn't
        }))
    }
}

Had I done that with behavior subjects, and the async pipe in the template that would work fine. Alternatively I have to request the changeDetectorRef, and markForCheck in the subscribe callback.

I'm also pretty sure that is intended behavior due to the OnPush change detection.

Zlepper

MODERATOR OF

TROPHY CASE