*** infobot <infobot!ibot@c-174-52-60-165.hsd1.ut.comcast.net> has quit IRC (Remote host closed the connection) | 00:19 | |
*** infobot <infobot!ibot@c-174-52-60-165.hsd1.ut.comcast.net> has joined #bzflag | 00:20 | |
*** ChanServ sets mode: +v infobot | 00:20 | |
*** Zehra <Zehra!~Zehra@unaffiliated/zehra> has joined #bzflag | 00:40 | |
Zehra | What would be the proper procedure for adding a single boolean variable which would only need to be accessed in two locations within the client? (Both files are non-headers as well and DEVINFO does not seem to cover this.) | 01:16 |
---|---|---|
Zehra | This would be related to a minor bug fix within the client I am currently working on. | 01:17 |
blast007 | that's far too vague of a question | 01:18 |
Zehra | Alright. "playing.cxx" and "ScoreboardRenderer.cxx" are the files being used. Information on a "state" I wish to track would be within "playing.cxx", but I would need to be aware of that "state" in "ScoreboardRenderer.cxx", this would be a single boolean variable, but this does not seem to qualify enough for it to be needed as a global variable, so my question is what should be done to follow the coding conventions, as it seems it is not covered | 01:25 |
Zehra | sufficiently within DEVINFO? | 01:25 |
blast007 | what state? | 01:27 |
blast007 | and how many times per frame would the current value of the state need to be read? | 01:28 |
Zehra | I would add a state to see if a client has joined and remained connected to a server or not. | 01:29 |
Zehra | As much as the input of the "huntKeyEvent" is used. | 01:30 |
blast007 | is this to fix the hunt key when not joined to a server? | 01:30 |
Zehra | Yes. | 01:30 |
blast007 | then I'm unclear what the scoreboard *renderer* has to do with that | 01:30 |
allejo | doesn't the client already have that information somewhere? | 01:31 |
Zehra | Line 282: // invoked by clientCommands.cxx when '7' or 'U' is pressed | 01:31 |
Zehra | allejo: It does to some degree, but not in an ideal manner as two boolean variables would need to be tracked. | 01:33 |
allejo | the client should already know if its on a server. how does it decide not to render a scoreboard e.g. | 01:33 |
allejo | the message key knows to display a "you can only send messages while on a server" message | 01:33 |
blast007 | yeah, look for "use send only when connected" in clientCommands.cxx | 01:34 |
blast007 | the solution is to just not call huntKeyEvent if you're not connected | 01:35 |
allejo | ^ | 01:35 |
Zehra | Will do. Thanks for the insights. | 01:36 |
*** Zehra <Zehra!~Zehra@unaffiliated/zehra> has quit IRC (Quit: Gone for now.) | 02:06 | |
*** Sgeo_ <Sgeo_!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 07:34 | |
*** Sgeo__ <Sgeo__!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 07:37 | |
*** DTRemenak <DTRemenak!~DTRemenak@about/essy/CrazyCoder/DTRemenak> has quit IRC (Quit: ChatZilla 0.9.93 [SeaMonkey 2.53/20180924130006]) | 08:33 | |
*** infobot <infobot!ibot@c-174-52-60-165.hsd1.ut.comcast.net> has quit IRC (Ping timeout: 272 seconds) | 08:43 | |
tupone | macsforme: Model.h and similar | 10:29 |
*** spldart <spldart!~james@bzflag/contributor/spldart> has quit IRC (Ping timeout: 264 seconds) | 10:51 | |
*** Sgeo__ <Sgeo__!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 15:54 | |
*** Sgeo_ <Sgeo_!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 15:57 | |
*** Zehra <Zehra!~Zehra@unaffiliated/zehra> has joined #bzflag | 16:40 | |
BZNotify | bzflag: Zehra opened pull request #210 "Fixes hunt usage when not connected to server" (https://git.io/fj9BZ) | 16:42 |
blast007 | allejo: checking after is at least consistent with the other commands, iirc | 16:50 |
allejo | oh is it? | 16:51 |
blast007 | yup, see cmdJump, for instance | 16:52 |
allejo | oh you're right | 16:53 |
*** Sgeo_ <Sgeo_!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 17:25 | |
*** Sgeo__ <Sgeo__!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 17:29 | |
*** DTRemenak <DTRemenak!~DTRemenak@2605:e000:141f:c002:e966:a4bb:97ca:708c> has joined #bzflag | 18:11 | |
*** DTRemenak <DTRemenak!~DTRemenak@2605:e000:141f:c002:e966:a4bb:97ca:708c> has quit IRC (Changing host) | 18:11 | |
*** DTRemenak <DTRemenak!~DTRemenak@about/essy/CrazyCoder/DTRemenak> has joined #bzflag | 18:11 | |
*** ChanServ sets mode: +v DTRemenak | 18:11 | |
*** Sgeo_ <Sgeo_!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 21:04 | |
*** spldart <spldart!~james@2601:2c5:c600:2365::494a> has joined #bzflag | 22:19 | |
*** spldart <spldart!~james@2601:2c5:c600:2365::494a> has quit IRC (Changing host) | 22:19 | |
*** spldart <spldart!~james@bzflag/contributor/spldart> has joined #bzflag | 22:19 | |
*** ChanServ sets mode: +v spldart | 22:19 | |
*** Sgeo <Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 22:23 | |
macsforme | tupone: what about it specifically? | 23:21 |
macsforme | we need to move ahead toward releasing the next major version | 23:22 |
macsforme | I already brought up a few weeks ago that we should evaluate JeffM's unfinished projects to see if they should be set aside for now... so if your work has conflicts with any of it, that can be part of the discussion | 23:24 |
macsforme | but if there is no straightforward way to port your projects to the master branch, then I see no compelling reason to merge them at all | 23:29 |
macsforme | I understand why you wanted to do your work in 2.4 (or I think I do)... it's a lot easier to develop graphics code on a branch where there are active servers and players... I get that | 23:32 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!