2,889,786 events, 1,482,905 push events, 2,365,598 commit messages, 178,551,415 characters
New branch convert-to-library
Decided this project could do with some new love and attention...
What's new?
-
Web sockets I needed a web socket and rather than adding a massive external library I thought it would be nice to have another small addition and was able to learn about the underlying technology. Fun :)
-
Move to a library This project was originally supposed to be a library but it turned into a web server example project, so I have now included both. One that you can import easily, and another you can run for a demo.
-
Added a Router I had a need to port my JS client-side router to C# and found it useful so it's staying for now, this has been upgraded in the example demo.
-
New namespaces/class names I felt these are now better this way. Eventually I may tune websocket to WebSockets.Client and WebSockets.Server and currently undecided since there is no need for a WebSocket client right now...
-
Fixes to serve directory in example project This has been slightly updated so that the messages are more consistent across directories, along with removal of 'Runnables' which weren't an entirely satisfying method for index/filetype resolution.
-
cjs extension is now a route Similar to a nginx *.php route, this should now perform similar sequences but at the moment it's mostly unused functionality.
-
Fixed constant client IOException This was found as it should ideally have been handled in the request read method than outside of it, and I've changed to a sane timeout as I felt we were timing out too quickly for slow machines or network connections.
As with any commit I've made sure to tidy things up too. These changes should be quite stable... Yay :)
Add EnumFlags.h
so that we can generically use restrictive enums with bitwise operators
sometimes I hate C++, but at least its write ugly shit once
-
Port over "Get rid of RR_RESERVED_ROOT_DIR_FD" from the following rr (https://github.com/rr-debugger/rr) commit:
commit 25c93ba12c2e05d355eb599727bf9c39c95e99a1 Author: Keno Fischer keno@juliacomputing.com Date: Thu Apr 2 01:04:28 2020 -0400
Get rid of RR_RESERVED_ROOT_DIR_FD Admittedly, this change is primarily motivated by a philisophical objection to RR_RESERVED_ROOT_DIR_FD, rather than any great practical need. It just seems to me that if the tracee went through all the trouble of hiding the real root, then we shouldn't just give it an easy way to get it back. Of course, I'm not suggesting that this would be the only issue with running an external rr tracer on a sanboxed process without compromising that sandbox's security guarantees - I'm sure there's many others. However, this one's a pretty obvious one, so I'd like to remove it if possible. That said, there are a couple of minor practical benefits: - It's more robust to weird setups (weird mount setups, tmp being a symlink). - It's more robust when recording programs that change uid - As a result, we can get rid of a few fallbacks that would only get used if we happened to be in one of these weird setups (e.g. where we would fail to map the rr page). - We can use memfd in more cases. This is a slightly benefit if /tmp happens to not be a tmpfs, which happens occasionally. - There was a note in the code that things could fail in the nesting scenario if somebody chroot'ed between the outer and the inner rr (e.g. by recording a container that itself launched an rr process). That should work fine now. - We avoid a corner case where after a setuid, some files in the trace directory would have the wrong uid. None of these are particularly important, but together, I find them convincing enough that I think this is worth doing (I happened to need the send_fd functionality this depends upon for an unrelated change, which made doing this quite easy). The one place where this is slightly annoying is in open_mem_fd, because we now need to send an fd and then get a new fd back. However, that only needs to happen if rr fails to open /proc/<pid>/mem. A comment in the code says that Ubuntu kernels have this behavior. However, I was unable to reproduce on current Ubuntu kernels. It's also counterbalanced by allowing us to do slightly fewer syscalls elsewhere. And lastly, with pidfd_getfd and related functionality, these kinds of file transfers might in the future be quite a bit faster anyway.
-
Also make various misc/related changes especially related to path/filename handling
This commit adds today's weather along with the morning, evening and night weather details. Also adds nested scrolling to support landscape mode
Get rid of RR_RESERVED_ROOT_DIR_FD
Admittedly, this change is primarily motivated by a philisophical objection to RR_RESERVED_ROOT_DIR_FD, rather than any great practical need. It just seems to me that if the tracee went through all the trouble of hiding the real root, then we shouldn't just give it an easy way to get it back. Of course, I'm not suggesting that this would be the only issue with running an external rr tracer on a sanboxed process without compromising that sandbox's security guarantees - I'm sure there's many others. However, this one's a pretty obvious one, so I'd like to remove it if possible.
That said, there are a couple of minor practical benefits:
- It's more robust to weird setups (weird mount setups, tmp being a symlink).
- It's more robust when recording programs that change uid
- As a result, we can get rid of a few fallbacks that would only get used if we happened to be in one of these weird setups (e.g. where we would fail to map the rr page).
- We can use memfd in more cases. This is a slightly benefit if /tmp happens to not be a tmpfs, which happens occasionally.
- There was a note in the code that things could fail in the nesting scenario if somebody chroot'ed between the outer and the inner rr (e.g. by recording a container that itself launched an rr process). That should work fine now.
- We avoid a corner case where after a setuid, some files in the trace directory would have the wrong uid.
None of these are particularly important, but together, I find them convincing enough that I think this is worth doing (I happened to need the send_fd functionality this depends upon for an unrelated change, which made doing this quite easy).
The one place where this is slightly annoying is in open_mem_fd, because we now need to send an fd and then get a new fd back. However, that only needs to happen if rr fails to open /proc//mem. A comment in the code says that Ubuntu kernels have this behavior. However, I was unable to reproduce on current Ubuntu kernels. It's also counterbalanced by allowing us to do slightly fewer syscalls elsewhere. And lastly, with pidfd_getfd and related functionality, these kinds of file transfers might in the future be quite a bit faster anyway.
(cherry picked from commit 25c93ba12c2e05d355eb599727bf9c39c95e99a1)
feat: Define SSMRunCommandPolicy in the CDK stack
Moving the SSMRunCommandPolicy resource into the CDK stack.
This is chosen because it's fairly easy to test if it works: if successful, we can continue to connect to an instance using ssm-scala.
AMIgo's stack defines two additional actions over the standard GuSSMRunCommandPolicy:
- ssm:StartSession
- ssm:TerminateSession
Slightly annoyingly, GuSSMRunCommandPolicy is a singleton and doesn't accept additional input.
Therefore, we have to add these actions into a new statement on the policy.
GuSSMRunCommandPolicy's Roles array is kinda hilarious (see snapshot test change).
The good news is it's done by AWS CDK magic, so should work!
Fix regression: quick stopping changing drawframe
This fixes a regression that desyncs my Nova TAS after re-removing the 1-frame input delay.
Quick stopping is simply holding left/right but for less than 5 frames. Viridian doesn't decelerate when you let go and they immediately stop in place. (The code calls this tapping, but "quick stopping" is a better name because you can immediately counter-strafe to stop yourself from decelrating in the first place, and that works because of this same code.)
So, the sequence of events in 2.2 and previous looks like this:
- gameinput()
- If quick stopping, set vx to 0
- gamerender()
- Change drawframe depending on vx
- gamelogic()
- Use drawframe for collision (whyyyyyyyyyyyyyyyyyyyyyyyyyyy)
And now (ignoring the intermediate period where the whole loop order was wrong), the sequence of events in 2.3 looks like this:
- gamerenderfixed()
- Change drawframe depending on vx
- gamerender()
- gameinput()
- If quick stopping, set vx to 0
- gamelogic()
- Use drawframe for collision (my mind has become numb to pain)
So, this means that all the player movement stuff is completely the same. Except their drawframe is going to be different.
Unfortunately, I had overlooked that gameinput() sets vx and that animateentities() (in gamerenderfixed()) checks vx. Although, to be fair, it's a pretty dumb decision to make collision detection be based on the actual sprites' pixels themselves, instead of a hitbox, in the first place, so you'd expect THAT to be the end of the dumb parade. Or maybe you shouldn't, I don't know.
So, what's the solution?
What I've done here is added duplicates of framedelay, drawframe, and walkingframe, for collision use only. They get updated in gamelogic(), after gameinput(), which is after when vx could be set to 0.
I've kept the original framedelay, drawframe, and walkingframe around, to keep the same visuals as closely as possible.
However, due to the removal of the input delay, whenever you quick stop, your sprite will be wrong for just 1 frame - because when you let go of the direction key, the game will set your vx to 0 and the logical drawframe will update to reflect that, but the previous frame cannot know in advance that you'll release the key on the next frame, and so the visual drawframe will assume that you keep holding the key.
Whereas in 2.2 and below, when you release a direction key, the player's position will only update to reflect that on the next frame, but the current frame can immediately recognize that and update the drawframe now, instead of retconning it later.
Basically the visual drawframe assumes that you keep holding the key, and if you don't, then it takes on the value of the collision drawframe anyway, so it's okay. And it's only visual, anyway - the collision drawframe of the next frame (when you release the key) will be the same as the drawframe of the frame you release the key in 2.2 and below.
But I really don't care to try and fix this for if you re-enable the input delay because it's minor and it'd be more complicated.
sort anims into folders
the filenames are used in the scripts, NOT their names in the animation controller, and since some were duplicate, they got an _0 or _1 at the end by the decompile, and that broke the scripts because the player was looking for an anim called "Eat" and that didn't work when the anim was actually called "Eat_0" in the fucking files, holy shit what is this why did that not work, anyways fixed now, no more issue
The first alpha is almost finished !
YAY !
With constant values support ! I'll go with that first, anyway. Dynamic variables support might follow afterwards. I have to support constant first, since ReadDynamicVariable needs you to provide the name... through a constant string value !
You can try to load the Example program (and don't click on Save before, or you'll nuke it !) to see how it goes at the moment.
There's still SO many things to fix. I've hit many issues with Godot, with things like :
- Inability to parse 64-bit integers from strings (in 2021)
- Hash() functions returning the same numbers on different strings
- The sheer inability for Godot to provide code completion on typed onready var variables
- The whole inspector to script nodes attributions being broken
Still, the GraphEdit system is kind of working correctly, and thanks to that, the first alpha should be released once the interpretor is done on the NeosVR side. I'll add Websocket streaming support for that reason, since parsing files on NeosVR is stupidly hard, if you want some user-friendlly interaction.
So, yeah... SOON ! ON YOUR SCREEN ! Remote LOGIX Alpha 1
Signed-off-by: Voyage voyage@miouyouyou.fr
[DNM] raphael: Ignore selinux neverallows
- Fuck you, Dirac.
Change-Id: If2df6adb12d28219c9541ed2ff7a0d9a6f54b745
I was missing the whole I FUCKING HATE MY LIFE kind of feel UwU
Bad Boys Den: Update of Raider's Base. (#325)
- Bad Boys Den: Update of Raider's Base.
Remade one shop to Butcher Shop. Add a small Warehouse with graveyard. Slightly remade a Garage, improved living house and the Bar.
-
Bad Boys Den: Small Fixes
-
Bad Boys Den: Hatred of Low Walls
Fixed god damn low walls. Also added a few things like carcass. pickaxes etc.
- Bad Boys Den: Extra Fixes fo free!
Spotted a some few small errors. Fixed it.
-
Bad Boys Den: End My Suffering
-
Bad Boys Den: Area Errors...Area Errors Everywhere!
Fixed an areas near Administration.
Co-authored-by: Edward Nashton eddienigma48@gmail.com
fuck you yo worthless piece of shit external hard drive I fucking hate you