Ah yep, I read about the TCP RST problem in one of the RFC docs, then promptly forgot about it and never implemented anything to avoid it. Thankyou for the detailed notes.
Found the issue - a use after free in send_response() if I close the session early due to an error. Was continuing to the next bit. Put a temp fix in place, will push a proper one later.
Other tips: I still had issues going too granular with GOAP actions at the start, so I recommend keeping your actions as coarse as possible. It's still a tool that you use with your AI designer hat on, it doesn't do everything on its own. But the power of being able to throw in a new goal, maybe one new action, and have the existing actions solve all the other prerequisites, is amazing. Defining world properties and states is a muuuuuuch lower mental load than using utilities for actions.
I wrote it all with performance in mind, and it seems to run fine. Basically lots of caching (each world property is only evaluated once per AI per tick then re-used, shared values are cached for all then re-used, etc); eliminating invalid paths early; and searching backwards from the goal instead of forwards from the current world state. I test with 4 AI players on an old i3 laptop processor from ~2016 without issue.
Hey, thanks! I was thinking about game ideas while stepping into the shower one day (where all great ideas are born), and "throwing people in a first-person view might be fun?" came across my mind. I mentally fleshed it out a bit, and wrote it down. When the idea I was already working on turned out to not be fun, I shelved that and started working on this instead. When I prototyped the basic throw feel and it already felt fun, I decided to run with it.
Not sure if this is still true RE: Azure. AFAIK they use Hyper-V (hypervisor) containers which offer kernel isolation like other lightweight-VM-container runtimes.
Isn't it more likely that this would have unfound vulnerabilities in it, and you'd still need to have this open to the internet to get similar benefits to Tailscale proper?
> A very slow raytracer in PowerShell that has been optimised from ~100 camera rays traced per second to 4000 rays per second on a 4GHz 6 core CPU with a few tricks
> Because I've been learning a bit of serverless stuff I was curious as to how much faster I could run this using PowerShell in a webscale™ setup by distributing the processing over as many concurrently running lambdas as I could get in my AWS account:
> By using Lambda with large memory sizes to get more cores I had >250,000 camera rays per second (~62x my laptop speed) but I managed to rack up a $200 bill over a couple of bad runs