Can't speak for everyone, but I'm interested to see where PMR goes, but don't have a lot to add. Do keep posting Bob, it's a handy reminder for those of us perhaps stung by early access/early preview games
A bit of a breaking change from a semver perspective, hence the 3.0.0 tag. However, if you are a basic user of the library, your code should be 99.9% change free.
The original goal a few months back was to implement AIC and AII and get an AI league up and running. Obviously that meant that I *had to* shave an entire herd of yaks and reimplement the packet handling for no good reason (except vanity and speed). Nor did I correctly estimate how much free time I would have to actually execute on this at the start of the year.
Big thanks to Flame and the node-insim library which I "borrowed" a large amount of the raw unit test data from, which saved me a huge amount of time. Every packet now has some level of testing to it.
insim 3.0.0 (crates.io, docs.rs, examples):
The original goal a few months back was to implement AIC and AII and get an AI league up and running. Obviously that meant that I *had to* shave an entire herd of yaks and reimplement the packet handling for no good reason (except vanity and speed). Nor did I correctly estimate how much free time I would have to actually execute on this at the start of the year.
Big thanks to Flame and the node-insim library which I "borrowed" a large amount of the raw unit test data from, which saved me a huge amount of time. Every packet now has some level of testing to it.
insim 3.0.0 (crates.io, docs.rs, examples):
- Now supports LFSW Relay over Websocket in both blocking and tokio (async) features of the crate
- `insim_pth` and `insim_smx` are no longer re-exported from the `insim` crate.
- Removed binrw as a dependency, speeding up packet decoding and encodingt
- AIC and AII support
- New WithRequestId trait to help shortcut making a packet with a reqi set, from anything that can be turned into a Packet (i.e. TinyType::None.with_request(RequestId(1))).
- AsyncTryReadWriteBytes and TryReadWriteBytes traits were removed, reverted to standard Read + Write, AsyncRead + AsyncWrite
- Point<T> has been removed in favour of depending on `glam` which provides a simple and fast linear algebra library for games and graphics to ensure more useful types out of the box
- You may now more easily use the library "sans-io", aka bring your own IO by not enabling either blocking or tokio features
- fix: Some consts were not public
- fix: flush incorrectly handled
- Additional examples: https://github.com/theangryangel/insim.rs/tree/main/examples
- Builder now provides useful functions to help bootstrap an insim connection
- Fixed a few crashes and improper packet definitions
- Initial release
- Initial release
Last edited by the_angry_angel, .
2.1.0 release. Wasn't planning on doing another one so early, but as there is an unexpected panic and a missing codepage I figured I probably should get it out of the door relatively quickly.
- fix: missing ^C codepage
- fix: RaceLaps panic/overflow when parsing large numbers of laps
- perf: improved performance of codepage and colour decoding
- feat: Added convenience is_xxx methods on flags, i.e. `is_remote` on NcnFlags
- feat: impl Into/From for relevant useful subtypes into Packet, meaning you can do `connection.write(TinyType::Ping).await?`
- feat: Colourify trait to help build strings with colours. It's just a helper to build strings with colours by doing this `format!("{} {}", "Hello".dark_green(), "world".red())`
- feat(strobe): A new example for client-side (aka Piran DD annoy-a-tron) showcasing impl Into/From for packet subtypes that flashes lights in a horrific sequence
2.0.0 for the suite just got released, it's a major version bump because technically it's got some breaking changes:
Most of the public API is exactly as it was.
My next task is probably going to be more on ergonomics. Eagerly looking at what Flame CZE is doing with node-insim at the moment
- MSRV was raised
- Game version is now parsed into it's own data type (see https://docs.rs/insim/latest/insim/insim/struct.Ver.html) which allows for version comparisons, etc.
- I've removed some items from being exposed publicly, mostly to do with codepage decoding, colours and escaping. This likely won't affect anyone.
- Adds support for 0.7F's new IPB packet https://github.com/theangryangel/insim.rs/pull/170
- All enums are now marked non_exhaustive (as they should've been)
Most of the public API is exactly as it was.
My next task is probably going to be more on ergonomics. Eagerly looking at what Flame CZE is doing with node-insim at the moment
Forgive me if I'm teaching you things you already know.
Generally speaking in the unix world generally most systems leverage a tool called `logrotate`, or implement their own variation in-process. You configure it to keep X copies, how often they're rotated, if they're compressed, and then what to do before and after rotation - for example restarting processes.
For a game server, I cannot imagine any more than 1-2 weeks of logs are realistically needed, imho?
Generally speaking in the unix world generally most systems leverage a tool called `logrotate`, or implement their own variation in-process. You configure it to keep X copies, how often they're rotated, if they're compressed, and then what to do before and after rotation - for example restarting processes.
For a game server, I cannot imagine any more than 1-2 weeks of logs are realistically needed, imho?
Can confirm it appears inaccessible.
All the credit really goes to you Dygear. I probably wouldn’t have pulled the trigger if not for you <3
No defeat necessary
There's plenty of room for lots of implementations Maybe it's something we can cross-pollinate / borrow ideas from each other That's the main reason why it took me so long to publish the crates. Every time I thought that I had something workable I would do a little test to see how it felt working with it and every time I felt something was wrong and I needed to introduce a breaking change. There's absolutely real value in not releasing too early
I completely respect your decision because it's the right one imho I'll agree it's certainly been fun coming up with compromises or options
Some stuff doesn't quite map nicely.There are some areas of the code I think can be done better, but they'll have to wait. The IS_HCP is a good example where I think it needs to be closer to the IS_MAL, and there are a few fields that will need some incompatible changes down the line.
I initially went down the rust-bindgen route. Which was a mistake. I'm not even sure that made it into git history. After some experiments with manually writing parsers a significant amount of time the libraries used Deku. After a few compatibility and upgrade issues and realisation that it's compile time, I started work on some home-grown macros. I realised that I was just building a half-assed version of binrw, so eventually switched to that, and I'm very happy with it at the moment.
I probably wasted the most time on the parsing and writing of packets.
Rust - insim.rs - a suite of crates to help you work with LFS
insim.rs is a suite of crates to help you work with LFS in Rust.
The intention is to provide an ergonomic, strongly typed, native rust implementation of insim and various file formats, rather than a thin layer over a series of bytes and primitive types.
Both blocking (sync) and Tokio-based async are supported (through feature flags), depending on your needs.
This was very much built for me and has become a passion project with no goal, or reason. But I hope that it can be useful for someone else.
The Future
I've got plans and ideas for the suite of crates, you can find them all here: https://github.com/theangryangel/insim.rs/issues. I do want to add Outsim, Outguage, MPR and SPR support.
However, my focus was to reach a stable API (v1.0.0) before the arrival of my 2 adopted daughters. I've just managed this, so I'll be giving them my complete focus for the next few months, at least.
Bugs and Pull Requests
Back in Feb 2021, I started work on this as an excuse to tinker with Rust after a Twitter conversation with Dygear. The original plan was just to bang out something quick and then build something fun with it.
Turns out that I enjoy a bit of yak shaving and didn't really get to the "build something" part.
There were a lot of long breaks, because of family life, and I spent an insane amount of time thinking about how to make it easy to use for people familiar with Rust and the original insim spec.
It turned out my original ideas weren't very sensible, and everything looks very different than what I had in mind originally.
Addressing that "Rewrite it in Rust" meme
I often use Insim as my "hello world" to a new language because it touches quite a number of areas.
I entered this saga thinking that I'd just bang out a library, as I've done before, and then move on. Mark Rust off the list of languages. I wouldn't publish it. I wouldn't do all the boring things like tests and documentation. I never set out to write the fastest, safest thing, in the new cool language.
I absolutely did not plan on spending a vast amount of time on this. It's completely insane. But somewhere along the way what I did find was a language which re-ignited my passion for programming, after spending years writing boring business software, for boring business people.
And I cannot explain it at all.
The intention is to provide an ergonomic, strongly typed, native rust implementation of insim and various file formats, rather than a thin layer over a series of bytes and primitive types.
Both blocking (sync) and Tokio-based async are supported (through feature flags), depending on your needs.
- The libraries are all published to crates.io.
- All libraries are documented on docs.rs (this could be massively improved, but I needed to get this out the door).
- You'll find examples in the git repo and simpler ones in the documentation.
This was very much built for me and has become a passion project with no goal, or reason. But I hope that it can be useful for someone else.
The Future
I've got plans and ideas for the suite of crates, you can find them all here: https://github.com/theangryangel/insim.rs/issues. I do want to add Outsim, Outguage, MPR and SPR support.
However, my focus was to reach a stable API (v1.0.0) before the arrival of my 2 adopted daughters. I've just managed this, so I'll be giving them my complete focus for the next few months, at least.
Bugs and Pull Requests
- If you have a bug, please log it against https://github.com/theangryangel/insim.rs/issues and I'll get to it when I can.
- Pull requests are very welcome, but if it's not aligned with the goals of the project then be prepared for rejection. If you want to do something significant/radical maybe reach out first.
Back in Feb 2021, I started work on this as an excuse to tinker with Rust after a Twitter conversation with Dygear. The original plan was just to bang out something quick and then build something fun with it.
Turns out that I enjoy a bit of yak shaving and didn't really get to the "build something" part.
There were a lot of long breaks, because of family life, and I spent an insane amount of time thinking about how to make it easy to use for people familiar with Rust and the original insim spec.
It turned out my original ideas weren't very sensible, and everything looks very different than what I had in mind originally.
Addressing that "Rewrite it in Rust" meme
I often use Insim as my "hello world" to a new language because it touches quite a number of areas.
I entered this saga thinking that I'd just bang out a library, as I've done before, and then move on. Mark Rust off the list of languages. I wouldn't publish it. I wouldn't do all the boring things like tests and documentation. I never set out to write the fastest, safest thing, in the new cool language.
I absolutely did not plan on spending a vast amount of time on this. It's completely insane. But somewhere along the way what I did find was a language which re-ignited my passion for programming, after spending years writing boring business software, for boring business people.
And I cannot explain it at all.
Last edited by the_angry_angel, .
Relay seems to be down. I think. I'm really tired and might be hallucinating.
On LFSWorld.net I'm seeing this https://imgur.com/Dnse97E
Locally I'm also unable to connect.
On LFSWorld.net I'm seeing this https://imgur.com/Dnse97E
Locally I'm also unable to connect.
Nerds <3
Good luck!
I assumed that this was a bug in my implementation and for now I've effectively hardcoded the relay to "uncompressed" format.
I'm somewhat glad I'm not going mental.
https://github.com/discourse/discourse is generally considered to be the defacto standard for forum software these days, I believe
Oooh. Nice <3
I *knew* it had to be one of you guys
I'm not sure it's really in the same price range, but there's always OVH, Hetzner, Digitalocean, etc. if a really small VM is enough. It'll be around 4-8EUR/month depending the provider, etc. :/
Vultr, Scaleway or DigitalOcean spring to mind as cheap
<3
Is it safe to assume the relay will still exist in the new world order? And is there any possibility to default servers into the relay unless private or explicitly disabled?
The only reason I’m asking is that with no dcon this makes the relay a more valuable tool for testing libraries, etc.
My condolences to friends and family.
I have fond memories of chatting with Shaun “back in the day”. Always positive
I have fond memories of chatting with Shaun “back in the day”. Always positive
whatyearisit.gif
The killer feature of LFS at it's height was undoubtedly servers like CTRA, etc. where there was a progression system, across multiple classes and servers with easy to pick up races. One off races before these types of server networks didn't keep me as interested and I never played as much before or after.
I'm now a proper adult - I own a house (which I bought as a wreck and I've been working on), I have a full time (and then some) job, I have a new extended family that I never had before, and a whole load of other stuff (gym, etc). My gaming sessions are now whenever I can get them in; leagues dont work for me, and I dont like pick up races because it feels like I'm just not doing anything. So I play stuff like BF where I can trick my brain into thinking because my XP is going up I'm not completely wasting time. Cruise servers I just dont get. If I wanted to sit in traffic I'd jump in my real car.
I've wanted to setup a kinda SaaS for a while to allow server ops to join their servers into an adhoc network via the InSim Relay to provide this experience so its not just relying on a single group. Just never got around to it, and now honestly I dont even know if the audience is really there.
If you want a response from the devs its better to contact via https://www.lfs.net/mailus rather than assuming they'll find this on the forum.
Fact of life; You put stuff on the internet, you will get port scanned. Decent software will attempt to talk to the port if it's open and try to verify what it is.
Unless you've got a reason to think you're being directly targetted I'd be surprised if its more than that.
If you're really bothered by it you can start looking at tools like fail2ban that consume the LFS server log and block the IPs (if you're on windows scripting something up using powershell, a quick regex to filter the logs and calls to create/modify firewall rules should suffice).
Unless you've got a reason to think you're being directly targetted I'd be surprised if its more than that.
If you're really bothered by it you can start looking at tools like fail2ban that consume the LFS server log and block the IPs (if you're on windows scripting something up using powershell, a quick regex to filter the logs and calls to create/modify firewall rules should suffice).
FGED GREDG RDFGDR GSFDG