| 03:02.48 | *** join/#bzflag apeman (~Victor@222-155-41-238.jetstream.xtra.co.nz) |
| 03:15.14 | apeman | if you compile a plugin twice and rename them different .so files and try to -loadplugin both of them in bzfs, the second one won't load and triggers "glibc detected... double free or corruption". Why? |
| 03:20.21 | blast007 | because they're the same plugin and the internal structure names are the same |
| 03:21.13 | blast007 | why would you want the same plugin loaded twice? |
| 03:21.31 | *** join/#bzflag JeffM (~JeffM@cpe-23-241-222-73.socal.res.rr.com) |
| 03:22.55 | apeman | i wanted to test to answer this ignorant question: is it possible for two dynamic library files to share memory by using the same code |
| 03:24.12 | Flash | My guess (without checking) is that each plugin defines an entry point and by loading exactly the same .so twice you have conflicts in names. |
| 03:24.14 | JeffM | not by default |
| 03:24.34 | JeffM | you can pass pointers between them |
| 03:24.44 | blast007 | JeffM: his test was loading the same plugin twice with two different filenames |
| 03:24.56 | JeffM | k |
| 03:24.59 | JeffM | but still each load gets it's own news |
| 03:25.05 | blast007 | or at least, *trying* to do that - it barfed on the second one |
| 03:25.14 | JeffM | odd |
| 03:25.25 | blast007 | "glibc detected... double free or corruption" |
| 03:25.40 | JeffM | does he have globals? |
| 03:26.08 | JeffM | anything inside the plugin class should be linked to the object and you could have N number of those allocated |
| 03:26.24 | JeffM | but globals would be in the same namespace |
| 03:26.33 | JeffM | and that'd get wierd |
| 03:26.40 | apeman | i had an extern global but i never defined it anywhere |
| 03:26.50 | JeffM | did you use it? |
| 03:26.54 | apeman | no |
| 03:27.11 | JeffM | and is the goal to just share memory between 2 different plugins? |
| 03:28.16 | blast007 | would both plugins having the same class names also cause a conflict? |
| 03:28.25 | JeffM | probably |
| 03:28.33 | JeffM | since they are in the global namespace |
| 03:28.40 | apeman | Well the problem in context. When you have custom flag plugins that generate world weapon shots, you need to choose shot IDs to use. A single plugin is easy, just use shot ID 0 then 1 then 2 up to 255 then back to 0. But if you have two plugins not aware of each other, they might both choose 0 and so one shot overwrites the other. |
| 03:28.42 | blast007 | yeah, that was my initial thought as well |
| 03:28.42 | JeffM | I didn't design the system to work like that :) |
| 03:29.04 | JeffM | apeman, yeah the solution is to make the API allocate the shot IDs |
| 03:29.16 | JeffM | not for you to figure out :) |
| 03:29.28 | JeffM | didn't I do an inter-plugin messaging system? |
| 03:29.53 | blast007 | looks like it |
| 03:30.01 | JeffM | then make one plugin that just hands out IDs |
| 03:30.13 | JeffM | and keeps a map of what is allocated and when they die |
| 03:30.20 | JeffM | then make each other plugin ask that plugin for IDs |
| 03:32.42 | JeffM | yeah you can do that with the general callback |
| 03:32.47 | JeffM | since we are single threaded |
| 03:33.56 | JeffM | oh actualy there is an easy way |
| 03:34.02 | JeffM | pass in 0 for the shot ID for world weapon |
| 03:34.11 | JeffM | if ( realShotID == 0) |
| 03:34.11 | JeffM | <PROTECTED> |
| 03:34.22 | JeffM | then we just allocate a new one |
| 03:34.47 | JeffM | the plugins won't fight then |
| 03:34.53 | JeffM | since they all get auto allocated |
| 03:35.59 | apeman | how does one use virtual int GeneralCallback( const char* /*name*/, void* /*data*/) { return 0; } ? |
| 03:36.58 | apeman | oh right, with bz_getPlugin |
| 03:37.03 | JeffM | there should be a way to register a name |
| 03:37.15 | JeffM | yeah it's a member of your plugin class |
| 03:37.51 | JeffM | but really just pass in 0 for the shot ID |
| 03:37.51 | JeffM | do you need to get the ID back? |
| 03:37.51 | JeffM | to do tricky stuff? |
| 03:39.20 | apeman | basically, yes. Or better yet choose the ID so you can encode who gets credit if that shot kills someone. The getNewWorldShotID is also not good if you want to use many shots and some shots may last longer than others |
| 03:40.51 | JeffM | well you are abbusin the shot systme anyway :) |
| 03:40.51 | JeffM | I'm trying to remmeber how to use the callback |
| 03:40.51 | JeffM | checking now |
| 03:40.52 | JeffM | I think what you do is ask for the plugin class of another plugin |
| 03:41.31 | JeffM | yeah so what you do is call bz_getPlugin |
| 03:41.34 | JeffM | give it the name of another plugin |
| 03:41.52 | JeffM | then you can call it's general callback with your data |
| 03:42.07 | JeffM | and have it pass back a new ID |
| 03:43.07 | JeffM | so int id = bz_getPlugin("idGetter")->GenericCallback("GimmeAnID",NULL); |
| 03:43.42 | JeffM | then in your ID manager, you implment your own drived version of GenericCallback that looks for calls with that name |
| 03:43.53 | JeffM | and gives out IDs |
| 03:44.31 | JeffM | if you need to pass in other data you can send in a structure pointer as the "data" paramater |
| 03:45.09 | blast007 | probably worth null checking the output of bz_getPlugin as well, just in case |
| 03:45.12 | JeffM | does that make sense? |
| 03:45.28 | JeffM | yeah |
| 03:45.33 | JeffM | I'd save off the pointer at the start |
| 03:45.46 | JeffM | then you can check if it exists or not |
| 03:45.51 | JeffM | but your needs are interesting |
| 03:45.53 | apeman | yes it makes sense |
| 03:46.15 | JeffM | what we need to do is expose a verson of ShotID where you can define a lifetime |
| 03:46.23 | JeffM | for scoring you can always keep a map |
| 03:46.36 | JeffM | but the lifetime thing is something that we don't handle now |
| 03:53.26 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 03:57.11 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 04:42.20 | *** join/#bzflag apeman1 (~Victor@222-155-41-238.jetstream.xtra.co.nz) |
| 07:02.25 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 07:14.50 | *** join/#bzflag rodgort (~rodgort@li125-242.members.linode.com) |
| 07:40.10 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 08:30.53 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 08:30.54 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 08:30.54 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 09:50.53 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 09:50.55 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 09:55.12 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 11:14.19 | *** join/#bzflag kierra (quassel@2600:3c03::f03c:91ff:fe93:2c7d) |
| 11:14.19 | *** join/#bzflag kierra (quassel@unaffiliated/kierra) |
| 12:06.52 | *** join/#bzflag meeba_ (~lamer@c-75-71-23-204.hsd1.co.comcast.net) |
| 12:09.26 | *** join/#bzflag Nitroxis (~n@wtwrp.de) |
| 12:29.43 | *** part/#bzflag apeman1 (~Victor@222-155-41-238.jetstream.xtra.co.nz) |
| 13:38.35 | *** join/#bzflag mdskpr (~quassel@li59-174.members.linode.com) |
| 14:44.12 | *** join/#bzflag raindog (~quassel@50-107-77-16.adr02.mskg.mi.frontiernet.net) |
| 15:28.52 | *** join/#bzflag raindog (~quassel@50-107-64-29.adr02.mskg.mi.frontiernet.net) |
| 15:53.57 | *** join/#bzflag ahs3- (~ahs3-@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 15:56.50 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 15:56.50 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 15:56.50 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 16:10.49 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 16:10.49 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 16:10.49 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 16:22.39 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 16:32.59 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 16:43.50 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 17:23.03 | *** join/#bzflag JeffM (~JeffM@107-209-61-105.lightspeed.irvnca.sbcglobal.net) |
| 18:03.06 | *** join/#bzflag Not-001 (~notifico@198.199.82.216) |
| 18:03.07 | Not-001 | [02bzflag-import-3] 07JeffM2501 pushed 032 commits to 03v2_4_x [+0/-0/±5] 13http://git.io/Mw8tuQ |
| 18:03.09 | Not-001 | [02bzflag-import-3] 07JeffM2501 0345aeb29 - int to bool warning fixed |
| 18:03.09 | Not-001 | [02bzflag-import-3] 07JeffM2501 03bf75473 - A way to fire a world weapon and get the shot ID A new version of fire world weapon that takes a pointer to a shot ID and gives back the first dead shot ID based on the lifetime from all other shots ( uses shot manager). Should make it easier for people to have multiple plug-ins that want to use world weapons and not have them conflict in IDs. There really isn't any reason for a plug-in to set the shot ID |
| 18:16.42 | JeffM | that should help plugins not fight |
| 18:17.04 | JeffM | it goes and looks for a shot ID that isn't in use so that should solve the lifetime issue |
| 18:22.00 | Delusional | Thanks Jeff. We'll get to work removing some of the hackiness from our plugins. |
| 18:22.17 | Delusional | some |
| 18:31.40 | JeffM | well do some tests first :) |
| 18:32.04 | JeffM | what you are doing with shots are still hacks and will still run into other issues |
| 18:32.16 | JeffM | does your developer understand how to use maps? |
| 18:33.08 | JeffM | BulletCatcher, so in the GIT world how would I apply those commits to 2.6? |
| 18:42.33 | Notify | 03BZFlag:JeffM2501 * 8771 /Functions(API): /* World Weapon Management */ |
| 18:43.36 | Notify | 03BZFlag:JeffM2501 * 8772 /Bz_fireWorldWep: |
| 18:43.53 | Notify | 03BZFlag:JeffM2501 * 8773 /Bz_fireWorldWep: /* Prototype */ |
| 18:44.20 | blast007 | and are we also going to do at least one other SVN-to-GIT import later? because I think we should move the import scripts to their own repo and have 'master' as the dev code (2.5 in our case) instead of having dev code in another branch. |
| 18:44.38 | JeffM | yeah the current system is hella confusing |
| 18:44.45 | blast007 | s/GIT/Git/ |
| 18:45.14 | JeffM | we are on month 8 of our import :) |
| 18:45.16 | blast007 | should probably have a branch for the normal 2.99.x code as well, right? |
| 18:45.26 | blast007 | currently it's in there as just a tag |
| 18:45.42 | blast007 | v2.99archive |
| 18:45.42 | JeffM | are we going to ever release it? |
| 18:45.53 | JeffM | or will it get pulled into a different branch? |
| 18:46.22 | blast007 | does a branch let us better track what went on in 2.99.x? I guess if not, then it doesn't matter. |
| 18:46.29 | JeffM | if it's going to live and get changes then it should be a branch, if it's a source to pull stuff from into a living branch then it shoudl be a tag |
| 18:46.43 | JeffM | I don't belive the history is affected ether way |
| 18:46.46 | blast007 | k |
| 18:47.05 | JeffM | it's just if we are going to make changes to 2.99 then it should be a branch, if it's just reference then a tag is ok |
| 18:47.14 | blast007 | we did have branches for the two 2.99.x branches (shots and net) |
| 18:47.34 | JeffM | sure thats when we were young and optomistic :) |
| 18:47.48 | blast007 | no, I mean, in our Git, right now |
| 18:48.15 | JeffM | well I have no idea what his goals are with all the imports |
| 18:53.03 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 19:30.51 | Notify | 03BZFlag:Allejo * 8774 /Bz_eFlagGrabbedEven: Added flagType which wasn't documented |
| 19:33.10 | Notify | 03BZFlag:Allejo * 8775 /Bz_eFlagDroppedEven: Added flagType which wasn't documented |
| 19:36.43 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 19:36.43 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 19:36.43 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 19:37.04 | *** join/#bzflag apeman (~Victor@222-155-41-238.jetstream.xtra.co.nz) |
| 19:41.26 | *** join/#bzflag Nitroxis (~n@wtwrp.de) |
| 19:50.19 | apeman | JeffM: "There really isn't any reason for a plug-in to set the shot ID, it can always keep a map to associate it with a player." |
| 19:50.20 | apeman | A map of Shot ID to player is not sufficient because if one plugin uses shot ID 5 then an independent one uses it some time later, now they both think a certain player owns it. When they try to change the killer, who gets the credit depends on which plugin is called last |
| 19:50.43 | JeffM | a plugin should only add shots that it creates to it's map |
| 19:50.48 | JeffM | so that should never happen |
| 19:51.06 | JeffM | the point is each plugin dosn't add IDs, it gets told what IDs it added |
| 19:51.08 | apeman | they use the shot ID 5 when the server gives it to them using getNextShotID |
| 19:51.23 | JeffM | yeah I changed the code to give BACK the ID |
| 19:51.28 | JeffM | so you can let the server create the ID |
| 19:51.32 | JeffM | and then only you will know it |
| 19:51.42 | JeffM | the other plugin won't know what shot you created |
| 19:51.46 | JeffM | so it shoudl never interfeere |
| 19:52.10 | apeman | Plugin one received shot ID 5 and then stored it. An hour later plugin 2 received shot ID 5 since it was free and stored it |
| 19:52.26 | apeman | they cant tell how long to store it for |
| 19:52.27 | JeffM | oh well yeah you have to handle the end shot event |
| 19:52.33 | JeffM | so you remove it from your map |
| 19:52.41 | JeffM | they can tell how long to store it :) |
| 19:52.46 | JeffM | when it ends you remove it |
| 19:52.57 | JeffM | if that mechanism isn't working then we should fix it |
| 19:53.00 | apeman | one shot can kill two players if the first victim lags. Both kills should be credited properly |
| 19:53.14 | JeffM | then we have to fix that |
| 19:53.27 | JeffM | the server has a shot manager that should be able to manage that |
| 19:53.31 | apeman | Some shots cant be ended like laser or shockwave |
| 19:54.01 | JeffM | and the server should know that |
| 19:54.35 | JeffM | that's the entire point of shot manager |
| 19:54.55 | blast007 | there's only so much you can do with custom flags right now given the limits of server-side tracking |
| 19:55.01 | JeffM | yeah |
| 19:55.14 | JeffM | the proper way to do what you want is to assign the shots to the player |
| 19:55.22 | JeffM | but you can't do that in the current protocoll |
| 19:56.12 | JeffM | this change may not be all you need, but it should be going in the right direction |
| 19:56.22 | JeffM | you can always use the custom callback to do what you need right now |
| 19:56.48 | apeman | Another problem case: Shot 5 is free and the plugin says it belongs to player 1. 3.6 seconds later shot 5 is free again because of reload time and it belongs to player 2. Player 2 gets credit for a shot by player 1 if the victim dies at expiry but they have 100ms lag |
| 19:57.33 | JeffM | yeah these are problems with setting player shots |
| 19:57.52 | JeffM | if you use world weapon shots then you know they won't be affected by reload |
| 19:58.01 | JeffM | we do NOT have a system to do what you want cleanly |
| 19:58.12 | apeman | This problem can be largely solved if the API gives you shot ID 5 and you're allowed to set it to 5 + 256 * playerID |
| 19:58.15 | JeffM | and when we do it won't be the world weapon API |
| 19:58.41 | JeffM | and you can do that with the custom callback |
| 19:58.49 | JeffM | but I'd not burn that into the API since it's a hack |
| 19:59.19 | JeffM | I understand your issues but you are stuck on encoding as being the only solution |
| 19:59.27 | JeffM | where we can just make shot manager smarter |
| 19:59.43 | JeffM | but there are limits do what can be done cleanly with the current hit method |
| 19:59.58 | JeffM | as you mentioned one shot killing 2 people |
| 20:00.11 | JeffM | for server collisions it'd pick one of those to die |
| 20:00.27 | apeman | when i mentioned reload I refer to the getNextShotID not reusing an ID until the shot is expired |
| 20:00.50 | JeffM | did you look at my new code for getNextShotID ? |
| 20:00.52 | JeffM | I changed it |
| 20:00.57 | apeman | yes |
| 20:00.59 | JeffM | k |
| 20:01.05 | JeffM | we could make it use the oldest ones |
| 20:01.07 | JeffM | that'd be easy |
| 20:01.20 | JeffM | give shot manager a 5 second time out on shot IDs |
| 20:01.22 | JeffM | or something |
| 20:02.11 | JeffM | for player shots reuse it if the player has kileld the shot and for server shots wait untill we are sure it's dead |
| 20:02.40 | JeffM | your multiplication method has to allocate fixed shots per player into your encoding and that can be hard to do across multiple plugins |
| 20:02.46 | JeffM | better to find a way to dynamicly allocate them |
| 20:02.50 | apeman | i did the same thing, give a timeout on a shot manager i wrote (thats the only viable option right now). Then i realised 5 seconds can hog a lot of shots. |
| 20:03.09 | JeffM | is shot ID a short or a byte? |
| 20:03.20 | apeman | 0-65536 |
| 20:03.22 | apeman | 65535 |
| 20:03.27 | JeffM | so an unsighed short |
| 20:03.31 | JeffM | so who cares |
| 20:03.35 | JeffM | it's just ram |
| 20:03.38 | JeffM | ram is cheap :) |
| 20:03.47 | apeman | err thats not my meaning |
| 20:03.59 | JeffM | if memory gets too high on the client we change the vector to a map |
| 20:04.07 | apeman | i mean that 5 seconds is a lot of time to wait for shots to expire. |
| 20:04.19 | JeffM | but who cares? |
| 20:04.24 | JeffM | as long as there are open IDs it's fine |
| 20:04.32 | apeman | but there are only 256 IDs |
| 20:04.47 | JeffM | and that's why encoding is a bad idea :) |
| 20:05.04 | JeffM | if you let shot manager handle the shots then it can manage it for as many players as there are |
| 20:05.07 | JeffM | it becomes dynamic |
| 20:05.09 | blast007 | actually I think the shot ID is a signed short, with only >= 0 being valid |
| 20:05.18 | JeffM | yeah that's what I thought to |
| 20:05.20 | JeffM | so 32k |
| 20:05.23 | JeffM | that's still a lot |
| 20:05.38 | blast007 | MsgKilled uses -1 as for the shot ID when it's not a death from a shot |
| 20:05.40 | JeffM | you arn't going to have 32 thousand shots fired in a 5 min span |
| 20:05.48 | JeffM | 5 second sorry |
| 20:06.40 | JeffM | heck I could even have shot manager store meta data for each shot so the plugin would not have to keep a map |
| 20:06.40 | apeman | So what about that salt stuff about taking modulo 256 and checking that players arent trying to fake shots |
| 20:07.03 | JeffM | a client can not create a shot that is assigned to the server player |
| 20:07.13 | JeffM | so that should not be an issue |
| 20:07.34 | apeman | It would need to be a protocol breaking release anyhow |
| 20:07.35 | JeffM | all of your plugin shots would be assigned to the server player, thats why you have to do your own scoring |
| 20:07.38 | JeffM | nope |
| 20:07.48 | JeffM | it'd be possible in the current system |
| 20:08.14 | JeffM | for proto break then shot ID needs to be decoupled from player |
| 20:08.19 | apeman | Currently it is not possible for ServerPlayer to have more than 256 shots active |
| 20:08.20 | JeffM | so any fired shot is just a GUID |
| 20:08.34 | JeffM | ok, see THAT was the main question I was asking you then |
| 20:08.39 | JeffM | so the effective limit is a byte |
| 20:08.46 | JeffM | so your multiplication thing can run out really fast |
| 20:09.08 | JeffM | a dynamic shot counter could maximize the number of shots that are live |
| 20:09.23 | apeman | Well in the current state. Max server shots is 256. Max shots encoded to a given owner is 256. |
| 20:09.23 | JeffM | and if the server runs out, end the oldest shots to replace them with newer shots |
| 20:09.52 | JeffM | for a shot do we send a byte for the player and a short for the shot? or a single short with both encoded? |
| 20:10.30 | apeman | we send PlayerId and a short for shotID |
| 20:11.00 | JeffM | ok and on the client we should use a vector to store the shot IDs for the server player right? |
| 20:11.16 | apeman | should or currently? |
| 20:11.20 | JeffM | currently |
| 20:11.27 | JeffM | I belive the server player has a special vector |
| 20:11.28 | apeman | an array of shots of 256 elements |
| 20:11.47 | apeman | every player has shots of 256 elements |
| 20:11.49 | JeffM | where is that located in the code? |
| 20:12.29 | JeffM | beucae if that is true then your method can never work, player ID 2 would give you shotID 512+ |
| 20:13.27 | apeman | why is that a problem |
| 20:13.43 | JeffM | because if hte shot ID is used as an index into that array it'll be outside the limits :) |
| 20:13.51 | apeman | Player.h std::vector<ShotPath*> shots; |
| 20:13.56 | JeffM | there ya go |
| 20:14.02 | JeffM | that's a vector not an array |
| 20:14.33 | apeman | my mistake. Every player has vector of shots of size MaxWorldShots |
| 20:14.41 | JeffM | do we ever grow it? |
| 20:14.47 | apeman | only serverplayer's shot array is 256 large |
| 20:14.51 | JeffM | do we ever grow it? |
| 20:15.25 | apeman | no |
| 20:15.26 | JeffM | shots.resize(shotNum+1); |
| 20:15.30 | JeffM | we do |
| 20:15.34 | JeffM | voidWorldPlayer::addShot(const FiringInfo& info) |
| 20:15.53 | JeffM | ahh but we strip some bytes |
| 20:15.55 | JeffM | interesting |
| 20:15.59 | apeman | the salt thing |
| 20:16.03 | JeffM | yeah your stuff is going to not work like you think |
| 20:16.08 | apeman | takes modulo 256 so 256 unique shots |
| 20:16.32 | JeffM | so you are just working on the assumption that the server doesn't do that so you can track IDs over 256 |
| 20:16.39 | JeffM | yeah that's super fragile |
| 20:17.03 | JeffM | that makes encoding a worse idea |
| 20:17.15 | apeman | huh? |
| 20:17.18 | JeffM | 2 of your encoded shots may come out to the same clamped ID |
| 20:17.55 | apeman | Use the ID from getNextWorldShotID(), then encode it. If they use same ID thats getNextWorldShotID()'s fault or you just tried to use too many bullets |
| 20:18.17 | apeman | you're given 2, you can use 258, 514, etc. |
| 20:18.34 | JeffM | and those get salted down to what on the client? |
| 20:18.38 | apeman | 2 |
| 20:18.48 | JeffM | so both shots are set as 2 in the shot array on the client |
| 20:18.52 | apeman | yes |
| 20:18.59 | JeffM | so there are 2 shots on the server, one on the client |
| 20:19.05 | JeffM | you lost a shot |
| 20:19.09 | JeffM | a player doesn't see one of the shots |
| 20:19.39 | apeman | well clearly you can only shoot one shot for each ID you get from getNextWorldShotID |
| 20:19.47 | apeman | if you need 2 shots you get 2 and 3 from it |
| 20:20.14 | JeffM | I'm saying in the case where the plugin sets it's own ID |
| 20:20.31 | JeffM | you are saying that the first shot from every player is encoded to be salted the same |
| 20:20.42 | JeffM | so really your multiplcation doesn't buy you anything at the client level |
| 20:20.46 | JeffM | just the server level |
| 20:21.06 | apeman | The only point of the encoding is to remember the designated shooter |
| 20:21.32 | JeffM | yes and that's what I'm saying shoudl be dooable with a map, or meta data |
| 20:21.53 | JeffM | you'd need all your plugins to use the same encoding convention |
| 20:22.09 | JeffM | but I understand your problems |
| 20:22.18 | apeman | currently, using a map is not a good solution due to trying to remember shot lifetimes which doesnt work with lag |
| 20:22.31 | JeffM | you are going to be screwed by some part of the process no mater what :) |
| 20:22.45 | JeffM | meta data could be pretty easy |
| 20:22.50 | JeffM | since we have a shot object for every ID |
| 20:23.03 | apeman | currently encoding shot ID is a better solution. Everyone uses their own shot ID allocation method anyway. It works on its own but they pretend other plugins dont use shots |
| 20:23.19 | JeffM | so in effect it doesn't work ;) |
| 20:23.49 | JeffM | there probalby isn't a good general solution |
| 20:23.49 | blast007 | would having it all in a single plugin make it easier? |
| 20:24.03 | JeffM | it's make it more consistent for the things built in that one plugin |
| 20:24.11 | apeman | It would start working if getNextWorldShotID allowed you have the shotID without firing |
| 20:24.15 | JeffM | but you can't force a serve rowner to only have a single plugin |
| 20:24.28 | JeffM | apeman, so reserve a shot ID? |
| 20:24.45 | JeffM | what for? so you can change it? |
| 20:24.53 | apeman | blast007: Yes, though one would not think about that at first when writing individual plugins like Death Blossom or Triple Barrel |
| 20:24.59 | blast007 | cuz if so, make a plugin that reads a definition file that defines all the custom flags along with some language for scoring, shot directions/lifetimes/etc, shot end effects, and so on |
| 20:25.00 | JeffM | just to hang a player ID on it? |
| 20:25.19 | JeffM | I can hang a player ID on a shot for you, that's easy |
| 20:25.24 | apeman | JeffM: yes, just to encode the owner |
| 20:25.25 | JeffM | no encoding nessisary |
| 20:25.32 | apeman | how? |
| 20:25.32 | JeffM | meta data :) |
| 20:25.44 | apeman | oh |
| 20:26.04 | JeffM | bz_setShotData(id,"namme", value); bz_getShotData(id,"name"); |
| 20:26.10 | JeffM | that'd be super easy |
| 20:26.33 | JeffM | the dat would be cleared every time we reused the shot so there would be no remaping |
| 20:26.43 | JeffM | I'll do that after lunch |
| 20:27.37 | JeffM | I can also make the new ID function prefer older shots |
| 20:28.07 | JeffM | well I mean make shots live as long as possible |
| 20:28.50 | JeffM | we actualy keep a list of "recently dead" shots and I can have it not use those IDs |
| 20:31.43 | apeman | I have #define _MAX_WORLD_SHOTS 30 changed to 256 |
| 21:39.35 | *** join/#bzflag JeffM (~JeffM@cpe-23-241-222-73.socal.res.rr.com) |
| 21:43.03 | Not-001 | [02bzflag-import-3] 07JeffM2501 pushed 031 commit to 03v2_4_x [+0/-0/±6] 13http://git.io/ilnO3g |
| 21:43.04 | Not-001 | [02bzflag-import-3] 07JeffM2501 0338e49b9 - more shot changes for the API Ability to store meta data with the shots so plug-in can save IDs for scoring. Expose shot GUID Refactor some ShotManager methods to make more sense Don't try to reuse recently dead shots for world weapons or player shots Respect the 255 shot world weapon effective limit |
| 21:43.40 | JeffM | that should help make it easer |
| 21:51.31 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 21:57.51 | Notify | 03BZFlag:JeffM2501 * 8776 /Functions(API): /* Shot Type Control */ |
| 21:57.58 | JeffM | guhhhh Wiki is soooooo slow |
| 22:03.39 | Notify | 03BZFlag:JeffM2501 * 8777 /Bz_getShotMetaData: Created page with "{{BZFS_API_Doc}} {{BZFS_API_Funcs}} ==Prototype== BZF_API uint32_t bz_getShotMetaData (int fromPlayer, int shotID, const char* name); ==Parameters== {| border="1" cellpadding=..." |
| 22:06.07 | Notify | 03BZFlag:JeffM2501 * 8778 /Bz_setShotMetaData: Created page with "{{BZFS_API_Doc}} {{BZFS_API_Funcs}} ==Prototype== BZF_API void_t bz_setShotMetaData (int fromPlayer, int shotID, const char* name, uint32_t value); ==Parameters== {| border="1..." |
| 22:07.23 | Notify | 03BZFlag:JeffM2501 * 8779 /Bz_shotHasMetaData: Created page with "{{BZFS_API_Doc}} {{BZFS_API_Funcs}} ==Prototype== BZF_API bool bz_shotHasMetaData (int fromPlayer, int shotID , const char* name); ==Parameters== {| border="1" cellpadding="20..." |
| 22:08.09 | Delusional | i was looking last week and it's been awhile since the wiki had to make any changes. |
| 22:10.16 | Notify | 03BZFlag:JeffM2501 * 8780 /Bz_getShotGUID: Created page with "{{BZFS_API_Doc}} {{BZFS_API_Funcs}} ==Prototype== BZF_API uint32_t bz_getShotGUID (int fromPlayer, int shotID); ==Parameters== {| border="1" cellpadding="20" cellspacing="0" ..." |
| 22:10.33 | JeffM | it's just so firggin slow |
| 22:10.53 | JeffM | probalby the notify hook |
| 22:11.18 | JeffM | between the GUID and the metadata you should have more tools available to you |
| 22:55.07 | *** join/#bzflag delusional (~delusiona@pool-98-111-215-152.pitbpa.fios.verizon.net) |
| 23:04.58 | apeman | JeffM: could you please change #define _MAX_WORLD_SHOTS 30 to 256 as well? |
| 23:05.17 | JeffM | I didn't know what else that would effect |
| 23:05.21 | JeffM | but I think it'll be ok |
| 23:06.01 | apeman | i have been running that for a long time |
| 23:06.59 | JeffM | k |
| 23:07.16 | JeffM | I'll do 255, I like to leave the end invalid to help with debugging :) |
| 23:07.29 | JeffM | then I know if it gets set to 256 it's bad |
| 23:09.29 | apeman | weird |
| 23:10.01 | apeman | that they use if (worldShotId > _MAX_WORLD_SHOTS) { not >= |
| 23:10.08 | Not-001 | [02bzflag-import-3] 07JeffM2501 pushed 031 commit to 03v2_4_x [+0/-0/±2] 13http://git.io/lvw_Nw |
| 23:10.09 | Not-001 | [02bzflag-import-3] 07JeffM2501 038852698 - use 255 for max world shot Since for some reason we mask out the highbyte of the shot ID we really can only have 256 shots for the world player, so let everything compute 255 for sanity. |
| 23:10.38 | JeffM | well there is no "they" |
| 23:10.38 | JeffM | :) |
| 23:11.20 | JeffM | and like I say, I like to use the max to indicate invalid |
| 23:11.38 | JeffM | but really we could use negative numbers |
| 23:11.44 | JeffM | at least on the server side |
| 23:12.37 | apeman | if you create a new server variable like bz_setBZDBDouble("_foo", 1.0, perms = 0, persistent = true); and then in-game do /reset * |
| 23:12.37 | apeman | the client thinks the variables didnt change but when server does bz_getBZDBDouble("_foo") the variables dont appear to be set |
| 23:13.35 | JeffM | IIRC we don't know what to "reset" it to since reset sets them all back to what they are set to at the command line |
| 23:13.58 | JeffM | you could have had multiple calls to set in the API, what one should we use? |
| 23:13.59 | JeffM | we'd have to keep a history |
| 23:14.59 | apeman | would it work _foo had a -set _foo in the .bzw? |
| 23:15.13 | apeman | i mean would it reset and still exist |
| 23:15.41 | JeffM | I think we only run the command line stuff, not the map |
| 23:15.52 | JeffM | but I am not an export in bzdb |
| 23:17.01 | JeffM | the way we load the map is weird |
| 23:18.50 | blast007 | apeman: if it's a variable that isn't set normally, you'd have to use -setforced |
| 23:19.33 | blast007 | and isn't 'persistent' only for client-side variables? |
| 23:19.49 | JeffM | yeah that makes it save it in the client config |
| 23:20.08 | JeffM | server has no built in data storage between sessions |
| 23:20.24 | blast007 | why do we even expose that in the API? |
| 23:20.49 | JeffM | when we had client scripting |
| 23:21.08 | JeffM | server could set a var as perisstant, client would store it, script would acccess it |
| 23:21.09 | JeffM | IIRC |
| 23:21.21 | JeffM | but right now it's useless |
| 23:21.37 | *** join/#bzflag delusional (~delusiona@pool-98-111-215-152.pitbpa.fios.verizon.net) |
| 23:21.51 | blast007 | 2.0 has it exposed as well |
| 23:22.30 | JeffM | probably exposeed everhthing that bzdb had and didn't realise it |
| 23:22.43 | JeffM | and can't change the API now :) |
| 23:22.51 | blast007 | :) |
| 23:23.34 | JeffM | we can make the server ignore that setting but the paramater needs to stay for binary compatability |
| 23:46.37 | *** join/#bzflag delusional (~delusiona@pool-98-111-215-152.pitbpa.fios.verizon.net) |
| 23:47.19 | *** join/#bzflag delusional (~delusiona@pool-98-111-215-152.pitbpa.fios.verizon.net) |