* Introduces `RawInterpolatedStringHandler` which is exactly the same as `DefaultInterpolatedStringHandler` except it _unsafely exposes_ it's `ReadOnlySpan<char>` buffer. This is useful for writing the string's data without actually building the string.
* Uses this new string interpolation handler in `SpanWriter` to eliminate intermediate strings built. This is immensely useful in eliminating string allocations in writing Gump packets.
### Enabling Packet Logging
`[packetlogging on` and target the user.
Supports command modifiers such as:
`[online packetlogging on where accesslevel = player`
Logs are saved in `path/<ip address>/packets.log`. It is a simple append-format log with no date splitting.
SpanWriter now has an argument that allows it to be resizable.
```cs
public SpanWriter(Span<byte> initialBuffer, bool resize = false)
public SpanWriter(int initialCapacity, bool resize = false)
```
If a SpanWriter is set to be resizable, or given an initial capacity instead of a buffer, it must be disposed:
```cs
public static void SomeMethod()
{
using var writer = new SpanWriter(stackalloc byte[512], true);
// stuff
// Automatic Dispose of writer
}
```
This is because the SpanWriter uses `ArrayPool<byte>.Shared` _rented buffers_ to resize. If the writer is not disposed, those buffers will never be reused resulting in a _memory leak_.
It is possible that the SpanWriter will outright ditch the initial buffer if resize is set to true and growing is needed. To check/account for that we can do the following:
```cs
public static void SomeMethod()
{
Span<byte> span = stackalloc byte[512];
using var writer = new SpanWriter(span, true);
// write some stuff that causes the span to grow
span = writer.RawBuffer;
// Do stuff with the span
}
```
Make sure you don't accidentally `Dispose()` the writer or use the `RawBuffer` outside of the `using` block. If you do, bad things will happen! (NullPointerException, or a fresh SpanWriter with no buffer, depending on the situation).
SpanWriter can also now be used with a fixed statement since it has a `PinnableReference()` function.
- [X] Updates Movement packets
- [X] Adds OSI fastwalk packets. These aren't used on OSi anymore.
- [X] Adds new movement handling, but looks like the client doesn't use it. (Also leaving the 0x4000 Character List Flag off)
- [X] Adds time sync request handler, but also looks like the client doesn't use it.
- [X] Adds time sync response for time sync, just in case, but it isn't used, so not sure about the arguments.
- [X] Reimplements RunUO's fastwalk to use a circular array on the netstate instead of every mobile
- [X] Removes ClearFastwalkStack from RunUO implementation. This shouldn't be needed anymore
Changed fastwalk settings:
```cs
public static int WalkFootDelay { get; set; } = 440;
public static int RunFootDelay { get; set; } = 220;
public static int WalkMountDelay { get; set; } = 220;
public static int RunMountDelay { get; set; } = 110;
public static bool EnableFastwalkPrevention { get; set; } = true;
public static AccessLevel FastwalkExemptionLevel { get; set; } = AccessLevel.Counselor;
// If this is changed during runtime, then the steps array needs resizing.
public static int MaxSteps { get; private set; } = 4;
```
modernuo.json
```json
{
"settings": {
"movement.delay.runFoot": "220",
"movement.delay.runMount": "110",
"movement.delay.walkFoot": "440",
"movement.delay.walkMount": "220",
"movement.enableFastWalkPrevention": "True",
"movement.fastwalkExemptionLevel": "Counselor",
"movement.maxSteps": "4"
}
}
```
Notes about OSI fastwalk:
While it does work, I can't find a benefit in using it because of the variable speeds. If players moved at a single speed then we could refill the stack every X milliseconds with 6 keys and use a naive token bucket implementation.
Unfortunately variable speeds mount/run/walk/etc means we would have to use a leaky bucket algorithm.
If we are using a leaky bucket algorithm with a variable leak, then we don't need to send tokens because we are already tracking it on the server side.
ModernUO vs OSI Fastwalk:
When the fastwalk was implemented on OSI, it used up to 6 tokens. These tokens were probably distributed every 600-750 milliseconds. To get the same effect, the new fastwalk settings might need to be adjusted. I would tweak them and feel free to let me know what worked for you!
Bumps release version
- [X] Updates result so it is preallocated
- [X] Updates PipeWriter so it is awaitable
- [X] Simplifies NetState code to match changes
- [X] Adds a byte for empty checking so incoming/outgoing can have full pipes.
Bumps release version
- [X] Moved packets from objects to functions
- [X] Fixed bug where characters were showing up with their modded names in the character list
Bumps release version
