| 02:05.07 | *** join/#bzflag the_map (~the_map@unaffiliated/the-map/x-1795707) |
| 09:31.07 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 09:32.26 | *** join/#bzflag brlcad (~sean@104.225.5.10) |
| 10:26.25 | *** join/#bzflag FieldSobers (~FieldSobe@unaffiliated/user49) |
| 13:40.30 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 16:25.34 | *** join/#bzflag Flash (~flash@2601:280:c200:4e39:9d21:80ff:d552:8ae3) |
| 16:25.34 | *** mode/#bzflag [+v Flash] by ChanServ |
| 18:14.35 | *** join/#bzflag alfa1 (~alfa1@181.95.189.57) |
| 18:16.20 | *** join/#bzflag alfa1 (~alfa1@181.95.189.57) |
| 18:26.02 | alfa1 | blast007: I don't understand. You said "you moved the window with code and it got fullscreen" (instantaneously, I guess) but later "you moved it with code and you did other things with it" then it didn't get fullscreen instantaneously. That is contradictory. |
| 18:27.08 | alfa1 | error: without quotation marks |
| 18:45.55 | blast007 | alfa1: in summary, it only goes fullscreen on the desired monitor if the window is either created on the desired monitor from the start, or if I manually drag the window to the disired monitor before telling it to go fullscreen |
| 18:46.43 | blast007 | if I create the window on monitor 1 and tell it to go fullscreen on monitor 2, it changes the resolution on monitor 2 but goes fullscreen on monitor 1 |
| 18:47.32 | blast007 | if I create the window on monitor 1, manually drag the window over to monitor 2, and then tell it to go fullscreen on monitor 2, it correctly changes the resolution of monitor 2 and goes fullscreen on monitor 2 |
| 18:57.59 | tupone | if (updated->lastState.status == eTeleporting && updated->lastState.status != eTeleporting) what does this means ?? |
| 18:58.44 | Flash | engage the infinite improbability engine? |
| 18:59.16 | Flash | tea and no tea? |
| 18:59.47 | tupone | I also see some like cdr > 0 || cdr < 32 |
| 18:59.48 | the_map | to be, and not to be: that is the condition |
| 19:00.17 | tupone | but the last I understand || -> && |
| 19:02.48 | alfa1 | analizing your second line, how can you have 2 windows? "it changes the resolution on monitor 2 but goes fullscreen on monitor 1"? |
| 19:06.06 | blast007 | tupone: I imagine the check is *supposed* to be where the previous state was *not* teleporting and the current state *is* teleporting |
| 19:06.29 | blast007 | alfa1: in this case, I'm talking about a single window but two monitors |
| 19:07.11 | blast007 | alfa1: it drops the second monitor down to the requested resolution, but actually shows the OpenGL window fullscreen on the first monitor |
| 19:08.55 | blast007 | tupone: as for the cidr one.. I'll have to review what that is supposed to do.. but yeah, that's wrong too |
| 19:09.34 | alfa1 | then you moved first the window to the second monitor before set it to fullscreen? and it set the resolution there but got frozen somewhat and returned to the first monitor and got fullscreen there? |
| 19:10.35 | tupone | blast007: but I don't know where is the old and where is the new :( |
| 19:11.29 | *** join/#bzflag katelynn342[m] (katelynn34@gateway/shell/matrix.org/x-dtomeyzayfgiwkcu) |
| 19:11.40 | blast007 | tupone: yeah, I'll have to peek at that when I have more than an SSH terminal |
| 19:13.48 | blast007 | okay, I think the cidr one is supposed to be && instead of ||, thought might also want it to be cidr >= 0 |
| 19:14.40 | tupone | cidr == 0 may means block all |
| 19:14.52 | blast007 | it would |
| 19:15.22 | tupone | I will make a PR for clang 10, without the old/new teleporting state |
| 19:16.34 | blast007 | I honestly don't even know if anyone uses that ServerSidePlayer code |
| 19:17.23 | alfa1 | does it annoy? it was/is a JeffM's big project ("big" as in it would take lot of time) |
| 19:17.25 | blast007 | 2.4 didn't have anywhere near complete SSP support. the most I'm aware it's being used for is chat bots or running slash commands that lack an API |
| 19:19.09 | alfa1 | AFAIK it worked just to join a SSP for now |
| 19:19.21 | alfa1 | as observer I think |
| 19:20.36 | alfa1 | he wanted to make people be able to make bots code by plugins |
| 19:20.42 | blast007 | alfa1: yeah, for use a chat bot or for running slash commands |
| 19:21.59 | alfa1 | and then quit "solo" and "autopilot" codes I think (maybe making them available as plugins again; which would help me keeping my bots project) |
| 19:22.12 | alfa1 | keep* |
| 19:22.24 | blast007 | alfa1: yeah, the goal with SSPs was always to make server-side bots |
| 19:22.51 | blast007 | that's just a lot of work because all of the code that has the "how to be a player" behaviour is in the client, not the server |
| 19:23.56 | alfa1 | but if it doesn't annoy, it should be kept in the code, for future work (AFAIK he keeps developing) |
| 19:24.12 | alfa1 | (or other person) |
| 19:25.42 | alfa1 | blast007: I worte you about the window problem again |
| 19:25.48 | alfa1 | wrote |
| 19:26.11 | blast007 | I'm not saying to remove it. Just, that it might not be be something to worry about fixing it right now. |
| 19:26.46 | alfa1 | ah, I see |
| 19:27.27 | blast007 | if it differs in 2.5, I wouldn't fix it in 2.4, for instance |
| 19:29.30 | blast007 | to get proper SSPs, we'd need to at minimum copy a bunch of code from the client. Ideally we'd create a library that both the client and server shared that controls the game simulation. |
| 19:29.46 | blast007 | then the server could do other useful stuff as well, like some better cheat detection |
| 19:30.48 | BZNotify | bzflag: 03atupone 03opened pull request #256 "clang-10 porting" (06https://git.io/JJtP6) |
| 19:31.08 | BZNotify | bzflag: 03atupone review_requested pull request #256 "clang-10 porting" (06https://git.io/JJtP6) |
| 19:31.09 | BZNotify | bzflag: 03atupone review_requested pull request #256 |
| 19:31.10 | BZNotify | bzflag: 03atupone review_requested pull request #256 |
| 19:33.07 | alfa1 | hmm I'm not an expert but I don't like a lot prefering "smart server" over "silly server" idea; as mostly a player, I like the nowadays approach |
| 19:33.50 | blast007 | alfa1: why? |
| 19:34.54 | alfa1 | basically, because the client knows better how to behave; how can I exain it more?... |
| 19:35.02 | alfa1 | explain* |
| 19:35.34 | alfa1 | all the maths, without theserver-client lag in middle, ... |
| 19:35.54 | alfa1 | maybe te 3D stuff together, ... |
| 19:36.03 | blast007 | nah, this isn't about making the clients have to wait for the server to tell them they can move |
| 19:36.14 | blast007 | both the client and server would be running the same simulation |
| 19:36.38 | blast007 | the server would have the authority, though, so if the two states diverge, the client adjusts to match the server |
| 19:37.00 | blast007 | so at most, you might see a slight correction in your client |
| 19:37.19 | blast007 | how many games work is that you send *input* states, not "I moved here" |
| 19:38.13 | alfa1 | I remember some of you and I discussed time ago somewhat about the "this project started as a LAN" and "it should be totally changed due to the WAN"; which I don't agree so much; for me a LAN could be projected as a WAN withouth major problmes; some reasons had the creator to make it this way |
| 19:38.42 | blast007 | so both the client and the server process that input and run the simulation. your client would keep a record of the unacknowleged input and/or state. if the server disagrees with what happened, the client will rewind the state and run through the steps the server gave it |
| 19:39.10 | allejo | on LAN, you can go punch someone for cheating. on WAN, you'll have a harder time doing that |
| 19:40.56 | blast007 | https://www.gafferongames.com/post/deterministic_lockstep/ |
| 19:41.31 | blast007 | Gaffer On Games is a great site for understanding how networked games can/do work |
| 19:42.43 | alfa1 | an example of a good "deterministic" game? and a good non-deterministic one? |
| 19:42.57 | alfa1 | "non-deterministic"* |
| 19:43.43 | alfa1 | hehe allejo |
| 19:46.03 | blast007 | I don't have examples of games |
| 19:47.01 | alfa1 | I will read that and try to keep the chat sometime later, ty blast007 |
| 19:51.01 | the_map | lol allejo |
| 19:56.34 | blast007 | https://youtu.be/_Z0vyOx4imI how you dealt with cheaters in the 2000's |
| 19:57.57 | CaptainRoberts[m | rollback solves a lot of problems. |
| 20:00.25 | alfa1 | very funny |
| 20:01.15 | blast007 | alfa1: :) |
| 22:15.49 | *** join/#bzflag alfa1 (~alfa1@181.95.190.80) |
| 22:22.38 | alfa1 | blast007: have you checked that SDL_SetWindowPosition really allocates the window on the desired new postion? |
| 22:22.47 | alfa1 | position* |
| 22:25.12 | blast007 | yes |
| 22:25.21 | alfa1 | if so, then add a pause (5 seconds) before setting fullscreen |
| 22:25.29 | blast007 | nah, doesn't help |
| 22:25.58 | blast007 | my demo app has a keybind to move the window to the other display. even doing that, and THEN telling it to go fullscreen doesn't help. |
| 22:26.14 | alfa1 | maybe another value needs to be set to make it equal to drag it by hand? |
| 22:27.44 | blast007 | you basically just say "something needs to happen", which.. yeah.. of course :) |
| 22:28.49 | alfa1 | I don't understand that. I meant maybe another variable needs to be changed. |
| 22:29.21 | alfa1 | but it's weird, yes; I'm reading all the text from today/yesterday |
| 22:30.45 | alfa1 | when you say the window goes fullscreen at the first display, does you mean the window dissapears from the display 2 and appears on display 1? |
| 22:35.55 | alfa1 | it has something to do with the parent display and with the dragging action; compare this with the code way to make it exactly the same. It can be also a code bug from SDL too. |
| 22:36.34 | alfa1 | (since it does change the display resolution) |
| 22:37.59 | alfa1 | yes, to me sounds like some variable still needs to be changed |
| 22:38.18 | alfa1 | (by code) |
| 22:41.30 | alfa1 | really, try to make a pause between both actions |
| 22:42.00 | alfa1 | maybe the system needs it (to modify values automatically) |
| 22:42.21 | alfa1 | try all the options |
| 22:49.39 | allejo | brute force. i like it |
| 22:49.49 | alfa1 | maybe the fullscreen method has any default value on its arguments; or you are using a wrong overloaded one |
| 22:50.50 | alfa1 | I have a tester soul :) |
| 22:54.15 | alfa1 | (as well as the moving method) |
| 22:56.19 | blast007 | alfa1: I *do* have a pause between actions. |
| 22:56.33 | blast007 | I have a key that just moves the window. |
| 22:56.42 | blast007 | So I can wait however long I want. |
| 22:56.48 | blast007 | Does. Not. Matter. |
| 22:57.54 | blast007 | and really, saying stuff like "maybe some variable still needs to be changed" says nothing. Like, of COURSE *something* needs to happen. You're just saying empty words. |
| 22:57.55 | alfa1 | ok, the keybinding way was not very clear about that |
| 22:59.07 | alfa1 | yes, I am not managing the real code, just giving general advices |
| 23:08.07 | BZNotify | bzflag: 03Ratfink commented on pull request #255 "Improved joystick support" by 03macsforme (06https://git.io/JJt7x): The ramp options in the menu aren't named quite right, since they'r... |
| 23:08.53 | allejo | oheyitsratfink |
| 23:09.01 | allejo | hiratfink |
| 23:09.17 | allejo | (i know that's github) |
| 23:21.05 | alfa1 | handling* |
| 23:27.42 | alfa1 | blast007: have you tried both SDL_WINDOW_FULLSCREEN and SDL_WINDOW_FULLSCREEN_DESKTOP flags for SDL_SetWindowFullscreen method? (even "0" to try coded windowed set?) |
| 23:28.16 | blast007 | SDL_WINDOW_FULLSCREEN_DESKTOP is for when you don't want a mode change |
| 23:28.26 | blast007 | I want a mode change, so I'm using SDL_WINDOW_FULLSCREEN |
| 23:29.01 | alfa1 | I guessed that but trying all the values can give you an idea if it's a bug in example |
| 23:30.01 | blast007 | SDL_SetWindowDisplayMode doesn't do anything unless the window mode is SDL_WINDOW_FULLSCREEN |
| 23:31.28 | blast007 | https://hg.libsdl.org/SDL/file/2eec032757ce/src/video/SDL_video.c#l1121 https://hg.libsdl.org/SDL/file/2eec032757ce/src/video/SDL_sysvideo.h#l117 |
| 23:32.20 | blast007 | though, I can't recall if it worked any better (even without the mode change) when using SDL_WINDOW_FULLSCREEN_DESKTOP |
| 23:32.44 | blast007 | I'd have to test later as there's a thunderstorm rolling through right now and I don't want to risk too many systems :) |
| 23:33.49 | alfa1 | ok |
| 23:37.53 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 23:37.54 | *** mode/#bzflag [+v spldart] by ChanServ |