| 00:09.05 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 00:21.44 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:21.44 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:21.44 | *** mode/#bzflag [+v infobot] by ChanServ |
| 02:28.32 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-nxexlpgfdzlkwosp) |
| 03:10.08 | Zehra | This is probably going to sound really stupid. |
| 03:11.20 | Zehra | I'm using the flag grab event in a plug-in and trying to set a kill right after it. |
| 03:12.08 | Zehra | Everything is in the event section of the plug-in, and it's ultra simple, so I can't figure out why it isn't working. |
| 03:12.29 | JeffM | what are you calling to do the kill? |
| 03:13.11 | Zehra | The flag grab event, so when a specific flag is grabbed, it calls the kill event. |
| 03:13.20 | JeffM | you don't call kill events |
| 03:13.29 | JeffM | you don't call events at all, bzfs calls events |
| 03:13.36 | JeffM | you send messages |
| 03:13.46 | Zehra | I mean function. :facepalm: |
| 03:14.00 | JeffM | in the flag grab event handler, what are you doing? calling the kill api function? or your kill handler function? |
| 03:14.17 | Zehra | bz_killPlayer(flagData->playerID, 0, BZ_SERVER, "SW"); |
| 03:14.42 | JeffM | the event may be in the middle of processing the grab message, so it may not send out new messages |
| 03:14.43 | Zehra | Right before it is this: if (flagData->flagType == "SR") |
| 03:14.55 | Zehra | oh, okay |
| 03:15.03 | JeffM | is the kill message getting to the target? |
| 03:15.39 | Zehra | It did, for some reason, when I did this: if (flagData->flagType == "GM" || "ST") |
| 03:16.07 | Zehra | But it killed any player which touched a flag, even if it wasn't the one specified. :/ |
| 03:16.11 | JeffM | there is only a single network message buffer that is available at a time, so if the event is in the process of building a message you can't send another one. |
| 03:16.40 | JeffM | let me look at that event |
| 03:17.12 | allejo | a string by itself as a boolean is "truthy" |
| 03:17.32 | allejo | if (flagData->flagType == "GM" || flagData->flagType == "ST") |
| 03:18.05 | JeffM | yeah that just wont' work :) |
| 03:18.17 | JeffM | it can't read your mind :) |
| 03:19.08 | JeffM | some grabs send messages, and that's what I fear is happening |
| 03:19.42 | Zehra | https://pastebin.com/XwXJBUSL |
| 03:20.21 | Zehra | I'm not sure if I'm understanding this correctly, like is my plug-in sending the death message too quickly? |
| 03:20.24 | JeffM | if (eventData->eventType) WTF??? |
| 03:20.33 | JeffM | no it's not too qickly |
| 03:21.38 | JeffM | first you want an == bz_eFlagGrabbedEvent in that event type check |
| 03:21.48 | JeffM | just checking the event type will make sure it's not the nullevent |
| 03:21.52 | JeffM | and it's never the null event |
| 03:22.28 | JeffM | yes, that event is called while the system is building up a message |
| 03:22.36 | JeffM | you can't send other messages in the body of that event |
| 03:22.59 | JeffM | it'll blow out the direct messsage buffer that there is only one of. |
| 03:23.14 | JeffM | you'll need to set a flag, and send it during the idle event |
| 03:23.39 | JeffM | though I could fix it in BZFS right now |
| 03:23.50 | JeffM | the event is just notification and can't change anything |
| 03:24.17 | allejo | i think you may be getting to something that'll go over his head |
| 03:24.31 | JeffM | hence why I offered to fix it ;) |
| 03:24.46 | JeffM | buhhh now I have to make a branch |
| 03:24.53 | allejo | he's in the correct direction. a flag grab event has already been fired. if he does a kill, it'll then trigger a flag drop and then a player die event |
| 03:25.20 | JeffM | yeah it's just the buffer issue. |
| 03:25.22 | allejo | so long as he has some boolean in the plugin to track who was killed by the plugin, it can be handled in the death event |
| 03:25.34 | JeffM | he can't trigger the death, that's the problem |
| 03:25.43 | JeffM | it hasn't actualy SENT the grab event yet |
| 03:25.48 | JeffM | it's in the middle of packing it |
| 03:25.59 | JeffM | if he sends the death, it overwrites the buffer the pack was using. |
| 03:27.26 | allejo | zehra, is the pastebin the code you're testing that isn't working? |
| 03:27.39 | allejo | or did you make changes? |
| 03:28.32 | JeffM | I don't feel like syncing my branch |
| 03:28.40 | JeffM | can you just commit a fix directly? |
| 03:29.40 | JeffM | bzfs.cxx: 3467 |
| 03:29.54 | Zehra | allejo, it compiled, but it didn't work. :/ |
| 03:30.00 | JeffM | move broadcastMessage(MsgGrabFlag, (char*)buf - (char*)bufStart, bufStart); |
| 03:30.00 | JeffM | <PROTECTED> |
| 03:30.01 | Zehra | I'm making a few changes to it now. |
| 03:30.08 | JeffM | compiling doesn't mean much |
| 03:30.44 | JeffM | compiling just means you have the syntax in a compileable manner, doesn't mean it does what you want :) |
| 03:30.56 | JeffM | Zehra: the workaround for your issue is somewhat signifigiant |
| 03:31.03 | allejo | the flag grab and player die events would be happening in entirely different scopes, no? so what's being overwritten? |
| 03:33.25 | allejo | I thnk the problem in that is that the documentation is wrong. flagData->flagType is a const char*, not an api string |
| 03:33.50 | JeffM | there is only one global buffer |
| 03:33.52 | JeffM | SAME SCOPE |
| 03:34.14 | JeffM | getDirectMessageBuffer doesn't allocate a buffer |
| 03:34.25 | JeffM | static char sMsgBuf[MaxPacketLen]; |
| 03:34.34 | JeffM | so the msgGrab has packed that up. |
| 03:34.42 | JeffM | but not copied it to the network buffers yet |
| 03:34.57 | JeffM | you try to SendMsgKilled, it's going to pack into the same buffer |
| 03:35.28 | JeffM | bzfs.cxx is mostly C with a button of globals |
| 03:35.55 | allejo | Zehra: change your if () to be this intead, if (strcmp(flagData->flagType, "SR") == 0) |
| 03:36.56 | Zehra | oh, okay. |
| 03:37.21 | JeffM | I still don't think he's going to send the grab message correctly |
| 03:37.29 | JeffM | it'll probalby send double kill |
| 03:37.38 | JeffM | are you always killing the grabber? |
| 03:38.33 | Zehra | It worked somewhat in one revision, except it just killed for every flag grab, which wasn't what I wanted. |
| 03:38.35 | JeffM | so nobody else actualy sees the grab, and you send a malformed message :) |
| 03:38.52 | JeffM | allejo: please fix the bug |
| 03:39.17 | Zehra | Maybe I could delay the kill message? |
| 03:39.35 | JeffM | you have to fix your test like he says |
| 03:39.51 | JeffM | you can't compare a char* to a constant and ever have it work |
| 03:40.02 | JeffM | but I think you'll also have a message problem |
| 03:40.13 | JeffM | but because of what you are doing the message problem may not show up |
| 03:40.28 | JeffM | c doesn't really have "strings" |
| 03:40.38 | JeffM | so anything with == has to be on objects, not char *s |
| 03:44.54 | allejo | Zehra: https://paste.ee/p/qbod9 |
| 03:45.11 | allejo | JeffM: I see what you mean about the events being overwritten |
| 03:46.17 | JeffM | this is how I'd write it. fixes both issues. https://www.irccloud.com/pastebin/VKD2zsGe/ |
| 03:47.17 | JeffM | allejo: not the events the one singluar buffer because bzfs is stingy on memory |
| 03:47.38 | allejo | right right, i mispoke |
| 03:47.40 | JeffM | it really should pool |
| 03:47.54 | JeffM | now the kill message will probalby make it LOOK like it works |
| 03:48.15 | JeffM | but if anyone tries to send any other messages, they totaly will not work, and probalby be mallformed. |
| 03:49.38 | Zehra | It works, although flag grabs don't appear. |
| 03:49.46 | JeffM | yeah that's the bug |
| 03:50.03 | JeffM | it'll also send a message with a bad lenght |
| 03:50.20 | JeffM | the grab is sent as long as a grab is, but has the data for a kill |
| 03:50.35 | allejo | should flag history be modified after the event call or before the flag grab message is broadcasted? |
| 03:50.50 | JeffM | I'd do it before, so the event can see the grab in the history |
| 03:51.13 | JeffM | it's a notification event, so all state changes should be done by the time the event is called, so they can be queried if needed. |
| 03:51.22 | allejo | makes sense |
| 03:51.45 | JeffM | the event handler should not have to guess about the history, it should be complete |
| 03:52.52 | JeffM | Zehra: to get caps to work, you need to send the kills outside of the event handler, so you would need to use the tick event. |
| 03:53.04 | JeffM | or fix bzfs |
| 03:54.41 | Zehra | ah okay. |
| 03:54.57 | Zehra | I'll probably end up using tick events. |
| 03:56.46 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-hdjyjuhhdftgppbs) |
| 03:56.46 | BZnotify | [13bzflag] 15allejo pushed 1 new commit to 062.4: 02https://git.io/vpwu0 |
| 03:56.46 | BZnotify | 13bzflag/062.4 1441a4c6d 15Vladimir Jimenez: Broadcast MsgFlagGrab before API event is called... |
| 03:56.46 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-hdjyjuhhdftgppbs) |
| 03:57.44 | Zehra | yay |
| 03:58.00 | Zehra | ty JeffM and allejo |
| 04:05.53 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-faoasxwvzbthgaqb) |
| 04:05.53 | BZnotify | [13bzflag.org] 15allejo pushed 1 new commit to 06master: 02https://git.io/vpwui |
| 04:05.53 | BZnotify | 13bzflag.org/06master 14b7608ca 15Vladimir Jimenez: Fix incorrect datatype in flagGrab event |
| 04:05.53 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-faoasxwvzbthgaqb) |
| 04:22.26 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-ztyhwnfcslagbqvl) |
| 04:22.27 | BZnotify | [13bzflag] 15allejo pushed 1 new commit to 062.4: 02https://git.io/vpwup |
| 04:22.27 | BZnotify | 13bzflag/062.4 14826b089 15Vladimir Jimenez: Version bump to 2.4.15 |
| 04:22.27 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-ztyhwnfcslagbqvl) |
| 09:35.34 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 12:10.22 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-rbbrkdqltjdyzkkz) |
| 12:53.21 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-vqimjiogtsxxxmza) |
| 12:53.21 | BZnotify | [13bzflag] 15atupone pushed 1 new commit to 062.4: 02https://git.io/vpwPY |
| 12:53.21 | BZnotify | 13bzflag/062.4 14ca1dd6a 15Alfredo Tupone: use pkg-config to get the ncurses libraries |
| 12:53.21 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-vqimjiogtsxxxmza) |
| 16:52.34 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-sqrpagiywzzizhts) |
| 17:28.29 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-dmzokvxcgrhpshxr) |
| 17:28.30 | BZnotify | [13bzflag] 15atupone pushed 1 new commit to 062.4: 02https://git.io/vpw5C |
| 17:28.30 | BZnotify | 13bzflag/062.4 14454852c 15Alfredo Tupone: Simplify code that get mouse position |
| 17:28.30 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-dmzokvxcgrhpshxr) |
| 17:37.49 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 18:00.37 | macsforme | blast007: for the cross-platform dependencies project, do you have ideas for what the output directory structure should look like? |
| 18:01.23 | macsforme | I know we were talking about one pre-built package for each platform, rather than combining them together |
| 18:04.11 | macsforme | at the same time, it would be helpful to set up the directory structure so that dependencies for multiple platform/architectures can co-exist in subdirectories if needed |
| 18:07.31 | macsforme | in case, for example, we eventually support building on mobile and the developer needs to switch between the desktop and mobile APIs, or we need to switch between Intel and ARM targets |
| 18:25.13 | blast007 | currently I output to folders named output-{target}-{arch}, so, for instance, output-debug-x86 or output-release-x64 |
| 18:25.26 | blast007 | we could easily add a platform in that name |
| 18:26.01 | blast007 | which for Windows I guess could even be the compiler short name, like VC15 |
| 18:27.22 | blast007 | I also create a top level licenses directory along side those |
| 18:29.43 | blast007 | within the output directories I have bin/ for the DLLs, include/ for the headers (structured like they would be when normally installed, so SDL2 and curl are in a subdirectory), and lib/ containing the .lib, .exp and (for debug) the .pdb (debugging symbols) |
| 18:36.31 | macsforme | how would we do the root directory for the dependencies? we wanted it to be automatically found inside the root of the bzflag repo directory, but also elsewhere via the BZ_DEPS environmental variable on Windows, right? |
| 18:40.20 | macsforme | so if I'm imagining it correctly, if someone downloads the dependencies package, they would need BZ_DEPS to point to the parent directory of the package, or else make them copy the contents of the dependencies package into the bzflag repo directory root, right? |
| 18:45.31 | macsforme | that wasn't very clear, but for example, if the path was $BZ_DEPS\output-release-x86, that would work fine for people who set $BZ_DEPS, but that wouldn't work for someone who just drops the dependencies directory into the root of the bzflag directory and leaves $BZ_DEPS unset |
| 18:52.26 | blast007 | I think we could stop with the BZ_DEPS and just use a 'dependencies' directory that you drops the output/licenses directory into |
| 19:00.50 | macsforme | okay, then the library and header paths in BZ's project files will just be relative to the project, right? |
| 19:11.45 | blast007 | yup |
| 19:12.22 | blast007 | I think we'd just swap $(BZ_DEPS) with ..\..\dependencies |
| 19:14.11 | macsforme | okay |
| 19:14.30 | macsforme | what are your thoughts on breaking the output directory name into subdirectories? e.g. output/macOS/release/x86_64 versus output-macOS-release-x86_64 |
| 19:15.42 | macsforme | maybe having it all in one directory name would make it clearer which platforms/architectures you have dependencies available for |
| 19:19.29 | blast007 | I don't really see that improving anything |
| 19:20.01 | blast007 | I would think we'd still have specific packages of dependencies for whatever platform you're building on |
| 19:20.11 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-zumjzpnsjexzuqnw) |
| 19:20.11 | BZnotify | [13bzflag] 15atupone pushed 1 new commit to 062.4: 02https://git.io/vpwAn |
| 19:20.11 | BZnotify | 13bzflag/062.4 141fa9934 15Alfredo Tupone: on SDL2 respect the requested window minSize |
| 19:20.11 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-zumjzpnsjexzuqnw) |
| 19:21.30 | macsforme | yeah, I tend to agree... as long as it is possible to manually combine them in case you need to switch between two or more |
| 19:23.44 | blast007 | output-macOS-release-x86_64 vs output-iOS-release-aarch64 |
| 19:26.02 | macsforme | yeah |
| 19:55.06 | macsforme | can we settle on one consistent scheme for naming architectures? for example, clang uses i386, x86_64, armv7, and arm64 as the architectures I might see us using |
| 19:57.19 | macsforme | does Visual Studio use something different? maybe it doesn't matter as long as each platform matches what its compiler uses |
| 19:59.27 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-dohrkdsnybwtplas) |
| 19:59.27 | BZnotify | [13bzflag] 15atupone pushed 1 new commit to 062.4: 02https://git.io/vpwxF |
| 19:59.27 | BZnotify | 13bzflag/062.4 140cceded 15Alfredo Tupone: drop extra resize calls. The windows is created only once. |
| 19:59.27 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-dohrkdsnybwtplas) |
| 20:13.52 | blast007 | I *think* Windows generally uses x86 and x64 |
| 20:14.28 | blast007 | i386 is mostly a linux thing, and somewhat of a legacy naming scheme |
| 20:14.56 | blast007 | I think they generally mean i686 when they say i386 |
| 20:22.32 | blast007 | Debian uses these codenames (i386, amd64, arm64, etc): https://www.debian.org/ports/ |
| 20:39.07 | JeffM | x86 and x64 are the new windows standard targets |
| 20:39.20 | JeffM | it used to be win32 and x64 |
| 20:39.42 | JeffM | but new projects in 2015+ all do x86 |
| 20:40.16 | JeffM | if you wanted to just do x64 builds of windows it'd be fine. You've ditched XP, so it's the next logical step |
| 20:41.48 | blast007 | there are still systems sold with 32-bit Windows |
| 20:42.19 | JeffM | seriously? |
| 20:42.20 | blast007 | some of the newish atom systems technically have a 64-bit processor, but only a 32-bit UEFI |
| 20:42.22 | JeffM | atoms? |
| 20:42.26 | JeffM | ahh |
| 20:42.42 | JeffM | and you want them to be able to play 3d video games |
| 20:42.51 | blast007 | at least the one I have. dunno if the current ones have changed that. |
| 20:43.06 | blast007 | I'm probably a generation or two behind on atoms |
| 20:43.28 | blast007 | I don't see a reason to ditch 32-bit |
| 20:43.53 | blast007 | at least on Windows |
| 20:43.56 | JeffM | wait untill MS decides to pull the plug |
| 20:44.35 | blast007 | I don't forsee that for, at least not for quite a while |
| 20:44.52 | blast007 | s/ for,/,/ |
| 20:45.04 | JeffM | it'll start with some release of windows 10, that will be 64 bit only or something like that, so there will be warning |
| 20:45.36 | blast007 | *shrugs* |
| 20:47.22 | blast007 | in any case, it's probably better we don't force a standard naming convention in. use whatever makes the most sense on the platform you're building on. |
| 20:47.31 | blast007 | they are going to have differing standards |
| 20:49.19 | macsforme | sounds good |
| 20:50.38 | blast007 | in Visual Studio, for instance, they have macros that would autofull stuff like Win32 or x86 (for 32-bit) and x64 for 64-bit |
| 20:51.26 | blast007 | the one we currently use, $(Platform) will use Win32 or x64, whereas $(PlatformTarget) would use x86 and x64 |
| 20:51.51 | blast007 | $(Platform) might pick the text we have set for the platform name |
| 21:01.36 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |
| 23:23.14 | *** part/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 23:52.31 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 23:52.31 | *** mode/#bzflag [+v BulletCatcher] by ChanServ |