Using connectrpc was a pretty refreshing experience for me. Implementing a client for the HTTP stuff at least is pretty easy!
I was able to implement a basic runner for forgejo using the protobuf spec for the runner + libcurl within a few days.
Bumped into your project a while back - pretty impressive. I was a little disappointed it seemed to just convert the resources rather than use the original runtime formats (since there are a features that don't directly translate to gltf), but for a viewer it's perfectly reasonable.
Are you planning on supporting tribes 1 maps at all?
Theres still quite a surprising interest in reverse engineering and extending the life of torque games. I'm hoping on publicly releasing a refresh of the original torque codebase this year which improves support for modern platforms including wasm.
It's amazingly easy these days to reverse engineer stuff and revive old codebases!
It would be possible to have it decode the .dts and .dif formats on demand - that was my original plan - just much less efficient for users, as the .glb files are about 1/5 of the file size on average. (I also assume glTF loading/rendering has had a lot more optimization work put into it than what I'd be able to accomplish.) For these reasons it seemed more productive to have it work on the Blender addons as a starting point rather than JavaScript/TypeScript parsers for the original formats. I still ship the original assets alongside the .glb files (meaning they have URLs just aren't loaded) in case I want to switch it someday.
Some of the custom features you may be referring to I implemented as custom properties in the glTF output - like surface flags. "Outside Visible" is one example, it's a flag baked into each .dif surface that determines whether rays can reach it from the outside, so the engine knows whether to apply the map's directional sunlight, or just ambient and light map lighting. So, even though it technically could try to render with modern PBR, dynamic lighting/shadows and all that, it instead renders as close to the original as possible using the same (or similar) techniques. Comparing screenshots with actual Tribes 2 renders is often indistinguishable unless you really know what to look for!
I really wanted to like it but the UI always put me off. Also tending to prefer a more open development model these days. Thankfully at least for dev gitea and forgejo have both come a long way and the CI is pretty decent now (though they still dont have a gui workflow builder!).
OneDev is not fully open (there are some module for paid user), but Robin is truly available, even if the only and main developer, on every ticket you open or feature you request.
The Settlers 2 was one of my favorite games growing up - really felt like they polished up the mechanics of the first game and made the UI more tolerable.
If anyone is looking for a more modern 3d equivalent but in a slightly different setting, I'd recommend The Colonists.
The way I see it, S2 was pretty lazy. They took a system that was fairly polished already and tinkered with it without understanding how it would impact the whole, like how they made a level-up system that heavily incentivizes a degree of micromanagement the UI isn't built to support.
Or take the pig farm: Clear pros and cons in S1; in S2 it's just a bad bakery. Or the perpetually broken ship navigation, and no way to do naval invasions.
A few months ago I used ChatGPT to rewrite a bison based parser to recursive descent and was pretty surprised how well it held up - though I still needed to keep prompting the AI to fix things or add elements it skipped, and in the end I probably rewrote 20% of it because I wasn't happy with its strange use of C++ features making certain parts hard to follow.
Back when this was first announced it was pretty neat, but I don't think it passes the long term reliability test for me. Last time I tried it I somehow managed to erase all the notes and the site broke - didn't exactly instil much confidence.
Lazarus is nice but both its apis and the ui feel like they're still stuck in the early 00's.
It's not enough to look like VB6 / Delphi these days; you've got to keep up with what kinds of conventions we expect now.
Also switched to a UGREEN, in this case the DXP4800 Plus. Truenas runs pretty nicely on it!
One critique I'd have of this setup is it's a lot noisier than my older Synology setup, but I think that's more to do with the HDDs than the case.
It's useful, but not necessary. Plenty of 10+ year old Rails apps in the wild. Github was running Rails 2.3 until 2018 while the entire software world that depended on it didn't fall apart. Even if you follow best advice and update your dependencies for security sake, you can effectively run the same code using the old "trends" (aside from things like safe parameters, etc).
Large rails apps tend to be on older versions not because they're so very stable but because Rails upgrades are a nightmare at scale. Even point versions have lots of undocumented breaking changes. There was a lot I didn't like during my 4 years as a rails developer but upgrades were the very worst of it.
> Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day.
it all depends on your philosophy on dependencies. if you maintain a small set of core dependencies that are there for good reasons and are actively maintained, then rails upgrades are pretty easy. if you have a Gemfile that has a bunch of third party gems that you bring in for small problems here and there, you have to occasionally pay down that debt on version upgrades. we have an 18 year old rails codebase currently on 7.1 that hasn't proven to be a big pain for upgrades. the hardest upgrade we did was because of a core dependency that had been dead for 5 years broke with a new version of rails. but that was a story of letting technical debt ride for too long and having to pay it back.
this is a common problem in any complex codebase that has a culture of using third party dependencies to solve small problems. you see this conversation all the time with modern frontend development and the resulting dependency tree you get with npm etc....
reply