Reimplement the Linux FIFO file server and client controls on Windows by using Named Pipes.
The DDNet server/client acts as a named pipe server and receives messages.
Messages can be posted to the named pipe server by connecting to it as a client.
The named pipe client can for instance be controlled from the command line with PowerShell.
The PowerShell script `scripts/send_named_pipe.ps1` is added for this purpose.
For example the PowerShell command `./send_named_pipe.ps1 "testpipe" "echo a"` sends the command `echo a` to the pipe named `testpipe`.
Multiple commands can be sent at the same time by separating them with semicolons or newlines.
Instead of considering diagonal hat inputs (e.g. up-left) as separate keys, consider them as inputs for both cardinal directions (e.g. up and left) at the same time.
This improves input with gamecontrollers that map the D-Pad to a joystick hat, as it was impossible with the previous handling to move with hat-left/right and jump with hat-up at the same time.
This means that diagonal hat buttons can no longer be used in binds, because they are no longer considered distinct buttons. It's unlikely that they would ever be useful in this game, as real joystick POV hats would not be used anyway.
Closes#6120.
This change does some more stuff:
* change the filename to include the time with seconds to be able to run
the script easier more often
* Fix that _backup tables are only moved after 1h and not immidiately in
UTC+1
* Add a parameter to configure the number of minutes the backup
* Add parameter to change timestamps to be in localtime
* consider the timeout in num_transfer calculation
* remove rows in _backup tables to not print in them in the log
* rename tables to TABLES, because it is meant to be a constant
5599: Add support for Rust code in DDNet r=def- a=heinrich5991
The glue is done using the [cxx crate](https://cxx.rs/) on the Rust side.
As a proof-of-concept, only a small console command (`rust_version`) printing the currently used Rust version was added.
You can generate and open the Rust documentation using `DDNET_TEST_NO_LINK=1 cargo doc --open`.
You can run the Rust tests using `cmake --build <build dir> --target run_rust_tests`, they're automatically included in the `run_tests` target as well.
Rust tests don't work on Windows in debug mode on Windows because Rust cannot currently link with the debug version of the C stdlib on Windows: https://github.com/rust-lang/rust/issues/39016.
---
The stuff in `src/rust-bridge` is generated using
```
cxxbridge src/engine/shared/rust_version.rs --output src/rust-bridge/engine/shared/rust_version.cpp --output src/rust-bridge/engine/shared/rust_version.h
cxxbridge src/engine/console.rs --output src/rust-bridge/cpp/console.cpp --output src/rust-bridge/cpp/console.h
```
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
The glue is done using the [cxx crate](https://cxx.rs/) on the Rust
side.
As a proof-of-concept, only a small console command (`rust_version`)
printing the currently used Rust version was added.
You can generate and open the Rust documentation using
`DDNET_TEST_NO_LINK=1 cargo doc --open`.
You can run the Rust tests using `cmake --build <build dir> --target
run_rust_tests`, they're automatically included in the `run_tests`
target as well.
Rust tests don't work on Windows in debug mode on Windows because Rust
cannot currently link with the debug version of the C stdlib on Windows:
https://github.com/rust-lang/rust/issues/39016.
---
The stuff in `src/rust-bridge` is generated using
```
cxxbridge src/engine/shared/rust_version.rs --output src/rust-bridge/engine/shared/rust_version.cpp --output src/rust-bridge/engine/shared/rust_version.h
cxxbridge src/engine/console.rs --output src/rust-bridge/cpp/console.cpp --output src/rust-bridge/cpp/console.h
```
The end anchor is removed from the grep RegEx, as it's not necessary and as it doesn't work on Linux systems when the crash log uses Windows line endings.
Update Dr. Mingw (ExcHndl) to 0.9.8.
Use the new `ExcHndlSetLogFileNameW` function to set the exception log file name using wide characters, to support paths containing unicode.
It's not necessary to call `ExcHndlInit` explicitly after loading `exchndl.dll`, as the `DllMain` will already initialize the exception handler when the DLL is loaded.
Module offsets are supported by upstream ExcHndl now, so we don't need to provide our own version that supplies the module offset to `ExcHndlInit` anymore.
Upstream ExcHndl will also resolve the source code lines for addresses automatically, when the executable is build with debug information.
Handle the cases that the exception handling module cannot be loaded and that the `ExcHndlSetLogFileNameW` function cannot be found in the module.
Update `scripts/parse_drmingw.sh`:
- Parse both old and new module offsets.
- Use tabs instead of spaces consistently.
- Reset the ANSI color after printing colored messages.
Remove square brackets to reduce the amount of space used.
Add log level indicator. The position between timestamp and system was
chosen because it is at a fixed position (unlike after the system) but
the log still remains naively sortable (which wouldn't happen if we were
to place it in front of the timestamp.
Before:
```
[2022-04-29 15:25:37][engine]: running on unix-linux-amd64
[2022-04-29 15:25:37][engine]: arch is little endian
[2022-04-29 15:25:37][storage]: added path '$USERDIR' ('/path/to/home/.teeworlds')
[2022-04-29 15:25:37][storage]: added path '$DATADIR' ('data')
[2022-04-29 15:25:37][storage]: added path '$CURRENTDIR' ('/path/to/ddnet')
[2022-04-29 15:25:37][host_lookup]: host='localhost' port=0 1
[2022-04-29 15:25:37][host_lookup]: host='localhost' port=0 2
[2022-04-29 15:25:37][console]: executing 'autoexec_server.cfg'
```
After:
```
2022-04-29 15:25:37 I engine: running on unix-linux-amd64
2022-04-29 15:25:37 I engine: arch is little endian
2022-04-29 15:25:37 I storage: added path '$USERDIR' ('/path/to/home/.teeworlds')
2022-04-29 15:25:37 I storage: added path '$DATADIR' ('data')
2022-04-29 15:25:37 I storage: added path '$CURRENTDIR' ('/path/to/ddnet')
2022-04-29 15:25:37 I host_lookup: host='localhost' port=0 1
2022-04-29 15:25:37 I host_lookup: host='localhost' port=0 2
2022-04-29 15:25:37 I console: executing 'autoexec_server.cfg'
```
When the client or server crash the fifo will be dead
then the cleanup command hangs at
echo "quit" > client1.fifo
because the fifo is not responding and thus it is stuck there.
which causes the user to probably ctrl+c at some point
which then avoids client2 to be quit which might not have crashed
So this commit checks if a fail_client1.txt file exits and if it crashed
already it will skip the call to the broken fifo
5495: Fix Android build r=heinrich5991 a=Jupeyy
- Video recorder off
- small fix in logger.cpp
Tested on Java-17
## Checklist
- [ ] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: Jupeyy <jupjopjap@gmail.com>
4829: Added map_replace_area tool r=def- a=sctt
Motivation:
sometimes mappers need to copy a certain area from a map to another (but also to a different position of the same map).
that's very time consuming on complex maps, as tiles and quads layers have to be manually copied one by one.
map_replace_area is designed to automatically replace all the tiles and quads from a specific area to another.
`Usage: map_replace_area <from_map> <from_x> <from_y> <to_map> <to_x> <to_y> <width> <height> <output_map>`
PoW screenshots attached below.
note: for the moment map_replace_area suppose that you are working on the same map (that's what i needed), that means source and destination maps must have the same layers structure, or else an error is returned.
but i understand it might be useful to also work on totally different maps, in that case users must be able specify layers they want to consider by associating source map layers to destination map layers (by using a config file maybe).
i'm probably going to make another PR to add this enhancement in the future.
PoW:
5343: Add rcon and chat to integration test r=def- a=ChillerDragon
Add more action to the integration test script: chat messages, chat commands, rcon commands.
This unlocks more code coverage at runtime to catch asan issues.
It adds a very restrictive regex on the log format. But I am happy to maintain that in case changes to the log output happen.
The current version is already supporting heinrichs refactor https://github.com/ddnet/ddnet/pull/5036
Also ensure chat messages arrive in the correct format. Would have catched the following issues:
https://github.com/ddnet/ddnet/issues/5342https://github.com/ddnet/ddnet/issues/5340https://github.com/ddnet/ddnet/issues/5302https://github.com/ddnet/ddnet/pull/5126
DEPENDS ON:
https://github.com/ddnet/ddnet/issues/5342https://github.com/ddnet/ddnet/issues/5340
5465: Change from pnglite to libpng for PNG reading r=def- a=heinrich5991
This is desirable mainly because libpng is maintained and pnglite is
not. pnglite was last updated in 2007 (15 years ago) and probably has a
lot of security vulnerabilities.
libpng is an actively maintained library also used by browsers like
Firefox or Chromium, so it's less likely to contain security
vulnerabilities, also it's more likely to be packaged by Linux
distributions.
This also refuses to load images of types not supported by pnglite,
which allows us to think about backward compatibility while also
introducing libpng.
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test if it works standalone, system.c especially
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: sctt <scottistefano91@gmail.com>
Co-authored-by: term <term@term.sinervis.pri>
Co-authored-by: f <scottistefano91@gmail.com>
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
Co-authored-by: ChillerDragon <ChillerDragon@gmail.com>
Co-authored-by: def <dennis@felsin9.de>
Co-authored-by: Jupeyy <jupjopjap@gmail.com>
See also Jupeyy's explanation in
https://github.com/ddnet/ddnet/issues/4294 for why we want to ignore
this:
> sadly components have no OnDestruct on anything like that
> so aslong it doesn't actually leak it's just non destructed memory
So it's something we allocate once for the entire client lifetime from
my understanding.
=================================================================
==421461==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 411760 byte(s) in 10 object(s) allocated from:
#0 0x55eaf0c08a29 in malloc (/media/ddnet/integration_test/DDNet+0x736a29)
#1 0x55eaf0de9f72 in CCommandProcessorFragment_OpenGL2::Cmd_CreateBufferObject(CCommandBuffer::SCommand_CreateBufferObject const*) /media/ddnet/src/engine/client/backend/opengl/backend_opengl.cpp:1898:25
#2 0x55eaf0dd82f5 in CCommandProcessorFragment_OpenGL::RunCommand(CCommandBuffer::SCommand const*) /media/ddnet/src/engine/client/backend/opengl/backend_opengl.cpp
#3 0x55eaf0f73229 in CCommandProcessor_SDL_GL::RunBuffer(CCommandBuffer*) /media/ddnet/src/engine/client/backend_sdl.cpp:246:20
#4 0x55eaf0f70568 in CGraphicsBackend_Threaded::ThreadFunc(void*) /media/ddnet/src/engine/client/backend_sdl.cpp:75:25
#5 0x55eaf0d679d7 in thread_run(void*) /media/ddnet/src/base/system.cpp:686:2
#6 0x7f08b788c54c (/usr/lib/libc.so.6+0x8c54c)
SUMMARY: AddressSanitizer: 411760 byte(s) leaked in 10 allocation(s).
As described in #5295, the integration test script waits for the client
to close before launching the next one. I don't know what causes this,
but disabling full-screen mode works around the issue.
I don't know if this is okay. @ChillerDragon?
Fixes#5295.
ChillerDragon
