*** Gollum <Gollum!~Gollum@131.93.56.40> has joined #bzflag | 00:23 | |
Agatha | Is there a way to set SW life for a world weapon shot? This isn't clear to me. | 02:01 |
---|---|---|
blast007 | does it use the same BZDB values that clients would use? | 02:03 |
Agatha | It doesn't have to, no. | 02:04 |
Agatha | I.e., if the BZDB value for a SW is changed, it shouldn't affect this special SW. (There may be special BZDB values for this special SW, but nevermind that.) | 02:05 |
blast007 | what exactly are you trying to do? | 02:10 |
Agatha | I would like to make an explosion effect using SW-type world weapons, but not have it be tied to the parameters of the bona fide SW flag. | 02:14 |
blast007 | I don't know if that's possible | 02:15 |
Agatha | Can we change the reload time for shooting with custom flags? | 02:20 |
blast007 | no | 02:21 |
Agatha | great :V | 02:21 |
*** Gollum <Gollum!~Gollum@131.93.56.40> has quit IRC (Quit: Client closed) | 03:07 | |
*** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 258 seconds) | 03:17 | |
Agatha | When sending a message from the server, should I use `BZ_SERVER`, `BZ_SERVERPLAYER` or `ServerPlayer`? They're all the same, ish. | 05:16 |
*** Optic_Delusion <Optic_Delusion!~Optic_Del@pool-173-75-132-184.pitbpa.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds) | 06:29 | |
*** Optic_Delusion <Optic_Delusion!~Optic_Del@pool-173-75-132-184.pitbpa.fios.verizon.net> has joined #bzflag | 06:36 | |
*** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 07:30 | |
*** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 252 seconds) | 08:05 | |
*** ashvala <ashvala!~quassel@104.131.125.108> has quit IRC (*.net *.split) | 08:48 | |
*** ashvala <ashvala!~quassel@104.131.125.108> has joined #bzflag | 08:49 | |
*** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 09:31 | |
SpringTank | Is there a way to have customized flag properties. For example: Steamroller with high speed and stealth, but no shots forcing a player to sneak up on and chase down others. Or MQ with stealth to make it harder for enemys to differentiate. Both of those flags are kinda useless as they are and my intentions are to buff them on a test server to see how it changes the gameplay. | 09:56 |
*** Gollum <Gollum!~Gollum@131.93.56.40> has joined #bzflag | 11:14 | |
*** Gollum <Gollum!~Gollum@131.93.56.40> has quit IRC (Client Quit) | 11:14 | |
blast007 | BZ_SERVER = -1, BZ_SERVERPLAYER = 253, and ServerPlayer is not part of the API (but is also 253). If you look at bz_sendTextMessage, it checks if the from player is BZ_SERVER and sets the playerIndex to ServerPlayer. Some other functions check for BZ_SERVER but not the 253 value equivilents, so I'd use BZ_SERVER normally. | 11:19 |
blast007 | SpringTank: nope | 11:19 |
SpringTank | maybe in a future update? | 11:50 |
blast007 | I can't recall if 2.5 has made any further progress with that, or if I am thinking of 2.99.x | 12:22 |
blast007 | 2.99.x at least had decoupled the flag effect from the flag itself, but I still don't think you could combine effects | 12:22 |
blast007 | if we want to go the route of fully customized flags/weapons/powerups, we'd likely need some scripting language on the client | 12:25 |
SpringTank | sounds interesting | 12:25 |
blast007 | 2.99.x had Lua scripting in the client and server | 12:26 |
SpringTank | and I agree with the client side scripting language | 12:26 |
SpringTank | i heard about that | 12:26 |
SpringTank | I think LUA would help with A LOT of things | 12:26 |
SpringTank | its deff a step in the right direction | 12:26 |
SpringTank | any plans for moveable objects like doors and such? | 12:27 |
blast007 | nope | 12:27 |
blast007 | that's tricky to make work | 12:28 |
SpringTank | I've been thinking of ways to implement it. deff wouldn't be trivial. | 12:28 |
blast007 | yeah, the sync issues would be a problem | 12:28 |
SpringTank | how precise is the game time? | 12:29 |
SpringTank | game ticks | 12:29 |
blast007 | we had something in 2.99.x called the ClientIntangibilityManager that was supposed to allow objects to become drivethrough/shootthrough dynamically | 12:29 |
SpringTank | oooo | 12:29 |
SpringTank | that would be good for koth | 12:30 |
SpringTank | multi point koth | 12:30 |
blast007 | precise? well, it's not consistent.. it's based on FPS :) | 12:30 |
SpringTank | ooof | 12:30 |
SpringTank | what about server time? | 12:30 |
SpringTank | is it only in seconds? | 12:30 |
blast007 | depends if they are players on or not and a few other factors | 12:30 |
blast007 | depends what you mean by precise though | 12:31 |
SpringTank | a master clock that gets syncronised with each client | 12:31 |
blast007 | it should keep time accurately enough (at least if you're not using a Windows bzfs) | 12:31 |
SpringTank | with lag accounted for ofc | 12:31 |
blast007 | I don't think we do any lag compenstation with regards to the game time, for instance | 12:32 |
blast007 | and clients handle the bullet ricochet logic for other tanks as well | 12:32 |
blast007 | so if you start adding moving objects or doors, you'll get some players seeing the bullets bounce off and other where it goes through | 12:33 |
blast007 | (goes through an open area that is) | 12:33 |
SpringTank | hmmm, i think a master clock with precision down the the ms synconised across all clients and the server would enable the clients and server to account for lag much better for stuff like world weapons and possibly doors in the future. | 12:33 |
blast007 | we tried lag compensation in 2.99.x and it didn't go well, but I think we compensated the wrong direction | 12:34 |
SpringTank | i think it could be added in without changing too much at the moment, and would make it easier to implement a more authorative server in the future | 12:34 |
SpringTank | lol | 12:34 |
blast007 | in 2.99.x, it fast forwarded time based on how much lag a player had. So, for intsance, if someone with 500ms of lag fired a bullet, your client would first see the bullet 500ms in front of their tank (based on whatever the shot speed is) | 12:35 |
blast007 | instance* | 12:35 |
SpringTank | ^ | 12:35 |
SpringTank | but where the shots still client side or server side? | 12:35 |
blast007 | so if a laggy player jumped up at you, they could effectively spawn a bullet inside your tank :P | 12:35 |
SpringTank | hah! | 12:35 |
blast007 | still client side | 12:35 |
blast007 | deaths are, if that's what you mean | 12:35 |
SpringTank | deaths are server side? | 12:36 |
blast007 | no, client side | 12:36 |
SpringTank | off, BUT! | 12:36 |
SpringTank | that gives me an idea for another game mode | 12:37 |
SpringTank | using a modded client set to follow a spacific path but only move forward when other team member are parked next to you. you could make a payload game mode | 12:37 |
SpringTank | where your team's goal is to get that tank to the other teams base to blow it up | 12:37 |
blast007 | I was just looking at a screenshot earlier of someone saying that on Louman's Churchyard that they can drive/shoot through the trees, but for everyone else they were solid | 12:37 |
SpringTank | huh | 12:38 |
SpringTank | differences in client versions maybe? | 12:38 |
blast007 | they were using 2.4.18 on a mac, so I forget if I had tried the same version and found that problem too | 12:38 |
blast007 | s/so I/but I/ | 12:39 |
blast007 | https://static.bzexcess.com/bzflag_assets/logo-retrace-3/ https://static.bzexcess.com/bzflag_assets/logo-retrace-3/renders/ | 12:41 |
SpringTank | those look cool | 12:41 |
blast007 | yeah, this retrace turned out much better than the last one | 12:44 |
blast007 | it even looks fine rendered to 16x16 | 12:44 |
SpringTank | just fooling around in gimp with what you just did blast. I converted white to transparancy and put some pictures that I took a while back as the background. | 13:07 |
SpringTank | https://imgur.com/a/s28Va7F | 13:07 |
SpringTank | they look better as thumbnails IMO | 13:07 |
blast007 | :) | 13:14 |
SpringTank | Shot handler for projectile weapons: server and clients sync master timer on player join and occasionally re-check and resync if nessasary: player fires shot, client tells server that it wants to fire a shot at that location at that time. local client ONLY plays animation of shot. Server then sends out a shot message with current master time to all other clients. All clients now know when that shot was sent from the | 13:21 |
SpringTank | server so they can compensate for lag. Server handles all physics for ricos and player deaths. clients only play animations of shots and their ricos. | 13:21 |
SpringTank | ^ Just a thought | 13:21 |
SpringTank | laser would be considered hitscan | 13:23 |
SpringTank | so it would be handled a bit differently | 13:23 |
blast007 | at the moment, the server doesn't even know where bullets are | 13:33 |
blast007 | also doesn't know where players have been | 13:34 |
blast007 | it just knows their last state | 13:34 |
SpringTank | hah! | 13:43 |
SpringTank | might be easier to copy server code over to a client and start from there! kidding ofc | 13:44 |
*** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 13:44 | |
blast007 | other way around you mean? | 13:52 |
SpringTank | no ;) | 13:55 |
SpringTank | so wait. how can the server *not* know what the clients are doing and where they are? doesn't all player/shot data get passed through the server at some point? | 13:56 |
blast007 | it's mostly a relay, with some basic state tracked | 14:03 |
blast007 | the server, for instance, doesn't do any ricochet projections. only the client does. | 14:03 |
blast007 | ideally we'd have a library shared between the client and the server that handled the simulation | 14:04 |
SpringTank | That's exactly what I was thinking | 14:04 |
blast007 | if would be fed normalized input states (a range of motion from, say, -32k to +32k, or boolean states like the jump key being held down) created from input devices, and it would handle calculating the updated game state | 14:06 |
blast007 | then the client and server could both run the same simulation | 14:06 |
SpringTank | yes, exaclty what I was thinking of | 14:07 |
blast007 | https://yal.cc/preparing-your-game-for-deterministic-netcode/ https://news.ycombinator.com/item?id=27253890 | 14:08 |
blast007 | https://gafferongames.com/post/deterministic_lockstep/ | 14:09 |
SpringTank | ^ exactly what I was implying, put in much better words than what I can | 14:13 |
SpringTank | Seems like it would almost require rewriting the entire game | 14:14 |
blast007 | it would be a significant refactor, at least | 14:17 |
blast007 | the starting point for that would be to make a client library that the server-side players can use and get that working, and then eventually use it for the actual client as well | 14:17 |
SpringTank | It's doable. I'm thinking removing functions from the game but keep it compilable until I have just the skeleton of a game left and start from there. Obvioulsy I wouldn't just delete the code, just move it to a holding spot in case it is needed. Then start rebuilding it from there. | 14:21 |
Agatha | I know that a lot of work has been put into various refactors and rewrites by various people over the years, but IDK what the state of those is. 2.5? 2.99? 3? What exists, is seen as viable, etc.? (Not particularly looking for an answer; just wanting to observe that people have tried major stuff before. I guess it's probably in git on some branches.) | 14:45 |
SpringTank | blast has the right idea IMO | 15:02 |
SpringTank | the problem is that it seems no one has the experence ~or the will~ to do it | 15:02 |
blast007 | 2.99.x had a lot of useful code (or at least, ideas/concepts) | 15:15 |
blast007 | it suffered from insane feature creep, along with game breaking bugs because half-finished or under-tested code was merged | 15:16 |
SpringTank | ah | 15:16 |
SpringTank | yeah, i remember that | 15:16 |
SpringTank | and here we are talking about more and more feature lmao | 15:16 |
blast007 | IIRC, the issue that really put the nail in the coffin was where the game, after being played for a hour or two, would start to have weird sync or lag-like issues | 15:17 |
SpringTank | that's odd | 15:17 |
blast007 | and it might have even required that several people where playing | 15:17 |
blast007 | so it was a fun one to debug since there wasn't a fast "change code, recompile, test" loop | 15:17 |
SpringTank | why not script the recompile/server restart? | 15:18 |
blast007 | though it might be enough to just initialize the start time of the server to 24 hours in the past | 15:18 |
SpringTank | it's what I do when testing plugins. press a button and go | 15:18 |
SpringTank | and then script a bunch of bots to autojoin | 15:19 |
SpringTank | let them run for a while | 15:19 |
blast007 | what I mean is, that you had to make a change, compile, restart the server, and also get everyone else to recompile their clients, and then join and play for an hour or two to see if it was fixed | 15:19 |
SpringTank | right | 15:19 |
SpringTank | hmm | 15:19 |
blast007 | the compiling part wasn't what was slow - the testing duration was | 15:19 |
SpringTank | script a bunch of bots to join on the newly recompiled game | 15:20 |
blast007 | I have tested initialing the game start time to like 47 days and I seem to recall it not going so well :) | 15:20 |
SpringTank | hah | 15:20 |
SpringTank | but yeah, that's a really weird bug | 15:20 |
blast007 | there's probably something wonky with our lag comp code | 15:21 |
SpringTank | iirc minecraft had a similar bug if you traveled too far out in the world. | 15:21 |
SpringTank | ^ | 15:21 |
blast007 | yeah, floating point precision errors | 15:21 |
SpringTank | yep | 15:21 |
SpringTank | so maybe something similar with the lag comp code. | 15:24 |
SpringTank | at that point I would use fractional math | 15:25 |
SpringTank | but that creates other challanges | 15:25 |
SpringTank | fixed point fractional math | 15:26 |
Agatha | I noticed that the time is a `double`. If you used a `float` in the rework, then you'd get problems after a certain amount of time. | 15:30 |
SpringTank | double will cause problems as well because it's sitll a float. its a double precision float | 15:31 |
SpringTank | time shouldn't be stored in a float anyways... | 15:31 |
Agatha | For sure, but the time may be impractically far enough into the future so as not to matter. I haven't worked out how far exactly. | 15:31 |
Agatha | ^ | 15:31 |
Agatha | Anyway, ST and I have just found a memory leak. Specifically, this line appears to be leaked: https://github.com/BZFlag-Dev/bzflag/blob/2.4/src/bzfs/bzfsAPI.cxx#L4576 | 15:31 |
SpringTank | should be stored in an int | 15:31 |
SpringTank | wait, we found a leak? I thought it was a problem with your plug Ag | 15:32 |
SpringTank | here is the pastebin from Valgrind | 15:33 |
SpringTank | https://pastebin.com/YN5tr8wT | 15:33 |
Agatha | It may in fact be trouble with my plugin, but I think it is not. | 15:33 |
blast007 | what issue are you having? | 15:35 |
SpringTank | It never crashed for me, but appeared to make some clients crash when testing agatha's wackyweapons plugin. That's why I susspect it's the plugin itself causing it and not a memory leak in bzfs | 15:36 |
SpringTank | I didn't notice any other problems | 15:36 |
blast007 | is this plugin playing sound, or is it just adding custom flags? | 15:37 |
SpringTank | just adding cutom flags, on this server version I have custom sounds comment out. | 15:37 |
blast007 | a memory leak in bzfs should not make client crash | 15:37 |
SpringTank | ^ | 15:37 |
SpringTank | unless sending trash data causes the client to crash. | 15:38 |
blast007 | but a leak wouldn't send trash data | 15:38 |
blast007 | it's just memory that isn't freed in bzfs by the time the server exits | 15:38 |
Agatha | The crashing issue is separate. Also, I think they may be being kicked (instead of crashing) if their clients are too old, which is as-intended. I've added some messages to confirm/rule-out that case. | 15:39 |
blast007 | what changed in the client that requires a new-ish client? | 15:40 |
Agatha | This bugfix: https://github.com/BZFlag-Dev/bzflag/commit/bbcf0a888203c40d25dc2bee389bce98ae793eb9 | 15:41 |
blast007 | that's a server change, not a client change | 15:41 |
Agatha | :V Derp; you're right. So, the plugin doesn't need to impose anything on the players—at least because of that. | 15:43 |
SpringTank | hmmm | 15:45 |
*** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has joined #bzflag | 17:38 | |
Agatha | Are lasers affected by `_shotSpeed`? I vaguely remember that they are. | 17:47 |
blast007 | I think they are | 17:48 |
blast007 | might affect how far the laser reacher | 17:48 |
blast007 | reaches* | 17:48 |
*** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 17:48 | |
SpringTank | amazing how many layers haven't updated to 2.4.22 yet | 18:05 |
OkinaMatara | I remember you could do really funky things with laser by messing with some variables, both local and server-side. | 18:07 |
blast007 | SpringTank: some may be using a version packaged by their Linux distribution | 18:09 |
SpringTank | probably | 18:09 |
blast007 | for most, it doesn't really matter too much as long as it works | 18:09 |
SpringTank | *crys in debian* | 18:09 |
blast007 | :) | 18:10 |
blast007 | Debian 11 will still have .20 | 18:10 |
SpringTank | they are always behind versions, but it almost always works out of the box! | 18:10 |
blast007 | our flatpak version works better since it's using SDL2 instead of SDL1 | 18:10 |
SpringTank | had that problem with dependencies when steam and TF2 was first ported to linux. I never got that penguin hat that only early linux testers could get... | 18:11 |
SpringTank | I build from source | 18:11 |
SpringTank | except on windows | 18:11 |
SpringTank | because I can't get any IDEs to work properly on windows. | 18:12 |
SpringTank | except codeblocks, but no one uses codeblocks. (: | 18:12 |
OkinaMatara | It would be an interesting project to simply get a compiler and some shell scripts to compile BZ on Windows, this way VS does not need to be used. | 18:13 |
SpringTank | would be nice if I could just type "make" on windows | 18:13 |
SpringTank | i don't like VS, takes too long to load and then you get software license problems. | 18:14 |
OkinaMatara | I'm not entirely fond of VS, I recall slow booting of applications and build times. | 18:15 |
OkinaMatara | vs less than 2 second build time for plug-ins and less than 2 minute or so build times for bz. | 18:16 |
SpringTank | gotta have them dependencies for window's bloated api | 18:16 |
SpringTank | I will say though, windows has some pretty damn good backward compatability | 18:16 |
blast007 | Visual Studio is the main thing I miss from Windows, actually | 18:18 |
SpringTank | i could never get it to work right for me. couldn't even figure out how to compile a simple "hello word" program with VS but that's probably due to my lack of experence and stubborness of learning new things. | 18:20 |
blast007 | Xcode was so bad that I had to buy a different IDE | 18:25 |
SpringTank | XD | 18:26 |
moriah | ~BulletCatcher++ | 18:43 |
Agatha | Okay I have a dumb question. I've been struggling to get my own private server to recognize me as a registered player. It says "This callsign is registered. You must use global authentication.". My registration is recognized on every other server in existence. | 19:34 |
OkinaMatara | Is the server hosted on the same network or something? (Since auth may be for IP so and so, but connection is localhost.) | 19:36 |
blast007 | does "private" mean that it's listing itself on the public list server but it's using the -advertise option to hide itself? | 19:36 |
Agatha | The server has "-publictitle <title>", "-publicaddr laserlady.freemyip.com", "-publickey <key>", "-advertise NONE", "-q", "-userdb <file foo>", "-groupdb <file bar>", and "-password <pw>". It's running on the same network. I connect to "localhost". | 19:40 |
blast007 | can other players connect to that server and authenticate? | 19:42 |
OkinaMatara | I might be mistake, but I guess the way auth is handled is causing the issue, since the IP the server is assuming does not match. | 19:44 |
blast007 | for private IP ranges, bzfs doesn't do the IP check | 19:44 |
OkinaMatara | Ah, my bad than. | 19:45 |
Agatha | "can other players connect" <- not sure, blast007. It's up right now if someone wants to try it. | 19:45 |
Agatha | 5154 | 19:46 |
OkinaMatara | I can't connect it seems. | 19:46 |
OkinaMatara | Is the domain set to the proper IP? | 19:47 |
Agatha | Should be. I just refreshed it just in case. | 19:48 |
SpringTank | what address, doesn't look like it's showing up on the list server | 19:49 |
blast007 | doesn't look like you have the port forwarded correctly | 19:49 |
blast007 | SpringTank: it won't be listed since they have '-advertise NONE' | 19:49 |
SpringTank | right, i see that now | 19:49 |
blast007 | Agatha: if you want to limit it to just the server list IPs, you can forward the port just for 144.217.83.100 and 158.69.0.41 | 19:50 |
blast007 | that way it can work with the server list and global auth, but nobody else would be able to get to it | 19:51 |
blast007 | oh, and are you running it on port 5154? if you're using a non-standard port, you have to include that in the -publicaddr | 19:51 |
blast007 | looks forwarded now and looks like you were able to auth | 19:53 |
Agatha | Not sure I understand. I just set up a port forward for 5154–5155, and restarted. That seemed to fix the authentication issue, but IDK why. | 19:53 |
blast007 | the list server attempts to connect back to your server. if that fails, it doesn't add it. | 19:54 |
blast007 | if the server isn't in the list server database, auth requests will fail. | 19:54 |
Agatha | Okay great; I think I understand. Thanks! | 19:56 |
Agatha | I've made a note of this for the future, too, so I don't forget. | 19:56 |
*** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has quit IRC (Remote host closed the connection) | 19:59 | |
*** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has joined #bzflag | 19:59 | |
Agatha | Okay, so, after much experimentation, I have empirically found that the distance a laser will go for a given `<vector>` is exactly `<vector's length>*_laserAdVel*_shotSpeed*0.35`. Anyone know what the 0.35 constant is? | 20:05 |
blast007 | the shot lifetime of the laser | 20:18 |
blast007 | 350 / 100 * 0.1 | 20:18 |
blast007 | the laser lifetime is calculated as _shotRange / _shotSpeed * _laserAdLife | 20:19 |
Agatha | That looks like it's in the right direction, but it seems that's not quite it. | 20:30 |
Agatha | The default _laserAdVel=1000, _shotSpeed=100, _shotRange=350 would give us 3500 or 0.0035 (depending on precedence), whereas the actual answer is 35000. | 20:30 |
Agatha | Also testing changing _shotRange, the laser's length is not affected. | 20:30 |
Agatha | No other ideas? I feel like it should be related; there's nothing else of the form 3.5*10^x by default besides the tank explosion size, which is clearly unrelated. | 21:09 |
Agatha | Another issue: After `-set _shotSpeed <value>` in the config file, stuff is messed up. Running `/reset _reloadTime` fixes it. However, it's not reasonable to do this each time the server is started. What should I be doing instead? | 21:10 |
*** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 21:36 | |
*** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has quit IRC (Ping timeout: 272 seconds) | 21:39 | |
blast007 | Agatha: _lastAdLife, not _laserAdVel | 22:57 |
blast007 | and it looks like a rejoin is necessary for a change to _shotRange to take effect | 23:02 |
blast007 | actually, it's probably that _reloadTime, which uses _shotRange, isn't being recalculated when you update _shotRange | 23:06 |
blast007 | the shot lifetime defaults to the value of _reloadTime, and is then multiplied by _laserAdLife. _reloadTime is _shotRange / _shotSpeed. | 23:07 |
Agatha | Ugh apparently I can't read. Yes; I understand what you were saying now. So, all in all: | 23:30 |
Agatha | <laser length> = <vector's length> * _laserAdVel * _shotSpeed * <laser shot lifetime> | 23:30 |
Agatha | <laser shot lifetime> = (_shotRange / _shotSpeed) * _laserAdLife | 23:30 |
Agatha | Therefore to make <laser length> = <vector's length>, some algebra says we must scale the vector by: | 23:30 |
Agatha | _shotSpeed / ( _shotSpeed * _shotRange * _laserAdVel * _laserAdLife ) | 23:30 |
Agatha | I have confirmed that this is accurate and have updated my code. Thanks blast007! | 23:30 |
Agatha | And yes, calling "/reset _reloadTime" is necessary to get the thing to work. The question above was (and is): this is still true even if _shotSpeed, etc. are set in the config file; how can I make it so that _reloadTime is updated even then (without running it manually)? | 23:30 |
*** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Quit) | 23:44 | |
SpringTank | find the function that _reloadTime calls and call it in your plugin. | 23:55 |
Agatha | Ew. I mean, I guess I could try that, but this is a problem that occurs with any server—even without plugins. Soooo | 23:57 |
blast007 | plus you don't call non-API functions from a plugin | 23:58 |
SpringTank | yeah, it's a strange bug it seems. hmmmm: write a script that auto starts a bzflag client that connects to the server on server start that auto runs _reloadTime | 23:58 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!