| 00:00.13 | JeffM | the best way to do what you want, you can't do with the way the game is coded today |
| 00:00.27 | alfa1 | admins can change variables, it is allowed, what is wrong with it? |
| 00:00.31 | JeffM | the best way is to send a message to the client to actualy controll it, not to fake it by changing speeds. |
| 00:00.43 | JeffM | because that's not really the "right" thing to do |
| 00:00.52 | JeffM | you want to stop them playing, not just slow them to 0 |
| 00:00.57 | JeffM | a "stoped" player is an observer |
| 00:01.52 | JeffM | variable changes are supposed to be long lasting gameplay changes |
| 00:01.57 | alfa1 | I see your point; but now please answer me if that thought 1, 2, 3 is true |
| 00:01.57 | JeffM | not something you change quickly over time |
| 00:02.26 | JeffM | you can't be sure of the order of packages, so maybe it's 132 for some users |
| 00:03.11 | alfa1 | ok, but still I have reason: if I add more time betwen 1 and 2 then all will go well |
| 00:03.19 | JeffM | maybe, maybe not |
| 00:03.32 | JeffM | with packet loss it could go 1 3 |
| 00:03.37 | JeffM | or just 1 2 |
| 00:04.13 | alfa1 | can't i play with speed check disabled all the time? |
| 00:04.20 | JeffM | you should not have it |
| 00:04.37 | JeffM | it should work if you leave it off for a range around the time you start slowing down |
| 00:04.48 | JeffM | if that doesn't work, then you need to debug WHY |
| 00:04.53 | JeffM | not just guess and hack at it |
| 00:05.29 | alfa1 | "you should not have it": I should not have to play w/o speed check disabled you mean? |
| 00:05.55 | JeffM | should not have to have it disable all the time, just when you are adjusting the speed |
| 00:06.14 | alfa1 | well, but I am going to an extrem example; is this allowed? |
| 00:06.26 | JeffM | it's your server, you do what you want |
| 00:06.39 | JeffM | there are no rules for what a server can and can not do |
| 00:06.41 | alfa1 | I can check it no and see |
| 00:06.44 | alfa1 | now* |
| 00:06.55 | JeffM | only rules about what kinds of servers we allow to connect to services |
| 00:06.57 | alfa1 | I will check |
| 00:07.12 | alfa1 | ok |
| 00:11.08 | alfa1 | "variable changes are supposed to be long lasting gameplay changes": what do you mean? |
| 00:12.45 | alfa1 | making changes in a slow way one compared with each other? let's say letting 5 seconds in middle? |
| 00:12.46 | blast007 | it means they're not designed to be changed constantly |
| 00:13.06 | blast007 | using /set _tankSpeed can already cause players to get kicked for going to fast |
| 00:13.13 | blast007 | the API is no exception |
| 00:13.23 | blast007 | and some settings tend to require a rejoin to take effect |
| 00:19.25 | *** join/#bzflag infobot (~infobot@rikers.org) |
| 00:19.25 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.10 released! https://forums.bzflag.org/viewtopic.php?f=8&t=19401 |
| 00:19.32 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:19.46 | alfa1 | you told me that the sleep function was not allowed on public servers; well, related to that |
| 00:20.05 | alfa1 | (not using sleep at all anyway) |
| 00:20.19 | alfa1 | I just was following all you all were telling me |
| 00:20.24 | alfa1 | and still |
| 00:20.40 | alfa1 | and still I am |
| 00:21.49 | alfa1 | then after said that, this tests I am making is only affecting to me and the players which come to my private servers; I hope there are no problems with this. Am I right? |
| 00:21.55 | alfa1 | these tests* |
| 00:22.57 | alfa1 | (anyway if this makes people get crashed I will not be using it) |
| 00:23.10 | alfa1 | I will test with few ppl first |
| 00:23.31 | blast007 | it's pretty easy... just do the thing I said |
| 00:23.39 | alfa1 | doesn't work |
| 00:23.47 | alfa1 | want to see the code? |
| 00:23.50 | blast007 | sure |
| 00:24.12 | alfa1 | give me time, I was changing things to try my method |
| 00:35.21 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 01:35.38 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 01:57.00 | Zehra | has anyone had a plug-in load groups if they are not loaded ? |
| 01:57.23 | Zehra | such as if everyone, verified, and local.admin are the only loaded groups... |
| 01:57.52 | Zehra | than it would load 'sample.user' and 'sample.cop' |
| 01:58.14 | Zehra | since servers can't check for groups which are not loaded |
| 02:00.47 | alfa1 | was funny |
| 02:00.55 | alfa1 | oops, wrong channel |
| 02:06.20 | Zehra | mostly meant as a way to prevent certain configurations from being removed or altered |
| 02:12.31 | Zehra | might need help testing a few things once they're finished with their work |
| 02:41.50 | blast007 | Zehra: you can't |
| 02:41.59 | blast007 | you have to put all the groups you care about in your groupdb file |
| 02:45.11 | Zehra | blast007: ty |
| 02:45.50 | Zehra | was thinking of using auto group loading as a feature to have a plug-in load certain groups to grant permissions |
| 02:46.58 | blast007 | plugins don't really do groups |
| 02:47.27 | blast007 | what kind of crazy complicated system are you trying to build? |
| 02:47.38 | blast007 | it's a silly tank game, not fort knox |
| 02:49.02 | Zehra | i'm probably a little crazy |
| 02:49.42 | Zehra | since it would have been an excessive amount of automation in some ways with permissions |
| 02:50.08 | Zehra | like if user is part of this group and not part of this group, limit permissions to this |
| 02:50.39 | Zehra | if user is part of this and this group, than limit permissions, unless part of that group |
| 02:50.59 | the_map | ...why though? |
| 02:51.19 | the_map | why not just have sane groups, instead of doing logic on them? |
| 02:52.06 | Zehra | it is a matter of trust and i don't think groups handle logic |
| 02:52.28 | Zehra | also reducing risks too |
| 02:52.39 | the_map | it's a matter of trust? how? |
| 02:53.09 | Zehra | i can grant permissions to groups and to deny them afaik... |
| 02:53.36 | the_map | more specifically, how is checking for users in multiple groups relate to trust? |
| 02:54.01 | the_map | if you don't trust a user, why have them in a permission-granting group at all? |
| 02:54.19 | Zehra | it's meant to limit permissions... |
| 02:54.48 | Zehra | so i might want to have the "verified" group have some permissions |
| 02:55.13 | Zehra | but will reduce the permissions from an untrusted group, unless part of another group |
| 02:56.13 | Zehra | also i might want to share a plug-in which would grant certain permissions to some groups, even if the group is not loaded |
| 02:56.40 | Zehra | (which isn't possible, so this idea wouldn't work.) |
| 02:58.09 | Zehra | probably one of my projects which is a little crazy in managing things |
| 02:58.25 | Zehra | but it would be a little interesting to see |
| 03:00.33 | Zehra | the idea is not to try to go out and ban players, but limit what the ones who are likely to create issues can do |
| 03:02.18 | blast007 | I could simplify the system for you and just delete your groups |
| 03:02.32 | blast007 | then you could just work with raw permissions! |
| 03:02.41 | blast007 | and BZIDs! |
| 03:03.28 | Zehra | please don't |
| 03:03.31 | blast007 | again, it's a silly tank game. you're WAY overengineering it. |
| 03:03.57 | blast007 | there should be no need for more than 4 groups, especially for a server that nobody plays on |
| 03:05.53 | Zehra | i'll make use with what i currently have :) |
| 03:06.17 | Zehra | it was kind of an overly complicated system which i was thinking of |
| 03:07.09 | Zehra | sort of like limiting 'everyone' from chatting unless 'verified'. |
| 03:07.35 | the_map | just don't allow chatting to the "everyone" group. give that permission to the "verified" group. |
| 03:09.39 | blast007 | admin, cop, whitelist, hidden admin - what else would you need? |
| 03:10.55 | Zehra | unless i'm the most popular server, it does not seem much more is needed. |
| 03:11.17 | Zehra | although bztank.net has a lot of groups loaded |
| 03:12.13 | JeffM | the API does not allow group creation. |
| 03:12.52 | blast007 | I ran the top server for a good while. I had 5 groups, and one was just me, so a plugin could have easily handled that one. |
| 03:16.38 | Zehra | i haven't run a public server, so the amount of permissions and groups is not perfectly thought of. |
| 03:17.07 | Zehra | has seen servers without additional groups and some with several groups |
| 03:39.44 | *** join/#bzflag alfa1 (~alfa1@host36.190-225-25.telecom.net.ar) |
| 07:11.21 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 13:35.13 | *** join/#bzflag alfa1 (~alfa1@host108.190-225-35.telecom.net.ar) |
| 15:04.44 | alfa1 | what headers should I include to be able to do 'BZDB.get' into my plugin? |
| 15:05.20 | alfa1 | I am trying to print the value of a variable |
| 15:05.27 | blast007 | you don't use BZDB.get. You use the API functions for getting those. |
| 15:05.46 | alfa1 | ah ok; looking... |
| 15:06.22 | blast007 | look at bzfsAPI.h and search for the comment "// BZDB API" |
| 15:06.32 | alfa1 | ok |
| 15:58.42 | alfa1 | it is working now: http://i.imgsafe.org/3d1aa9d9f2.png & http://i.imgsafe.org/3d1b8743ec.png ('paso' = step). I made 1 second between each step. |
| 15:59.40 | alfa1 | steps 2 to 4 (3) are the reducing/increasing values ones |
| 16:02.14 | blast007 | you don't need to disable the speed checks when increasing |
| 16:02.57 | blast007 | and you may not need to have a separate step for disabling speed checks, just for enabling them |
| 16:03.38 | alfa1 | yes, I agree, but I just wanted a major security |
| 16:04.10 | JeffM | if you want security don't use bzflag |
| 16:05.16 | alfa1 | then you believe I don't need to disable the check for increasing; is it just how it works or other cause? |
| 16:05.30 | JeffM | think about it |
| 16:05.38 | JeffM | the check will have a higher speed than the client |
| 16:05.47 | JeffM | so the speeds the client's have will be lower |
| 16:05.55 | JeffM | the check is only if the client speed is higher |
| 16:06.13 | JeffM | anyone with a higher speed than the server during the increase IS Cheating |
| 16:09.43 | alfa1 | networking: the server sets the speed variable tinier and sends the msg; the client gets the msg, decreases the speed and sends the msg; the server gets the msg? |
| 16:10.47 | JeffM | you realy don't get the problem do you? |
| 16:11.17 | alfa1 | I forgot, at start, the client sets the variable |
| 16:11.18 | JeffM | server sets the speed, server sends the message. Before the message gets to client, client sends a message with the old speed. Client gets new speed. Server gets message with old speed, server says speed is wrong. |
| 16:11.39 | JeffM | you can NOT assume an order |
| 16:11.44 | JeffM | not between client and server |
| 16:12.20 | alfa1 | no, I am not trying to understand the problem, I have an idea of that; I am trying to und. the basics first |
| 16:12.36 | blast007 | alfa1: this is the basics |
| 16:12.54 | alfa1 | who does set the variable first: the client or the server? |
| 16:12.57 | JeffM | yeah do you see where the problem is if the order happens the way I said? |
| 16:13.03 | JeffM | server |
| 16:13.13 | JeffM | but it may not GET to the client before the client sends an update |
| 16:13.24 | blast007 | the server also assumes that there is 0 latency for setting variables |
| 16:13.42 | blast007 | it does not wait for all the clients to acknowledge the change |
| 16:13.53 | alfa1 | ah, right, I don't run a command in this case but a plugin which is server side... |
| 16:14.17 | blast007 | /set and your plugin do the same thing |
| 16:14.39 | alfa1 | but /set is run at first in the client |
| 16:14.56 | blast007 | no, it isn't run on the client |
| 16:15.02 | JeffM | <PROTECTED> |
| 16:15.13 | JeffM | plugin = server |
| 16:15.17 | blast007 | the client just sends that string of text to the server, and the server processes it |
| 16:15.35 | alfa1 | I mean, I do /set in the client and then the server gets the msg and executes it |
| 16:15.49 | JeffM | yes, but the client doesn't change anything untill the server says to |
| 16:15.49 | alfa1 | ok |
| 16:16.17 | JeffM | client sends "/set" to server, server changes bzdb var, server sends bzdbvar update to all clients, client changes internal bzdb var |
| 16:16.37 | JeffM | so yeah, you WILL get updates inbetween |
| 16:16.41 | JeffM | from other clients |
| 16:16.47 | blast007 | until we move to quantum networking |
| 16:16.50 | JeffM | or even the client that did the /set |
| 16:16.51 | alfa1 | then, I say it again (to see the very basics): "networking: the server sets the speed variable tinier and sends the msg; the client gets the msg, decreases the speed and sends the msg; the server gets the msg?" |
| 16:17.11 | JeffM | you are missing a part |
| 16:17.35 | JeffM | where a client sends an update inbetween the server side set and the client getting the speed update |
| 16:17.45 | blast007 | the client never stopped sending movement updates |
| 16:18.22 | alfa1 | I know that all the time there are msgs going out and in the server; I am just trying to understand 1 group of them |
| 16:18.45 | JeffM | that's the problem, you can't just take a single set and ignore the others, it's the others that are your problem. |
| 16:18.50 | blast007 | but that understanding doesn't help |
| 16:19.20 | alfa1 | if I understand 1 group of them, then I can multiply them (with the respective crossing in a possible disorderd way) |
| 16:19.31 | JeffM | but it does not multiple like that |
| 16:19.38 | JeffM | it's all mixed |
| 16:19.42 | JeffM | not just scaled |
| 16:20.14 | alfa1 | well, okay, I said that; but then my phrase was basically right |
| 16:20.17 | JeffM | just know that when you lower the speed the client won't know for a while, but when you increase the speed it doesn't matter, becuase the client won't know for a while, so it'll always be slower. |
| 16:20.54 | alfa1 | ok, and now I ned time to understand the situation of increasing, thanks |
| 16:20.58 | alfa1 | need* |
| 16:28.47 | alfa1 | <JeffM> "think about it"; "the check will have a higher speed than the client"; "so the speeds the client's have will be lower"; "the check is only if the client speed is higher"; "anyone with a higher speed than the server during the increase IS Cheating": okay I am seeing it now; thanks |
| 16:37.18 | JeffM | yes, there is no valid reason for a client to have a speed over the limit when you know it's increasing |
| 16:37.29 | JeffM | they can't look into the future, they can only be late from the past |
| 16:38.14 | JeffM | the fact that the speed check is for > speed, makes the algorithm asymmetric. |
| 16:39.13 | alfa1 | yes, and I didn't know the check was only for higher values; though, now I think about it, it is logical (nobody is going to want to be slower than the rest :) |
| 16:39.46 | blast007 | well, you can move slower than max speed ...... |
| 16:39.50 | JeffM | what else would it before? checking to see if it is exactly the speed? |
| 16:40.03 | JeffM | did you think everyone MUST move at max speed? |
| 16:40.20 | JeffM | this tells me you don't really understand the logic involved |
| 16:40.35 | alfa1 | ah okay :P |
| 16:40.42 | alfa1 | yes, max speed... |
| 16:40.55 | blast007 | do you play this game? |
| 16:40.57 | JeffM | you play with a keyboard don't you :) |
| 16:40.57 | alfa1 | I was just thinking on cheaters |
| 16:41.08 | blast007 | even a keyboard can move slower |
| 16:41.14 | JeffM | can but may not |
| 16:41.36 | JeffM | he may not know about the slow movement keys |
| 16:41.52 | JeffM | clearly he's missing some info on how bzflag works |
| 16:41.56 | blast007 | always does at the start. IIRC, there's a short 'ramping up' time after you initially press the arrow keys, so that quick taps can trigger smaller movements |
| 16:42.07 | alfa1 | yes, 5 years playing :); I just need to think more before opening my mouth sometimes :P |
| 16:42.17 | kierra | amen :) |
| 16:43.36 | alfa1 | these development tasks make your mind gets tired and hurried, though |
| 16:43.51 | JeffM | it's just basic logic |
| 16:49.46 | alfa1 | I want to say I will keep improving it, but I just wanted to show that it worked already |
| 16:50.55 | alfa1 | and that I was somewhat right about it being possible ("my method"); though thanks for all the advices and corrections |
| 16:55.17 | alfa1 | and I repeat, just in case: this situation could be compared, maybe, with the 'UDP-kick' issue (a frequent one) and maybe has a similar fix |
| 17:02.47 | JeffM | no, that's not the same thing |
| 17:04.10 | alfa1 | it just checks if the client has that bit enabled? but it is a networking issue too I guess; maybe giving them a bit more of time (1 second more?)? |
| 17:04.19 | JeffM | no |
| 17:04.22 | JeffM | UDP is lossy |
| 17:04.49 | alfa1 | UDP is lossy but the check is not |
| 17:04.54 | JeffM | sorta |
| 17:04.57 | JeffM | it's a complicated check |
| 17:05.02 | blast007 | the UDP kick is when the client fails to send (and/or receive) player updates over UDP |
| 17:05.08 | JeffM | yeah |
| 17:05.08 | alfa1 | TCP for the check? |
| 17:05.12 | JeffM | no |
| 17:05.18 | JeffM | well half of it |
| 17:05.25 | JeffM | half is over UDP to make sure UDP works |
| 17:05.33 | JeffM | if UDP doesn't work, boom you are gone |
| 17:05.46 | JeffM | it's a VERY different situation |
| 17:05.47 | blast007 | if it receives a shot message over TCP, it assumes that UDP is broken for that client and kicks them |
| 17:06.11 | blast007 | in the future we'd probably not use TCP for the game data |
| 17:06.14 | JeffM | I've become very familar with the complexities of the UDP handshake as part of libBZFlag |
| 17:06.15 | blast007 | game protocol* |
| 17:06.26 | JeffM | yeah, enet or somethign like that |
| 17:08.04 | alfa1 | "<blast007> the UDP kick is when the client fails to send (and/or receive) player updates over UDP": maybe giving the clients (or server too?) more time for that check? |
| 17:08.24 | alfa1 | (or more tries) |
| 17:08.24 | blast007 | no |
| 17:08.25 | JeffM | time doesn't help |
| 17:08.28 | JeffM | it doesn't retry |
| 17:08.31 | JeffM | it's just GONE |
| 17:08.38 | JeffM | UDP doesn't retransmit |
| 17:08.50 | JeffM | one shot, done. |
| 17:09.08 | JeffM | if that UDP handshake fails, you are screwed |
| 17:09.09 | blast007 | we could attempt UDP again, but we don't |
| 17:09.17 | JeffM | yeah |
| 17:09.19 | blast007 | and there's little point changing it now |
| 17:09.21 | JeffM | it's not a robust handhsake |
| 17:09.23 | alfa1 | I am talking of the check, not of the protocol. Where is the check made? on client or server? both? |
| 17:09.27 | blast007 | gut it for 2.6 |
| 17:09.36 | JeffM | server, after the handsake |
| 17:09.38 | JeffM | shake |
| 17:09.44 | JeffM | it's NOT the same thing, trust us |
| 17:10.02 | JeffM | ether take the time to learn the code, or stop trying to guess and anoy us |
| 17:11.45 | alfa1 | "<blast007> we could attempt UDP again, but we don't": this is what I am talking about; give them 1 or more tries; why not? is it so critical? happens frequently |
| 17:12.10 | blast007 | happens frequently to people with bad connections |
| 17:12.10 | JeffM | because it would be wasted effort since the goal is to replace all of networking |
| 17:13.02 | alfa1 | not sure blast; the most common way to fix it, in game, is to rejoin; if it was permanent it would be kicked again and again |
| 17:13.28 | JeffM | he didn't say it was permanent |
| 17:13.31 | JeffM | stop guessing |
| 17:13.41 | JeffM | things the channel should go reg voice for a while |
| 17:13.47 | alfa1 | the majority of the times you just rejoin once and done; I have seen very few times when the problem persists more than that |
| 17:13.57 | JeffM | that's the nature of UDP |
| 17:14.00 | JeffM | learn networking |
| 17:14.05 | blast007 | then it doesn't sound like a very frequent thing ;) |
| 17:14.17 | blast007 | and it's not like it kicks you half-way through playing |
| 17:14.31 | blast007 | it kicks on the first shot |
| 17:14.54 | alfa1 | yes, first shot |
| 17:15.05 | JeffM | so before anything important |
| 17:15.11 | JeffM | before you can affect the world |
| 17:15.30 | blast007 | unless you go on a rampage with steamroller |
| 17:15.52 | JeffM | could kick on update via TCP |
| 17:15.54 | alfa1 | to say a percentage... of 100 times a player joins, it happens... 5%? 10%? 15%? more? anyone else help me with this? |
| 17:16.04 | JeffM | we do not have that data |
| 17:16.06 | blast007 | I think that would kick everyone, JeffM :) |
| 17:16.20 | JeffM | probalby |
| 17:16.32 | JeffM | could change spawn to not send untill UDP is handled. |
| 17:16.32 | alfa1 | (anyone else who plays frequently like me JeffM :) |
| 17:16.51 | blast007 | again, it's your crap connection |
| 17:17.03 | alfa1 | let's say 10%; it is important |
| 17:17.11 | blast007 | are you on wifi? |
| 17:17.16 | JeffM | if it's important, you can't frigging guess |
| 17:17.21 | JeffM | no lets say 0.001% |
| 17:17.28 | alfa1 | no, I am always on wire |
| 17:17.30 | JeffM | my guess is just as valid as yours |
| 17:17.58 | alfa1 | not happening to me (almost never) but to others |
| 17:18.09 | JeffM | but you have no data, so you are just guessing |
| 17:18.38 | blast007 | now stop bugging us about this |
| 17:18.40 | JeffM | we know the networking system sucks |
| 17:18.59 | JeffM | you aren't going to solve all it's problems |
| 17:19.03 | alfa1 | I have an strong impression, JeffM; of course I have not made any case study; I could do it if you all agree |
| 17:19.10 | JeffM | replacing it with a lib is going to solve all it's problems |
| 17:19.14 | JeffM | and then make some new ones |
| 17:19.29 | alfa1 | well, I stop, just wanted to help |
| 17:19.33 | JeffM | oh I'd not accept any code you wrote to the project. |
| 17:19.43 | JeffM | also it'd have to wait for a proto break |
| 17:19.48 | JeffM | sicne the check is tied to the prototocl |
| 17:19.52 | alfa1 | I said study case, maybe a document, not code |
| 17:19.59 | JeffM | the part you failed to understand. |
| 17:20.02 | alfa1 | or just info |
| 17:20.06 | JeffM | we know the problem, we don't need more info |
| 17:20.09 | alfa1 | statistics |
| 17:20.22 | JeffM | you assume that because it isn't fixed, we dont' know how to fix it. that is not true |
| 17:20.25 | JeffM | we know how to fix it |
| 17:20.29 | JeffM | it just hasn't been fixed. |
| 17:20.57 | alfa1 | yes, you are going to remake all the netoworking in the future, right? |
| 17:21.07 | JeffM | if there is a future, maybe |
| 17:21.10 | alfa1 | an easy slution :) |
| 17:21.20 | alfa1 | and fast |
| 17:21.40 | JeffM | do you see a flurry of development? |
| 17:22.18 | alfa1 | should I continue or stop chatting? |
| 17:22.28 | alfa1 | I don't want to be kicked, etc. |
| 17:22.39 | JeffM | depends if it's about UDP or not |
| 17:22.54 | alfa1 | I meant, you just asked me |
| 17:23.08 | JeffM | it was retorical |
| 17:23.09 | alfa1 | but you both are telling me also to stop |
| 17:23.48 | alfa1 | well, somtimes it is not clear if it is |
| 17:23.55 | alfa1 | (rethorical) |
| 17:24.26 | blast007 | and he gave you a rhetorical answer |
| 17:24.33 | JeffM | clearly there is not a flurry of development |
| 17:24.47 | JeffM | or maybe you don't know because you can't see anything on github |
| 17:25.41 | alfa1 | I still don't undersand, sorry if it is me, should I continue or stop chatting? |
| 17:26.55 | JeffM | goes and listens to the Wonder Woman soundtrack |
| 17:29.05 | JeffM | allejo: you once said there were tools to help github repos manage developer agreements, am I remembering that correctly? |
| 17:29.32 | blast007 | bots |
| 17:30.04 | JeffM | via commit hooks and stuff? |
| 17:30.18 | allejo | yah |
| 17:30.26 | allejo | well web hooks to PRs |
| 17:30.36 | JeffM | sure same idea :) |
| 17:30.39 | blast007 | https://clabot.github.io/ |
| 17:30.48 | blast007 | https://github.com/python/the-knights-who-say-ni |
| 17:31.11 | allejo | https://www.clahub.com/ |
| 17:31.59 | JeffM | cool, thanks |
| 17:32.00 | blast007 | do those work best when everything is a pull request? |
| 17:32.45 | allejo | yah, no way to enforce it on regular repos unless you do it manually for those with commit access |
| 17:33.01 | blast007 | though I guess any you give direct push access should already have signed the CLA |
| 17:33.22 | allejo | e.g. have an organization (which has some push restrictions) where you can create a "CLA" team and only allow members of that team to push |
| 17:33.36 | JeffM | yeah that probalby would not be an issue as long as the admins are aware. |
| 17:34.02 | JeffM | and you should not add someone who hasn't had a pull request |
| 17:34.40 | allejo | https://cla-assistant.io/ is another option too |
| 18:11.45 | the_map | the spacebar would be a great key to shoot with |
| 18:11.57 | the_map | use both thumbs, and it sounds like a machine gun |
| 18:12.29 | the_map | welp,there.goes.my.spacebar |
| 18:12.38 | the_map | that.was.fun.while.it.lasted |
| 18:13.29 | blast007 | everyone knows space is for jumping |
| 18:13.39 | the_map | no, that's F12 |
| 18:13.49 | blast007 | my F12 key doesn't work |
| 18:15.19 | the_map | every time I try to type "F12" I just press the F12 key instead, it drives me nuts |
| 18:15.24 | the_map | same with the other function keys |
| 18:17.17 | allejo | call D2 next and i'll have bingo! |
| 18:17.40 | the_map | D3! |
| 18:17.47 | allejo | AGH |
| 18:17.49 | *** join/#bzflag Void7 (~Void7@2604:a880:1:20::1315:3001) |
| 18:17.49 | *** join/#bzflag KaadmY (~kaadmy@2604:a880:1:20::1315:3001) |
| 18:43.19 | *** join/#bzflag alfa1 (~alfa1@181.91.63.199) |
| 19:49.32 | JeffM | just require everyone to get a gamepad |
| 19:49.45 | JeffM | that was the idea for the iphone version right :) |
| 20:02.35 | alfa1 | may I ask for people to help me test something? |
| 20:08.28 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 21:15.11 | alfa1 | "[Dom 10 Jul 2016] [12:17:15] <BulletCatcher>I have a change that adds --disable-server. [Dom 10 Jul 2016] [12:17:15] <BulletCatcher> I'll commit it in a few days when I have more time.": any possibility this is happening soon? just curiosity since I have to compile a new plugin and then I need to compile the server again mandatory (if I am right) |
| 21:16.13 | blast007 | that would disable the plugin builds too... |
| 21:16.47 | blast007 | but if you're rebuilding the server every time, you're doing it wrong |
| 21:17.05 | blast007 | just run 'make', not 'make clean ; make' |
| 21:17.46 | alfa1 | ah, then, only I can run the plugins that are in the last ./configure argument? |
| 21:18.22 | alfa1 | or only the first time to compile it? |
| 21:18.31 | blast007 | run? you mean build? |
| 21:18.52 | alfa1 | (yes, not doing 'make clean' and 'make' anymore) |
| 21:19.32 | alfa1 | 'run' as is including it in the config file |
| 21:20.16 | alfa1 | as in* |
| 21:21.02 | blast007 | why would the build process have anything to do with running bzfs? |
| 21:21.10 | blast007 | it's not building the plugins INTO bzfs |
| 21:21.16 | blast007 | they're separate files |
| 21:21.26 | blast007 | the build process controls what you BUILD |
| 21:21.38 | alfa1 | in example, now I have 2 custom plugins, should I include both in the './configure' argument or not necessary since I have already built one? |
| 21:21.47 | blast007 | yes - why wouldn't you? |
| 21:22.27 | blast007 | but that doesn't have ANYTHING to do with running bzfs. that only has to do with what plugins get built during the build. |
| 21:23.02 | blast007 | are you running configure every time you build your plugin? |
| 21:24.03 | alfa1 | no, I only do 'make' now |
| 21:24.18 | alfa1 | but now I need a new custom plugin |
| 21:24.18 | blast007 | so what is the problem then? |
| 21:24.32 | blast007 | so run configure with both plugins specified |
| 21:24.35 | blast007 | bam, done |
| 21:25.27 | alfa1 | I know that works, but I was wondering about some things lately (and for 1 year now at least) |
| 21:26.15 | alfa1 | is thinking now |
| 21:27.14 | alfa1 | I thought that only I needed the plugins to be compiled and then I can use them when I want |
| 21:28.41 | alfa1 | in example, the default plugins seem to be always compiled (at least the first time), not on demand |
| 21:28.53 | alfa1 | but custom plugins are on demand |
| 21:30.04 | alfa1 | then I wondered if I already had a custom plugin compiled if it was necessary to include it again on configure; but yes, then always I run 'make' they both will compile |
| 21:30.32 | alfa1 | (when I wanted to include a new custom one, not compiled) |
| 21:31.05 | alfa1 | and also wondered if the server could be disabled, but you said 'no' |
| 21:31.29 | alfa1 | they are external libraries, linked dynamically then |
| 21:33.00 | JeffM | install windows, building is much easier |
| 21:33.41 | alfa1 | ok, I think I understood; not sure why the server needs to be included since it lasts 5 minutes to compile (and plugins are not statically linked) and thought that maybe BulletCatcher's addition could fix it |
| 21:33.54 | alfa1 | , though* |
| 21:34.11 | JeffM | plugins are only run by the server, if the server is excluded, then we assume you are client only, so plugins are skipped |
| 21:34.31 | JeffM | so if you don't build a server then you don't need to build plugins. |
| 21:36.34 | alfa1 | oh, then, (still reading blast007)... to compile a new plugin, doing a new './configure', I don't need to compile the server again, right? |
| 21:37.25 | alfa1 | (not need for 'make clean' I guess in this case either) |
| 21:38.11 | blast007 | right |
| 21:38.17 | alfa1 | ah nice |
| 21:38.43 | JeffM | make clean is only used when you want to start 100% over, like when you screwed up big time |
| 21:38.47 | JeffM | or you have some problem |
| 21:38.56 | JeffM | or are getting ready to make a zip |
| 21:40.14 | alfa1 | then we build the server again only for the dynamic new links (just few text) we now include? |
| 21:40.14 | JeffM | or are trying to make it look like you are working at your job and want the compiler to take longer |
| 21:40.34 | JeffM | the server only rebuilds when the server changes |
| 21:41.44 | alfa1 | ok, then the dynamic new links (new custom plugins) |
| 21:42.00 | alfa1 | (new and old custom plugins we need) |
| 21:42.03 | JeffM | the server does not know or care about your pluing |
| 21:42.06 | JeffM | not untill it runs |
| 21:42.11 | JeffM | has NOTHING to do with building |
| 21:42.26 | JeffM | what part of dynamic do you not understand? |
| 21:43.22 | *** mode/#bzflag [+o blast007] by ChanServ |
| 21:43.31 | *** mode/#bzflag [+q $~a] by blast007 |
| 21:43.33 | *** mode/#bzflag [-o blast007] by blast007 |
| 21:46.44 | JeffM | Maxwell's silver hammer came down upon his head. |
| 22:15.45 | *** part/#bzflag alfa1 (~alfa1@181.91.63.199) |
| 23:53.04 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
