| TimRiker | I upgraded my debian box to 12.1 which has php 8.2 | 00:18 |
|---|---|---|
| Juest | compiling dependencies | 00:32 |
| Juest | it complains at linking | 00:32 |
| Juest | maybe i have to clear my folders from old files | 00:33 |
| blast007 | and you're using the latest 2.4 branch of the dependencies? | 00:34 |
| Juest | yup | 00:35 |
| Juest | it succeeded for sdl2 release but failed for debug | 00:43 |
| blast007 | what error are you seeing? | 00:44 |
| blast007 | throw it up on a pastebin | 00:45 |
| Juest | https://pastebin.pl/view/a4e0e749 | 00:51 |
| Juest | https://pastes.io/7pkfeufhcg better pastebin site | 00:54 |
| blast007 | from the bzflag-dependencies folder, try a 'git clean -xfd' and then run buildVC2017.bat again | 00:57 |
| Juest | do you know a good man2html program for windows that works? | 00:59 |
| Juest | i have one from 2017 but it looks like its hung | 00:59 |
| Juest | for some weird reason | 00:59 |
| blast007 | besides the one in our misc/ directory? | 01:01 |
| Juest | yeah, for some reason it seems untracked or something | 01:02 |
| blast007 | untracked? | 01:02 |
| Juest | wait let me compile it then | 01:03 |
| Juest | i dont know how it was built | 01:03 |
| Juest | i have a man2html.exe file from 2017 in the man folder | 01:03 |
| blast007 | it's part of our Windows build | 01:03 |
| Juest | and it doesnt work | 01:03 |
| Juest | ah okay, it'll get replaced then | 01:03 |
| blast007 | what | 01:03 |
| blast007 | FYI, it's not a GUI program | 01:04 |
| Juest | where does man2html from the bzflag tree get built to? | 01:04 |
| Juest | yeah i know its a cli program | 01:04 |
| Juest | it appears stuck | 01:04 |
| blast007 | yeah, cuz that's not how it works | 01:04 |
| blast007 | you don't just run it alone | 01:04 |
| Juest | sorry then | 01:04 |
| blast007 | trying to find which project actually uses it | 01:05 |
| blast007 | ah, there's a makeHTML.bat file in the MSVC/build/ directory | 01:07 |
| Juest | got it | 01:09 |
| Juest | sorry for my forgetfulness/ignorance | 01:09 |
| Juest | do 64 bits build work yet? | 01:10 |
| blast007 | no | 01:10 |
| Juest | what's left? | 01:10 |
| blast007 | I think it's the dependencies that don't all build 64-bit with their current build method | 01:10 |
| blast007 | if I switched to calling their CMake projects it might be okay | 01:11 |
| Juest | interesting | 01:11 |
| Juest | why bzflag-dependencies stopped receiving github releases? | 01:11 |
| blast007 | cuz I got lazy | 01:11 |
| Juest | i wanted to disable the spectre mitigations but too difficult to figure out this setup | 01:12 |
| blast007 | why? | 01:12 |
| Juest | not needed and performance penalty | 01:12 |
| blast007 | and the 1000+ FPS we get isn't enough? :) | 01:13 |
| Juest | :) | 01:13 |
| Juest | i guess i could run bzflag under remote desktop | 01:13 |
| Juest | to reproduce with a debugger attached | 01:14 |
| Juest | which i prefer windbg | 01:14 |
| blast007 | why would RDP help with that? | 01:14 |
| blast007 | what you might be able to use is remote debugging: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging?view=vs-2022 | 01:15 |
| Juest | im aware about the remote debugger stuff | 01:15 |
| Juest | dont have the vs 2017 one installed here i think | 01:15 |
| Juest | and i still wouldnt be able to run it on my win7 if i dont copy the debug "redist" files | 01:16 |
| Juest | wonderful, now it succeeded | 01:16 |
| blast007 | actually it seems like the dependencies *might* all work in x64. (I do have the part that sets the arch to x64 commented out in the .bat file, but that can be uncommented by removing the ::) | 01:36 |
| blast007 | but then trying to actually build the game in x64 leads to a couple errors. 2532 errors to be exact, and 466 warnings. :) | 01:36 |
| blast007 | might be some project settings that are messed up in the x64 configuration | 01:37 |
| Juest | im copying manually the pdb files to the bzflag directory | 01:59 |
| Juest | im going to use windbg locally | 01:59 |
| Juest | i dont know | 02:04 |
| Juest | it doesnt crash in debug blast007 | 02:05 |
| Juest | oh i got it to crash actually | 02:05 |
| Juest | it's a C++ EH exception | 02:06 |
| Juest | blast007 https://pastes.io/xblyvve3ey | 02:10 |
| Juest | i have -dddd passed as argument, if it matters anything in the crash | 02:12 |
| Juest | okay now i actually crashed it | 02:15 |
| Juest | in the right condition | 02:15 |
| Juest | https://pastes.io/4t19nf4pbc | 02:16 |
| Juest | okay, there goes the crash | 02:17 |
| Juest | i reproduced it on a debug build with stack trace | 02:17 |
| Juest | does that help? | 02:17 |
| Juest | wow im getting a bit of a deja vu | 02:19 |
| Juest | this crash happens easily on a server with players | 02:19 |
| Juest | the crash doesnt happen if i am alone observing | 02:20 |
| Juest | awesome i crashed during the worldunpack | 02:22 |
| Juest | 0018b090 00579ae4 bzflag!WorldBuilder::unpack(void * buf = 0x07ea5220)+0x280 [z:\bzflag\src\bzflag\worldbuilder.cxx @ 112] | 02:23 |
| Juest | 0018b230 0057b6a6 bzflag!loadCachedWorld(void)+0x414 [z:\bzflag\src\bzflag\playing.cxx @ 1738] | 02:23 |
| Juest | im testing worlds with custom textures to see what happens | 02:25 |
| blast007 | ah, I wonder if I was testing on an empty server before | 02:25 |
| Juest | im finding all sorts of different bugs now | 02:26 |
| Juest | now its a render crash | 02:26 |
| Juest | mesh draw crash | 02:26 |
| Juest | https://pastes.io/klyk3wervh | 02:27 |
| Juest | i've determined that im more likely to crash on custom servers that download textures and have its own world | 02:27 |
| Juest | i managed to crash it by reconnecting while it was trying to unpack the world | 02:27 |
| Juest | those crashes are very random but they have something in common: im attempting reconnects at the same time | 02:28 |
| Juest | i cant crash in vanilla worlds | 02:31 |
| Juest | as in maps that dont use custom stuff | 02:32 |
| blast007 | note that a backtrack from a program crash isn't always useful, since it could be a buffer overflow writing over some other memory that makes the program barf in another location | 02:32 |
| Juest | what should i be looking into? | 02:32 |
| blast007 | something like this can help find memory-related programming errors: https://github.com/dynamorio/drmemory | 02:34 |
| Juest | let me see | 02:35 |
| Juest | the stacktrace is consistent when i crash on planetmofo | 02:37 |
| blast007 | building here again to see if I can reproduce it with that additional info | 02:38 |
| Juest | it could be my computer | 02:39 |
| Juest | i have a very strange bug with a game | 02:39 |
| Juest | that sticks across installations on this computer only | 02:39 |
| Juest | it crashes because it sets a pointer to itself at some point during initialization instead of setting the correct data | 02:39 |
| blast007 | what cpu/gpu does the system with the crash have? | 02:42 |
| Juest | i7 4790k evga gtx 1660 | 02:43 |
| Juest | i'll try to reproduce this on my other computer ove remote desktop | 02:44 |
| Juest | over* | 02:44 |
| Juest | to discard that it could be a bug with my hardware instead of a bzflag problem | 02:44 |
| Juest | i cant get it to run | 02:49 |
| Juest | crashing with a c++ eh exception | 02:49 |
| blast007 | ooo, I got it to crash | 02:50 |
| Juest | okay good | 02:50 |
| blast007 | it caught an exception in MeshDrawInfo::updateAnimation | 02:50 |
| Juest | in planetmofo? | 02:50 |
| blast007 | yeah | 02:50 |
| Juest | weird, i was getting a crash on player | 02:50 |
| Juest | twice even | 02:51 |
| Juest | try it again, maybe it crashes on something else | 02:51 |
| blast007 | I have the world file cached, but deleted the http cache for the images, and then spammed connect | 02:51 |
| Juest | i have everything cached | 02:51 |
| blast007 | read access voluation. this->animInfo was 0xDDDDDDDD | 02:51 |
| blast007 | and DDDDDDDD is a magic number for "Used by MicroQuill's SmartHeap and Microsoft's C/C++ debug free() function to mark freed heap memory" | 02:51 |
| Juest | the world crash unpack crash happens if you are downloading the world and reconnect when it finished | 02:51 |
| blast007 | https://en.wikipedia.org/wiki/Magic_number_(programming) | 02:51 |
| Juest | interesting | 02:52 |
| Juest | you couldnt really process the windbg output i posted? | 02:52 |
| Juest | the player crash | 02:53 |
| blast007 | ah, didn't see that | 02:53 |
| blast007 | FEEEFEEE is another magic number | 02:53 |
| Juest | should i check out the crash on release with the pdbs? | 02:53 |
| blast007 | I don't know | 02:54 |
| Juest | it happens on release but i dont have debug information | 02:55 |
| Juest | can you reproduce on release yourself? | 02:55 |
| blast007 | I can reproduce it on debug, so is there a reason to reproduce on release? | 02:56 |
| Juest | okay, i dont know, but thought maybe things are different on release because of optimizations | 02:56 |
| blast007 | wonder if it crashes on linux too | 02:57 |
| Juest | i could try to repro on mac | 02:58 |
| Juest | do you have any idea where the problem might lie in? | 02:58 |
| Juest | i guess its in custom maps | 02:58 |
| Juest | considering that im not crashing on vanilla | 02:58 |
| Juest | vanilla as in maps that use stock geometries | 02:59 |
| Juest | rather than meshes | 02:59 |
| Juest | im back again at a c++ eh exception crash | 03:00 |
| blast007 | it might be specific to maps with drawinfo, which would be very few maps | 03:00 |
| Juest | okay, i think its a crash that happens explicitly with maps that use meshes | 03:00 |
| blast007 | MeshDrawInfo I *believe* would be the drawInfo object in BZW | 03:01 |
| Juest | crashed on the quickshot server map | 03:01 |
| Juest | i had a crash on player in planetmofo | 03:01 |
| Juest | it seems to change | 03:02 |
| Juest | but you think the meshdrawinfo was the correct stacktrace? | 03:02 |
| blast007 | it very well could be | 03:02 |
| blast007 | I got a crash on Linux too :) | 03:03 |
| Juest | awesome | 03:04 |
| Juest | i noticed another bug in the middle of this | 03:04 |
| Juest | it says error on md5 removing offending file | 03:04 |
| Juest | but it gets stuck there | 03:04 |
| Juest | when i reconnect it says the same message | 03:04 |
| Juest | should i open a issue on github? | 03:04 |
| Juest | i got the player stacktrace again | 03:05 |
| Juest | are you getting different stacktraces too or always the same one? | 03:05 |
| blast007 | I didn't run in gdb on linux yet, but I ran it through valgrind (a memory error debugger) and I'm seeing issues in MeshDrawInfo::updateAnimation there too, among other MeshDrawInfo functions | 03:07 |
| Juest | oh wow, so it seems correct | 03:07 |
| blast007 | so it looks like we're trying to read freed memory | 03:08 |
| Juest | should i run it through drmemory? | 03:08 |
| Juest | should we bisect this? | 03:08 |
| blast007 | kinda doubt a bisect will help, since I imagine this issue has always existed since drawInfo was added | 03:09 |
| Juest | hmm interesting | 03:09 |
| Juest | when was drawinfo added? | 03:09 |
| blast007 | for 2.0 I believe | 03:09 |
| Juest | i want to say i experienced this bug before but i cant recall | 03:09 |
| blast007 | yeah, I believe it was you that posted an issue for it | 03:10 |
| blast007 | https://github.com/BZFlag-Dev/bzflag/issues/128 | 03:10 |
| Juest | there we go | 03:15 |
| Juest | yeah its the same issue | 03:15 |
| Juest | should i update that with the new information? | 03:15 |
| Juest | well, you | 03:16 |
| BZNotify | bzflag: blast007 commented on issue #128 "Client crash when hitting Connect multiple times" by Juesto (https://github.com/BZFlag-Dev/bzflag/issues/128#issuecomment-1703668925): This may be an issue specific to servers running maps that use draw... | 03:16 |
| BZNotify | bzflag: Juesto commented on issue #128 "Client crash when hitting Connect multiple times" (https://github.com/BZFlag-Dev/bzflag/issues/128#issuecomment-1703670448): addendum:... | 03:19 |
| *** TD-Linux <TD-Linux!~Thomas@user/td-linux> has quit IRC (Server closed connection) | 03:20 | |
| *** TD-Linux <TD-Linux!~Thomas@user/td-linux> has joined #bzflag | 03:20 | |
| Juest | im happy that i finally got this sorted out | 03:21 |
| BZNotify | bzflag: Juesto commented on issue #128 "Client crash when hitting Connect multiple times" (https://github.com/BZFlag-Dev/bzflag/issues/128#issuecomment-1703670448): addendum:... | 03:22 |
| Juest | does it really deserve the good first issue tag? | 03:22 |
| Juest | its more complicated than it looks like, i think | 03:22 |
| blast007 | heh | 03:22 |
| Juest | im sorry that i was very vague with it | 03:22 |
| blast007 | okay.. I added a check for world in joinGame() that deletes it and sets it to null if it exists, inside the 'if (joiningGame)' block, and now it barfed on World::getPlayers called from joinInternetGame2() | 03:23 |
| Juest | just now i paid better attention to what i was doing | 03:23 |
| Juest | huh | 03:23 |
| Juest | side-quest: can you get it to crash during world unpack? | 03:26 |
| Juest | maybe its the same issue altogether | 03:27 |
| Juest | i posted a paste of that | 03:27 |
| Juest | crap i didnt post the world unpack crash | 03:28 |
| Juest | nevermind i did | 03:28 |
| Juest | but its just the stacktrace | 03:28 |
| blast007 | I got a crash in WorldBuilder::unpack when joining my server running Rats Nest | 03:30 |
| Juest | okay cool, is this related to the whole issue or not? | 03:31 |
| blast007 | probably | 03:31 |
| Juest | i have my dobuts, i crashed on unpack when i joined a bzexcess server | 03:32 |
| Juest | can you check if the crash is consistent? | 03:32 |
| blast007 | oh god, a new crash in a new area... | 03:34 |
| blast007 | in ScoreboardRenderer::newSortedList | 03:34 |
| Juest | how | 03:35 |
| blast007 | "Unhandled exception at 0x75BDD8C2 in bzflag.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0019C99C." | 03:35 |
| blast007 | I hit connect twice or so, then let it connect, then hit esc, enter, enter to rejoin | 03:35 |
| blast007 | let it fully connect* | 03:35 |
| Juest | interesting | 03:35 |
| Juest | try drmemory? | 03:36 |
| Juest | which isnt running for me on windows 7 | 03:36 |
| Juest | i downloaded the portable version | 03:36 |
| blast007 | I'm gonna have to resume this another day | 03:37 |
| Juest | no problem | 03:38 |
| Juest | thank you for looking into it | 03:38 |
| Juest | and getting somewhere | 03:38 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 03:52 | |
| *** blast007 <blast007!~blast@user/blast007> has quit IRC (Server closed connection) | 05:20 | |
| *** blast007 <blast007!~blast@user/blast007> has joined #bzflag | 05:20 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 08:01 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 08:04 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 08:04 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 246 seconds) | 08:06 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 08:08 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 246 seconds) | 08:12 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 08:15 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 246 seconds) | 08:19 | |
| *** FastLizard4 is back | 08:53 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 09:00 | |
| *** FastLizard4 is now away: AWAY from keyboard | 09:01 | |
| *** FastLizard4 is back | 09:37 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 09:57 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 248 seconds) | 10:00 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 245 seconds) | 10:07 | |
| *** FastLizard4 is now away: AWAY from keyboard | 10:10 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 10:39 | |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 12:58 | |
| *** yuitimothy is back | 12:58 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 13:39 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 13:39 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 13:43 | |
| *** Juest <Juest!~Juest@user/Juest> has quit IRC (Quit: Client closed) | 16:02 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 16:46 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 16:49 | |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 16:55 | |
| *** yuitimothy is back | 16:56 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 16:58 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 245 seconds) | 17:01 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 17:03 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 244 seconds) | 17:07 | |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 17:17 | |
| *** yuitimothy is back | 17:17 | |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 18:14 | |
| *** yuitimothy is back | 18:14 | |
| *** Optic_Delusion <Optic_Delusion!~Optic_Del@2600:4041:19d:2d00:208b:3997:7508:94db> has quit IRC (Ping timeout: 248 seconds) | 18:27 | |
| *** Optic_Delusion <Optic_Delusion!~Optic_Del@2600:4041:19d:2d00:3806:62b1:6a53:7d7f> has joined #bzflag | 18:31 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 19:03 | |
| *** Juest <Juest!~Juest@user/Juest> has joined #bzflag | 20:01 | |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 20:12 | |
| *** yuitimothy is back | 20:12 | |
| tupone | any reason why we use -std=gnu++11 and not -std=c++11 ? to use the last we need to pass [noext] to AX_CXX_COMPILE_STDCXX_11 | 20:19 |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 20:28 | |
| *** yuitimothy is back | 20:28 | |
| Agatha | -std=c++20 (: | 20:35 |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 20:43 | |
| Juest | hm? | 20:55 |
| blast007 | tupone: probably no reason | 20:56 |
| Juest | making dynamically colored tank textures would be easy, right? | 20:57 |
| Juest | didn't bz used to have dynamic colors or it was just one tank color? | 20:57 |
| Juest | hey blast007, bothered to look at the issue with drawinfo? | 20:58 |
| Juest | didnt mean to sound condescending or something like that | 21:00 |
| blast007 | Juest: nah, not yet. I'm working this weekend to get a bunch of stuff ready for this next week. | 21:02 |
| blast007 | the map format does have a dynamic colors feature so objects can cycle colors | 21:03 |
| *** yuitimothy is back | 21:09 | |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 21:31 | |
| *** yuitimothy is back | 21:31 | |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 21:37 | |
| *** yuitimothy is back | 21:37 | |
| Juest | nice | 23:00 |
| Juest | can that be easily ported to tanks? | 23:00 |
| blast007 | for what purpose? | 23:01 |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 23:03 | |
| *** yuitimothy is back | 23:03 | |
| Juest | dynamic coloring | 23:05 |
| Juest | im looking at issue 12 on the github | 23:05 |
| Juest | dynamically colored textures | 23:06 |
| Juest | it would need code to support the uncolored textures | 23:06 |
| blast007 | that's an entirely different thing | 23:06 |
| blast007 | dynamic colors in maps is for animating colors | 23:06 |
| Juest | got it | 23:06 |
| blast007 | not just applying a static tint to a texture | 23:06 |
| blast007 | so, one example, is that you could have functional stoplights with dynamic colors | 23:07 |
| blast007 | or a pulsing orb | 23:07 |
| Juest | imagine a disco bzflag map :D | 23:07 |
| blast007 | or blinking lights the top of radio towers (such as in the Metropolis map) | 23:07 |
| Juest | that's cool | 23:08 |
| blast007 | and the animation is time based and you can set delay offsets to sync up different objects patterns | 23:08 |
| Juest | is it possible to have like a realtime colored screen in a map with this? | 23:09 |
| blast007 | screen meaning what? | 23:09 |
| Juest | a billboard for example | 23:09 |
| blast007 | I don't know how well it would perform with a LOT of those :) | 23:10 |
| Juest | i'd imagine it would tank the fps | 23:10 |
| blast007 | but in theory, sure, you could probalby have a full motion video with dynamic color applied to individual "pixels" | 23:10 |
| Juest | what's the recommended max fps for bzflag before things go haywire? | 23:11 |
| blast007 | about 200 FPS | 23:11 |
| blast007 | I tend to limit to 180 | 23:11 |
| blast007 | much beyond that and you start to bounce off walls | 23:11 |
| Juest | client issue? | 23:14 |
| Juest | why does the server allow this? | 23:14 |
| blast007 | the server doesn't have anything to do with client-side FPS | 23:14 |
| blast007 | the server also isn't authoritative, so it doesn't run physics or enforce player positions/movement | 23:15 |
| blast007 | it only enforces some limits (speed, out of bounds positions, sudden jumps in position, at least relative to flag grabs/captures) | 23:15 |
| Juest | the bouncing would count as sudden jumps in position? | 23:17 |
| blast007 | no | 23:45 |
| blast007 | sudden jumps like reporting that you captured a flag on a base halfway across the map | 23:45 |
| Juest | oh i see | 23:46 |
| Juest | basically cheating actions | 23:46 |
| blast007 | yeah | 23:46 |
| blast007 | obvious stuff | 23:46 |
| Juest | can this get disabled for testing in bzfs? | 23:46 |
| blast007 | can what get disabled? | 23:46 |
| Juest | preferably in the config | 23:46 |
| Juest | the server enforcements | 23:47 |
| blast007 | what would you be testing? | 23:47 |
| Juest | cheats for educational/research reasons | 23:47 |
| Juest | or hacks whatever | 23:47 |
| blast007 | there are some BZDB settings for disabling some of the checks | 23:47 |
| Juest | how are the bzdb settings stored on disk? | 23:48 |
| blast007 | https://www.bzflag.org/documentation/map-design/bzdb/#server-administration | 23:48 |
| blast007 | they aren't | 23:48 |
| Juest | they need to be executed from a file? | 23:48 |
| Juest | if one wants custom bzdb variables to persist | 23:48 |
| blast007 | it's the -set option, either on the command line or in a config file | 23:49 |
| blast007 | bzfs command line options | 23:50 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!