| 00:20.56 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:20.56 | *** 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:20.56 | *** mode/#bzflag [+v infobot] by ChanServ |
| 02:15.43 | *** mode/#bzflag [-v short_circuit] by ChanServ |
| 07:45.25 | *** join/#bzflag ruskie (~ruskie@sourcemage/mage/ruskie) |
| 12:02.50 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 12:02.50 | *** mode/#bzflag [+v spldart] by ChanServ |
| 12:37.14 | *** join/#bzflag gartral (~gartral@unaffiliated/gartral) |
| 16:49.56 | JeffM | blast007: do you have an answer to my questions about GM locking? |
| 16:50.38 | blast007 | regarding what happens when the flag drops? |
| 16:50.57 | JeffM | it's more general than that |
| 16:51.11 | JeffM | can a tank with out the flag change the lock status of shots that are active? |
| 16:51.37 | JeffM | basicly is locking a property of the tank, or the flag |
| 16:52.02 | JeffM | droping the flag is just one possible case (in 2.5) |
| 16:52.19 | JeffM | I'm working on the ability for the server to fire GMs for a player |
| 16:52.30 | JeffM | so should the player without the flag be able to lock THOSE gms? |
| 16:58.52 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-iwkenkyhjmcsjnor) |
| 16:58.52 | BZnotify | [13bzflag] 15JeffM2501 pushed 1 new commit to 06master: 02https://git.io/vhuy7 |
| 16:58.52 | BZnotify | 13bzflag/06master 141bbfb8d 15Jeffery Myers: add missing copyright headers |
| 16:58.52 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-iwkenkyhjmcsjnor) |
| 17:01.53 | *** join/#bzflag Juesto (~AndC@190.194.204.95) |
| 17:01.55 | Juesto | hey |
| 17:02.01 | JeffM | hello |
| 17:02.14 | Juesto | does mac version ignore custom additions to data? |
| 17:02.23 | JeffM | what does that mean? |
| 17:02.27 | Juesto | apparently it is |
| 17:02.30 | JeffM | you mean stuff in the data dir? |
| 17:02.42 | Juesto | yes, which is in Resources on mac |
| 17:02.54 | JeffM | its inside the app bundle |
| 17:03.04 | JeffM | it should read whatever's in the app bundle |
| 17:03.06 | JeffM | IIRC |
| 17:03.08 | Juesto | I've set my font and it's not being picked up |
| 17:03.27 | JeffM | I recall it being wierd |
| 17:03.51 | Juesto | like, sticking to the data stuff it been compiled with? |
| 17:04.04 | JeffM | no, it just looks in odd places if I rmember correctly |
| 17:04.09 | JeffM | there are ways to get it override |
| 17:04.15 | Juesto | it's Resources |
| 17:04.15 | JeffM | but since it's all bunled it's wierd |
| 17:04.19 | Juesto | but where else |
| 17:04.25 | JeffM | is that the folder inside the .app ? |
| 17:04.37 | Juesto | yes, Contents/Resources |
| 17:05.08 | JeffM | if you physucaly replaced the file, but is still showing the old one, it has to be reading it from somewhere else |
| 17:05.12 | JeffM | or did you add a new file? |
| 17:05.23 | Juesto | i added something |
| 17:05.39 | JeffM | and did you change the font texture name in your config? |
| 17:05.57 | Juesto | yeah, I'm using my own config |
| 17:06.10 | JeffM | probalby have to ask macsforme then |
| 17:06.20 | Juesto | okay... |
| 17:06.22 | JeffM | I recall there being something spcial about it, but I can't remember what. |
| 17:06.45 | Juesto | _CodeSignature/CodeResources maybe? |
| 17:06.56 | JeffM | I don't recall |
| 17:07.10 | Juesto | oh well |
| 17:07.51 | JeffM | blast007: is 65,535 shots per max shot lifetime + max client lag enough? |
| 17:08.39 | JeffM | or 4294967295 ? |
| 17:08.49 | Juesto | that's 64 bits? |
| 17:08.53 | JeffM | 32 |
| 17:09.08 | Juesto | 32 is 20147something |
| 17:09.17 | JeffM | umm no |
| 17:09.22 | JeffM | it's 4.2 million |
| 17:09.28 | JeffM | 2 to the 32nd |
| 17:10.07 | Juesto | oh okay |
| 17:10.49 | JeffM | I have no idea what bitness would be around 20k |
| 17:11.23 | JeffM | 14bit is 16k, and 15 bit is 32k |
| 17:12.52 | JeffM | long long just seems silly for shot IDs |
| 17:13.07 | JeffM | UInt16 should be fine |
| 17:14.58 | JeffM | also is 255 shots per player per lag time acceptable? |
| 17:15.36 | JeffM | those limits make it so I only have to add a single byte to FIringInfo |
| 17:15.58 | blast007 | what is the current behavior? when you die, does the lock go away? if you drop the flag (or the server takes your flag, or you run out of shots on a limited flag), does the lock go away? |
| 17:16.11 | blast007 | I think at least for the dropped flag, existing ones will still be locked |
| 17:16.19 | JeffM | currently when you die or if you drop the flag the lock goes away |
| 17:16.25 | JeffM | BUT you can relock |
| 17:16.29 | JeffM | without the flag |
| 17:16.36 | blast007 | really? |
| 17:16.37 | JeffM | so after the drop, you can relock |
| 17:16.39 | JeffM | yeah |
| 17:16.54 | JeffM | the issue on github says the lock loss on drop is a bug |
| 17:17.01 | JeffM | but I think it's not well defined. |
| 17:17.11 | JeffM | hence why I need a specification |
| 17:18.17 | JeffM | from BulletCatcher "Pro tip: after the GM lock is lost due to this bug, you can right-click or press "i" to lock the shot again." |
| 17:18.48 | JeffM | as I see it there are 3 options. |
| 17:18.53 | JeffM | 1) leave it as is, it's not a bug |
| 17:19.04 | JeffM | 2) don't loose the lock on drop, and still let people relock. |
| 17:19.16 | JeffM | 3) don't loose the lock on drop, but also don't let people relock. |
| 17:19.17 | blast007 | so one of two ways to go: 1) holding the GM flag is required to set/alter the target lock, but death/drop does not clear the lock (the missiles hold their target) 2) holding the GM flag is required to set/alter the target lock, but death/drop DOES clear the lock |
| 17:19.27 | blast007 | I don't think you should be able to alter the lock without holding the flag |
| 17:19.33 | JeffM | nor do I |
| 17:19.44 | JeffM | to me the flag is the locking equipment |
| 17:19.52 | blast007 | that's probably just due to reused logic for the 'identify tank' feature |
| 17:19.58 | JeffM | yeah |
| 17:20.24 | JeffM | I do think a shot should stay locked after you die, last command to the missile, etc.. |
| 17:20.29 | blast007 | I'm leaning towards the second of my options |
| 17:20.46 | JeffM | so the tank with the flag is activly steering the shot? |
| 17:20.55 | JeffM | thus no flag, no steering commands to missile? |
| 17:20.58 | blast007 | yeah |
| 17:21.09 | JeffM | shoudl the tank have to maintain line of sight to the target? :) |
| 17:21.13 | blast007 | flag drops or tank dies, missile just then goes in a straight line |
| 17:21.32 | JeffM | how can the tank equipment steer to a target it can't see? |
| 17:21.48 | JeffM | video feed from the missle? |
| 17:21.56 | blast007 | it uses the godview radar |
| 17:21.59 | blast007 | :P |
| 17:22.08 | JeffM | so it's a divine missile |
| 17:22.14 | JeffM | why does it need the tank then? :) |
| 17:22.21 | JeffM | that's an acceptable specification. |
| 17:22.29 | JeffM | so the bug is, allowing relock. |
| 17:22.44 | JeffM | I will change the bug and see who comments. |
| 17:22.52 | blast007 | allowing relock, and the last GM from a shot limited flag not having a lock |
| 17:23.54 | blast007 | er, nvm, actually, the last part isn't an issue :) |
| 17:24.11 | blast007 | (since all missiles won't have a lock after the flag drops) |
| 17:24.34 | blast007 | we can play test that a bit and see how it feels |
| 17:26.16 | blast007 | I started working on replacing our audio code with OpenAL |
| 17:27.19 | spldart | ooOOoo... Listening to your few silly comments in the middle of your serious development. How about GM be fly by wire. One at a time and you have to steer to target by wire ;) |
| 17:28.27 | blast007 | spldart: for a barfy experience, /localset _trackShots 1 |
| 17:28.29 | spldart | Well. Not exactly that. You don't steer but your window view localizes to target and you keep the pipper on him till missle hits. Half way through flight you could conceivably change targetr ;) |
| 17:28.52 | spldart | I'll shaddup now XD |
| 17:28.59 | blast007 | (and then fire a GM after setting that) |
| 17:29.00 | JeffM | spldart: that was a feature of BZ not BZFlag |
| 17:29.15 | blast007 | sorry, trackShots, not _trackShots |
| 17:29.19 | spldart | Was it? |
| 17:29.25 | blast007 | http://bzexcess.com/2009/03/bztips-2-client-side-variables/ |
| 17:29.44 | JeffM | blast007: with the changes i'm making looksing the lock will be a server side event, if you want to change it and have it say locked on the last target, that will be a server only change. |
| 17:29.51 | JeffM | so it's totaly playtestable |
| 17:30.06 | JeffM | could even have it toggleable via a testing plugin |
| 17:30.40 | JeffM | all clients will do for GM is say "get that guy", and the server will accept or ignore the request. |
| 17:30.57 | blast007 | cool |
| 17:31.14 | JeffM | GM should be the first server side shot. |
| 17:31.37 | blast007 | will the server be driving the shot, or is that still client-side calculation? |
| 17:31.47 | JeffM | the server will be doing the driving |
| 17:31.58 | JeffM | shot manager now has all the stuff it needs |
| 17:32.25 | JeffM | the death will be client side still, but the shot updates will only come from the server |
| 17:32.27 | blast007 | and we have enough obstacle knowledge on the server to know when it hit something? |
| 17:32.33 | JeffM | yes |
| 17:32.41 | blast007 | :D |
| 17:32.42 | spldart | realy/? |
| 17:32.45 | JeffM | that's part of what I added with the last update to shot manager |
| 17:32.46 | spldart | excellent |
| 17:33.03 | spldart | So the servers has a map in it's head? |
| 17:33.03 | JeffM | I've got it doing ricos on regular shots, it's just ignoring the results |
| 17:33.12 | JeffM | yeah, it's how it does spawns |
| 17:33.29 | blast007 | that'll be great. cuz MsgShotEnd was UDP, so in some cases, with packet loss, you could end up having a GM that would never end (until it hit something or the shot slot was overwritten) |
| 17:33.58 | blast007 | that can get rid of our hacky end-shot credit stuff too |
| 17:34.00 | JeffM | yeah clients are already used to getting GM updates, so I figure it's a good one to start with |
| 17:34.12 | JeffM | and the pathing is relativly simplistic and not pre-determined |
| 17:34.31 | JeffM | and it's already got lag in it |
| 17:35.13 | JeffM | it should be possible for all endshots to come from the server in 2.5 |
| 17:35.45 | JeffM | all the shots in shot factory have path generation and update methods now. |
| 17:36.00 | JeffM | and ProjectileShot computes segments in the same way the client does |
| 17:36.11 | JeffM | it just stores less data |
| 17:36.19 | JeffM | the client has a lot of drawing stuff mixed in |
| 17:36.53 | JeffM | but yeah, there are now server side versions of getFirstBuilding and getFirstTeleporter |
| 17:37.48 | blast007 | spldart: oh, I forgot, '/localshot trackShots 1' is observer mode only. but if someone you are driving with fires a GM, the camera will follow the GM, iirc. |
| 17:38.37 | spldart | This is fascinating cuz I can follow a lot better than I could years ago ;) |
| 17:43.21 | JeffM | ok, next shot question. |
| 17:43.50 | JeffM | currently the shot reload and shot lifetime are inherently linked. |
| 17:44.20 | JeffM | if a tank has 3 shot slots, there is no combination of reload and lifetime that will allow more than 3 shots in the world at a time. |
| 17:44.35 | JeffM | there is no physical storage on a client for more than 3 shots. |
| 17:44.42 | JeffM | since the shots are reused. |
| 17:44.49 | JeffM | I'm changing that |
| 17:45.04 | JeffM | once a shot is fired, it's taken over by the server and given a global shot ID |
| 17:45.28 | JeffM | it's still attributed to the player for hit/scoring reasons, but it's not directly attached to the player object on the client. |
| 17:46.04 | JeffM | I'm going to leave the bzdb defaults the same, so the main result will be that it will still LOOK like a tank can only have 3 shots on screen at a time, but the system won't be hard-bound to that rule |
| 17:46.34 | JeffM | this way custom flags can do things like tripple shot, and actualy create shots for the player, instead of creating world weapon shots and having to do manual score adjustment. |
| 17:46.43 | blast007 | people do mess around with the reload and lifetime variables, though |
| 17:47.02 | JeffM | yeah and they run into issues now where the behavor is wierd, and shots just disaapear |
| 17:47.02 | blast007 | (sometimes in horribly broken ways) |
| 17:47.09 | blast007 | yeah :) |
| 17:47.18 | JeffM | yeah this would prevent that brokenness |
| 17:47.35 | JeffM | there would be a global limit of 64k shots at at a time |
| 17:47.38 | JeffM | form all sources. |
| 17:48.00 | JeffM | so the question is, is that ok :) |
| 17:48.37 | blast007 | let's just limit it to 8. that'll be much better for the audio system. ;) |
| 17:49.02 | JeffM | dude, you are going to have to make a priority system no matter what |
| 17:49.09 | JeffM | I can help you with that when the time comes. |
| 17:49.10 | blast007 | yeah |
| 17:49.23 | JeffM | just give all the shots weights |
| 17:49.42 | JeffM | and build a weighted graph based on distance. |
| 17:50.03 | blast007 | plan was for a priority system, and possibly having an extra source or two so that I can play the new sound, and quickly fade out a lower priority source so that I can then assign *that* source as a spare |
| 17:50.24 | blast007 | (trying to avoid hard cuts) |
| 17:51.48 | JeffM | sure, I'd have 2 pritority lists, one for positionals, and one for "ui" sounds. |
| 17:52.04 | JeffM | for the positionals, you'd always cut out the far ones, so they'd be low anyway |
| 17:52.25 | JeffM | for the UI sounds, there arn't that many and you can probalby come up with a fixed pritority list |
| 17:52.32 | JeffM | like GM lock overrides chat blip |
| 17:53.12 | JeffM | but is 64k shots ok? |
| 17:53.18 | blast007 | yeah |
| 17:53.30 | JeffM | full 32bit seems overkill |
| 17:53.31 | JeffM | ok |
| 17:53.35 | blast007 | 64K should be enough for anyone |
| 17:54.00 | JeffM | so the idea is that all shot paths get allocated as shared_ptrs |
| 17:54.03 | JeffM | and there are 2 lists |
| 17:54.14 | JeffM | the global list and local player's local list |
| 17:54.32 | JeffM | when a shot is fired, it's allocated a local shot ID (based on the old shot slot logic). |
| 17:54.49 | JeffM | the shot is sent up, server gives it a global ID, and then it's sent back out to all players. |
| 17:55.28 | JeffM | when the player gets back his shot it still has his local shot ID attached to it, so the shot gets pulled out of the local shot list, and put into the global shot list with it's new GUID. |
| 17:55.54 | JeffM | means the client does have to scan 2 lists for shots hits and drawing, but one is small. |
| 17:56.12 | JeffM | or I could add them to the global shot list with negiative IDs or something |
| 17:56.28 | JeffM | that'd limit it to 32k shots at a time. |
| 17:56.44 | blast007 | the first option sounds fine |
| 17:57.03 | blast007 | though even 32K is more than enough |
| 17:57.16 | JeffM | so then if the server sends out additional shots attributed to the player, they just get shoved into the global shot list, and processed like the rest of the shots |
| 17:57.26 | JeffM | they just don't have local IDs, so that part is skipped |
| 18:00.38 | JeffM | it also means that we could send all lifetime info to the client as part of the shot |
| 18:01.10 | JeffM | and regarding shot limits, after this is done, I want to add a message to tell the client how many shots it has left, as a countdown. |
| 18:01.40 | JeffM | and if they send a shot after the server knows they don't have the flag, it can just be ended and sent back to just the local player |
| 18:02.09 | JeffM | for non cheaters, the client will respect the shot limit and drop the flag when it's up. |
| 18:02.47 | blast007 | and for cheaters, they'll get their pants pulled down and be spanked with moon rocks? :) |
| 18:03.03 | JeffM | once the server can aim it's own GMs, yes :) |
| 18:03.11 | blast007 | hehe |
| 18:03.19 | JeffM | want me to put a big H shaped spaceship infront of the moon? |
| 18:04.16 | spldart | Cyberdyne here we come |
| 18:04.29 | JeffM | more like pandora |
| 18:04.51 | blast007 | unclear which ship that would be |
| 18:06.32 | spldart | Funny. Now I have a request pop to my mind from many years ago. Someone asked for music to be part of a world file or some such. Not asking for it. Just remembered the request. |
| 18:06.34 | JeffM | borderlands 2 |
| 18:07.01 | spldart | I guess it was the pandora comment ;) |
| 18:07.09 | JeffM | and the H shaped ship |
| 18:07.13 | spldart | yes |
| 18:08.20 | spldart | Though original Duke3D theme music would be awesome in a map designed my LouMan in the spirit of .... I digress XD |
| 18:09.41 | blast007 | spldart: heh.. I recall I did some mod to the source one to allow playing a music loop... |
| 18:09.47 | blast007 | once* |
| 18:09.59 | spldart | 8) |
| 18:10.34 | spldart | */me has stupid Duke it out in DC theme goin in his head* :( |
| 18:10.42 | JeffM | hook up a mod tracker |
| 18:11.00 | spldart | :)( |
| 18:11.11 | allejo | Juesto: replacing stuff in the resources folder on macOS works just fine |
| 18:11.28 | allejo | fonts, you have to build with TextTool which is in the repo somewhere |
| 18:11.33 | blast007 | alure already provides that :) |
| 18:11.41 | blast007 | (via libdumb) |
| 18:11.55 | blast007 | or I guess it's just 'dumb' |
| 18:12.56 | JeffM | oh yeah, I didn't even think to ask that, Juesto you didn't just try to dump a TTF in there or anything did you? |
| 18:13.09 | allejo | and Juesto, the signature folder is what tells macOS that BZFlag is an app compiled by a real life professional developer! |
| 18:13.35 | blast007 | if we did want to use this, given that it hasn't had a release yet, is that going to complicate things? do we care about being packaged by Linux distributions for 2.6? https://github.com/kcat/alure |
| 18:14.54 | blast007 | I guess it has had releases, they just don't tag the repo |
| 18:14.55 | blast007 | http://kcat.strangesoft.net/alure.html |
| 18:15.11 | allejo | if we're gonna look at flatpaks or snaps or whatever they're called, we'd be handling those dependencies anyways, wouldn't we? |
| 18:15.23 | allejo | s/handling/bundling/ |
| 18:15.23 | blast007 | flatpaks, snaps, and possible appimage |
| 18:15.28 | blast007 | yes |
| 18:15.50 | blast007 | alure is packaged by debian |
| 18:15.58 | JeffM | I really don't thing package managers can properly support games, so those other systems are much more preferable. |
| 18:16.16 | blast007 | multiplayer online games* |
| 18:16.17 | JeffM | package managers just don't have the base concepts games need. |
| 18:16.19 | JeffM | yeah |
| 18:16.26 | JeffM | online |
| 18:16.40 | JeffM | you are fine running your old version of tux racer ;) |
| 18:16.43 | Juesto | allejo, well not working, I'm using the old fmts |
| 18:17.09 | JeffM | you added the image and the fmt file? |
| 18:17.09 | Juesto | JeffM: ^ |
| 18:17.23 | Juesto | Yeah, should i remove the png? |
| 18:17.29 | JeffM | no no, it needs both |
| 18:17.33 | Juesto | which is the source anyway (?) |
| 18:17.37 | JeffM | both |
| 18:17.40 | Juesto | both are there |
| 18:17.52 | allejo | i don't think being limited to distro package managers should be a thing for 2.6 since we're exploring different distribution methods |
| 18:17.53 | JeffM | the png is the image data, the fmt is the font offset and kerning data |
| 18:18.05 | JeffM | it loads both files |
| 18:18.05 | blast007 | allejo: k |
| 18:18.16 | Juesto | it's working on Linux just fine |
| 18:18.20 | Juesto | just not on mac |
| 18:18.22 | JeffM | apple hates games |
| 18:18.31 | blast007 | apple deprecated additional fonts |
| 18:18.31 | Juesto | ehh |
| 18:18.40 | JeffM | courage |
| 18:18.54 | blast007 | you're probably holding it wrong |
| 18:19.18 | allejo | rotate it 90 degrees and use compressed air in a zig zag motion |
| 18:19.41 | blast007 | to upgrade your fonts, you'll have to buy a new copy |
| 18:19.42 | JeffM | macsforme can probalby help you dubug it, he's most often on in the evnenings |
| 18:19.59 | blast007 | all our fonts are soldered in |
| 18:20.05 | Juesto | okay, us evening you mean? |
| 18:20.18 | allejo | i've used custom fonts on macOS before just fine. I just had to build it with TextTool and load it manually in the config file |
| 18:20.18 | JeffM | yeah, he's in the US in arizona |
| 18:20.26 | Juesto | alright |
| 18:20.41 | JeffM | or at least I think hes still in AZ |
| 18:21.02 | Juesto | Allejo: it's the old copyrighted fonts this project had |
| 18:21.10 | blast007 | profont? |
| 18:21.21 | Juesto | luxi, toga, profont |
| 18:21.24 | Juesto | yeah |
| 18:21.29 | Juesto | and vera |
| 18:21.45 | allejo | are you just dropping in old files or did you build the fonts again with TextTool? |
| 18:22.01 | Juesto | on that note, when there'll be a font selector in gui |
| 18:22.07 | JeffM | if it's got PNG and fmt it should be in the right format. |
| 18:22.21 | Juesto | allejo: old font straight away |
| 18:22.40 | Juesto | JeffM: the font stuff slightly changed but it shouldn't do any difference |
| 18:22.47 | JeffM | if distros are no longer a thing, the distro rules don't apply and more fonts can be used |
| 18:23.49 | JeffM | hmmm why did I not version the fmt files? |
| 18:26.28 | blast007 | ProFont is MIT now anyway |
| 18:33.28 | Juesto | :D |
| 18:34.10 | Juesto | so.. |
| 18:34.22 | Juesto | I'm compiling bz on mac |
| 18:40.31 | Juesto | allejo: texttool? |
| 18:40.53 | JeffM | it turns TTFs into PNG/FMT pairs |
| 18:43.08 | blast007 | Juesto: in the tools/TextTool2/ directory of our source |
| 18:47.16 | Juesto | thanks |
| 18:47.41 | Juesto | are the original ttfs in the sources? |
| 18:48.34 | Juesto | there should be dependency facilitation for mac users |
| 18:49.26 | *** join/#bzflag I_Died_Once_ (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 18:49.35 | blast007 | "dependency facilitation" ? |
| 18:49.57 | blast007 | and does your operating system lack a search function? |
| 18:51.05 | tupone | is the astyle command line in DEVINFO 2.4 supposed to be good ? |
| 18:51.37 | blast007 | 'good' as in working? |
| 18:52.12 | tupone | I applied to FlagSceneNode.h where I only removed a line, and it generate a complete different files |
| 18:52.23 | tupone | with diff -w is the same |
| 18:52.39 | tupone | it should stay the same, I imagine |
| 18:52.46 | *** join/#bzflag kierra (~quassel@00.alucard.sujevo.io) |
| 19:03.45 | blast007 | tupone: I ran it here on that file and it didn't change |
| 19:04.15 | blast007 | though I think the file wildcard at the end doesn't work |
| 19:11.58 | tupone | I did with one file only and it change. Maybe the astyle version? |
| 19:12.16 | tupone | 3.0.1 |
| 19:13.06 | tupone | astyle --style=allman -nxjz1 --convert-tabs --max-code-length=120 include/FlagSceneNode.h |
| 19:14.11 | tupone | with CRLF line terminators :) |
| 19:14.30 | tupone | the command is for windows |
| 19:19.13 | tupone | should be -nxjz2 for linux |
| 19:23.11 | blast007 | ah, yeah, the z1 isn't necessary |
| 19:23.26 | blast007 | I was running it from Windows initially so I wasn't seeing a problem :) |
| 19:23.53 | JeffM | Yeah that isnât needed all the time, it was just a onetime fix to get them all the same |
| 19:26.30 | blast007 | think we also need to run it on the plugins yet |
| 19:26.42 | blast007 | I'll mess with it a bit later |
| 19:29.00 | *** part/#bzflag Guest28482 (~quassel@00.alucard.sujevo.io) |
| 19:31.45 | *** join/#bzflag moriah (~quassel@unaffiliated/kierra) |
| 19:32.09 | JeffM | I ran it on my entire tree when I did the inital PR |
| 19:32.23 | JeffM | so it should have the plugins |
| 19:32.39 | blast007 | plugins use .cpp not .cxx |
| 19:32.46 | JeffM | ohhhhh |
| 19:32.56 | JeffM | we should commonize all that |
| 19:32.56 | blast007 | for some reason |
| 19:32.59 | blast007 | yeah |
| 19:33.08 | JeffM | that's my bad, the default in VC is CPP |
| 19:33.15 | blast007 | ah |
| 19:33.18 | JeffM | what one do you like? |
| 19:33.39 | JeffM | and how jacked up will history get if we change file names? |
| 19:33.49 | blast007 | renames shouldn't be a problem |
| 19:34.07 | JeffM | cpp seems more common to me |
| 19:34.26 | blast007 | at least as long as we're renaming, commiting, and THEN doing any major changes (including whitespace) |
| 19:34.44 | JeffM | yeah I'd do the rename as it's own commit |
| 19:34.59 | blast007 | there's a 'git mv' command |
| 19:35.07 | JeffM | cool |
| 19:35.20 | blast007 | dunno if it can do any wildcard magic |
| 19:35.39 | JeffM | worst case a script could do it |
| 19:35.45 | blast007 | yup |
| 19:35.55 | JeffM | will it hose branches people have? |
| 19:36.15 | blast007 | I'd be more inclined to just change the plugins to match the rest of the stuff |
| 19:36.33 | JeffM | yeah that's what I'm thinking, less likelyhood of conflicts with outstanding work |
| 19:37.18 | blast007 | (in 2.99.x we went the opposite direction though) :) |
| 19:37.48 | blast007 | and we all know how 2.99.x turned out!</sarcasm> (oh who am I kidding.. the sarcasm never ends with me) ;) |
| 19:38.33 | Juesto | why use cxx |
| 19:39.29 | JeffM | because bzflag is old and C++ was new when it was made |
| 19:39.40 | JeffM | and that's what the SGI compiler used |
| 19:42.18 | blast007 | that can really just wait for now though |
| 19:43.27 | blast007 | maybe someone that knows more about git can chime in on how much changing it all to .cpp will break things |
| 19:44.09 | JeffM | nominates BulletCatcher |
| 19:56.42 | JeffM | uses all the algorithms! |
| 19:57.12 | JeffM | so much easier with linq |
| 20:23.50 | JeffM | bleh.. the reload time is dependent on there being empty slots... |
| 20:25.12 | *** join/#bzflag TheAmazingGerman (5b6d14da@gateway/web/freenode/ip.91.109.20.218) |
| 20:26.01 | TheAmazingGerman | Hey my niggas, i am back, and now i am gonna ddos bzflag 24/7 till you unban me and let me play on planet mofo |
| 20:26.06 | TheAmazingGerman | :) |
| 20:26.26 | TheAmazingGerman | bye |
| 20:26.28 | *** mode/#bzflag [+o JeffM] by ChanServ |
| 20:28.16 | *** mode/#bzflag [+o blast007] by ChanServ |
| 20:33.27 | Juesto | wtf |
| 20:34.20 | JeffM | just an idiot |
| 20:34.25 | *** mode/#bzflag [+b *!*@*/91.109.20.218] by blast007 |
| 20:34.45 | *** mode/#bzflag [-o blast007] by blast007 |
| 20:34.59 | blast007 | wonder if he's going to stop the DDoS for any leap seconds/microseconds |
| 20:37.05 | JeffM | oh man, robots and autopilot just copied code. |
| 20:37.29 | JeffM | they both have findWorstBullet |
| 20:37.46 | blast007 | the worst bullet is the one inside of you |
| 20:38.14 | JeffM | well at least now it's a smart pointer and will get rid of itself :) |
| 20:55.57 | spldart | :( I fell asleep at the wheel and missed the fun :( |
| 21:04.03 | spldart | Late o clock where he's at. |
| 21:26.08 | JeffM | anyone know what the bzdb var "_lRAdRate" does? |
| 21:26.23 | JeffM | it doesn't seem to be used, but it matches stuff like "_laserAdRate" |
| 21:26.39 | JeffM | was there a long range flag once? |
| 21:28.01 | spldart | long reload? I dunno |
| 21:33.10 | blast007 | no idea what _lRAdRate should be for |
| 21:33.15 | JeffM | I'll remove it |
| 21:33.21 | blast007 | https://github.com/BZFlag-Dev/bzflag/commit/69e36b868530c092266e2371728f55f056d2d289 it was added here |
| 21:33.39 | JeffM | nothiung calls it |
| 21:34.16 | JeffM | so it's as old as the db |
| 21:35.11 | JeffM | ok, so I see that there will be a gameplay change with what I'm doing, but to me it makes sense. |
| 21:35.16 | JeffM | lets say I have 5 shots |
| 21:35.33 | JeffM | I have the laser and I fire one shot |
| 21:35.40 | JeffM | then I drop the flag and pick up MG |
| 21:36.07 | JeffM | with the old code, I could quickly fire 4 MG shots, but I could not fire the 5th until the laser slot's reload timer was up. |
| 21:36.50 | JeffM | if the reload for laser was long enough, I could cycle through several sets of 4 MG shot rounds before that 5th slot was free. |
| 21:37.05 | JeffM | with my change, all your slots reload based on your current flag. |
| 21:37.11 | JeffM | so you'd get the 5th slot faster. |
| 21:38.00 | JeffM | the opposite could be true as well, if I had MG, fired 4 shots, then picked up laser, in the old code, I'd get 5 super fast laster shots because 4 of the slots would reset at MG times, but fire lasers |
| 21:38.10 | JeffM | now they'd all reload at laser speed. |
| 21:38.49 | JeffM | I can emulate the old behavor if you want, I can keep a slot record with it's reload times. |
| 21:39.15 | JeffM | well actualy I can only do that for local players, not observed remotes |
| 21:39.36 | JeffM | observed remotes ENTIRELY use the shots in the field to compute the reload times in the HUD |
| 21:42.40 | blast007 | don't we also make you reload all your shots when you drop the theif flag? |
| 21:42.52 | JeffM | probably |
| 21:42.55 | spldart | If you drop a weapon and pick up another should the limits of one or the other apply? Wouldn't it be the World designers issue to keep people from having clusters of superflags right next to each other keeping players from dominating by simply drop, pickup, drop, pikkup? |
| 21:43.14 | JeffM | you tell me how you want it to work :) |
| 21:43.46 | spldart | Meh... I'm just thinking out keyboard. |
| 21:43.49 | JeffM | how imporant is it to you that observers be able to see the reload timers of other players? |
| 21:44.16 | blast007 | I think the problem with not emulating the old behavior would be if there is a spawn area for, say, laser flags that has 10 flags there. you could sit there, grab a laser, fire them all off, drop the flag, reload at normal speed, grab another flag, repeat |
| 21:44.24 | spldart | The server operator might consider that very important |
| 21:44.37 | spldart | Regular observers don't need to |
| 21:44.44 | JeffM | I can emulate the old behavor for localplayers |
| 21:45.07 | blast007 | I'm not clear why it would behave differently for remote players |
| 21:45.14 | JeffM | I can make each slot keep a timer for the last shot it fired. |
| 21:45.29 | JeffM | because for remote players I don't know what shots came from slots |
| 21:45.44 | JeffM | in the case where the map added a shot for them |
| 21:46.08 | JeffM | I guess I could use the localShot ID and set generated shots to 255 |
| 21:46.11 | blast007 | oh, so remote players you just know the global shot ID and the other attributes like shot type, position, velocity, vector? |
| 21:46.19 | JeffM | that was the plan |
| 21:46.28 | JeffM | I do send the local shotID, aka slot number. |
| 21:46.31 | JeffM | so I could use that |
| 21:46.39 | blast007 | (oh, and shot owner, I supposed) |
| 21:46.48 | JeffM | yeah, team color, all the normal stuff |
| 21:47.00 | JeffM | the shot ID was already a short |
| 21:47.08 | JeffM | even though we'd only ever fill it up to 255 |
| 21:47.10 | blast007 | oh, you send the local shotID too for remote players? |
| 21:47.18 | JeffM | yeah it's part of the firing info |
| 21:47.24 | JeffM | I don't strip it |
| 21:47.28 | blast007 | so then what is the point of the global shot ID? |
| 21:47.34 | JeffM | I have to send it back to the shooter so they can remap |
| 21:47.43 | JeffM | for shots that didn't come from slots |
| 21:47.47 | JeffM | like tripple shot |
| 21:47.59 | JeffM | the server can add inserted shots |
| 21:48.12 | blast007 | ah, so what would the local shot ID be for server-generated player-assigned shots? |
| 21:48.20 | JeffM | 255 |
| 21:48.24 | JeffM | so I can check that way |
| 21:48.34 | JeffM | that limits -ms to 128 ;) |
| 21:48.34 | blast007 | yeah, sounds like there's enough data |
| 21:48.39 | JeffM | I think it'll be fine :) |
| 21:53.52 | JeffM | do you ever expect -ms to be changed to something that will change while a game is active? |
| 21:54.35 | blast007 | no |
| 21:54.40 | blast007 | well.. hmm |
| 21:55.01 | blast007 | I could see it changing when a new *map* is loaded |
| 21:55.11 | JeffM | sure |
| 21:55.20 | JeffM | ok, I'll make it resettable |
| 21:55.22 | blast007 | I don't think it should change while everyone is playing |
| 21:55.31 | *** mode/#bzflag [-v Foo_man_choo] by ChanServ |
| 21:55.33 | blast007 | far too many ways that can break |
| 21:55.37 | Juesto | so bzf will have changelevels? |
| 21:55.37 | JeffM | right now it gets burned into an array when the player is created |
| 21:55.45 | JeffM | so that's at join |
| 21:55.50 | JeffM | Juesto: that's the plan |
| 22:06.54 | JeffM | I'm making a ShotSlot object that gets stored with Player, everytime a slot based shot gets fired, via remote or local, the slot is updated and starts a timer. |
| 22:07.11 | JeffM | should make the hud code cleaner too, it can just iterate the slot list |
| 22:32.02 | *** join/#bzflag kierra (~quassel@00.alucard.sujevo.io) |
| 22:39.29 | Delusional | seems like there is an attack on the listserver |
| 22:40.17 | Delusional | or Iâm wrong, and itâs mofo thatâs under attack |
| 22:41.20 | the_map | <PROTECTED> |
| 22:41.45 | JeffM | it's known |
| 22:41.47 | the_map | <PROTECTED> |
| 22:44.00 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:47.21 | *** join/#bzflag allejo (~allejo@bzflag/developer/allejo) |
| 22:47.21 | *** mode/#bzflag [+v allejo] by ChanServ |
| 22:54.14 | *** part/#bzflag Guest69566 (~quassel@00.alucard.sujevo.io) |
| 22:54.20 | *** join/#bzflag Guest69566 (~quassel@00.alucard.sujevo.io) |
| 22:54.22 | *** part/#bzflag Guest69566 (~quassel@00.alucard.sujevo.io) |
| 22:59.21 | *** join/#bzflag moriah (~quassel@unaffiliated/kierra) |
| 23:04.22 | JeffM | so tell me if this sounds like a stupid design, there is a class called ShotPath |
| 23:04.26 | JeffM | it has no base class |
| 23:04.39 | JeffM | it contains a pointer to a ShotStrategy |
| 23:05.03 | JeffM | shot strategy takes a ShotPath ptr in it's constuctor and keeps a pointer to the path |
| 23:05.10 | JeffM | they are friends of each other |
| 23:05.26 | JeffM | there are derived ShotStrategies for each shot type |
| 23:05.45 | JeffM | and a big switch in the ShotPath contrustor that attaches the right one to itself |
| 23:05.56 | JeffM | in a big circular dependency |
| 23:06.47 | JeffM | yet it'd be simple enough to make ShotStrategy derive from ShotPath and make a simple factory object that just created the right Derived ShotPath for the shot..... |
| 23:08.02 | JeffM | oh and the strategy has wraper functions that simply just remap to functions in the ShotPath.... |
| 23:39.24 | blast007 | mmmm, this alure lib looks pretty neat. you can set a callback when you play a sound that will trigger when that source is done playing |
| 23:57.05 | JeffM | yeah that's a common thing in audio engines |
| 23:57.10 | JeffM | soyou can recoup your buffers |
| 23:58.31 | blast007 | they also let you pass in a pointer when you start playing a sound that gets passed to the callback |