| 00:58.54 | *** join/#bzflag McSpider (~McSpider@198.143.187.178) |
| 00:59.28 | *** join/#bzflag cz3141 (cz3141@gateway/shell/devio.us/x-cyimppzgyzomaoxo) |
| 01:58.41 | *** join/#bzflag JeffM (~JeffM@cl211234.wl.callutheran.edu) |
| 01:58.42 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 01:58.42 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 02:12.06 | *** join/#bzflag McYukon (~McYukon@198.143.187.178) |
| 04:46.26 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 04:46.27 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 07:06.44 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 07:24.45 | *** join/#bzflag khazhyk` (~khazhyk@198.143.187.178) |
| 07:24.45 | *** join/#bzflag khazhyk` (~khazhyk@unaffiliated/khazhyk/x-1714154) |
| 07:37.30 | *** join/#bzflag AAA_awright (~aaa@2001:41d0:1:d632::1) |
| 08:15.54 | *** join/#bzflag AAA_awright (~aaa@2001:41d0:1:d632::1) |
| 08:57.03 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 12:48.19 | *** join/#bzflag Delusional (~delusiona@pool-173-71-173-214.pitbpa.fios.verizon.net) |
| 12:48.20 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 12:59.14 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 14:32.31 | *** join/#bzflag a_meteor (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 14:37.13 | *** join/#bzflag thrakattak (cz3141@gateway/shell/devio.us/x-tfzbgdwxktuauxyi) |
| 16:35.07 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 16:50.07 | *** join/#bzflag Delusional (~delusiona@pool-173-71-173-214.pitbpa.fios.verizon.net) |
| 16:50.07 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 17:50.40 | *** join/#bzflag JeffM_ (~JeffM@107-209-61-105.lightspeed.irvnca.sbcglobal.net) |
| 17:51.29 | *** join/#bzflag unclelightning (~chatzilla@pool-64-222-228-72.port.east.myfairpoint.net) |
| 18:15.01 | *** join/#bzflag unclelightning (~chatzilla@pool-64-222-228-72.port.east.myfairpoint.net) |
| 18:53.15 | *** join/#bzflag JeffM__ (~JeffM@107-209-61-105.lightspeed.irvnca.sbcglobal.net) |
| 19:22.26 | blast007 | wonder how hard it would be to add UDP support to the -solo bots... :/ |
| 19:22.45 | blast007 | my UDP fix breaks solo bots |
| 19:23.06 | blast007 | explains why there was a bot check for the UDP shot kick, though |
| 19:31.14 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 19:31.14 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 20:02.02 | allejo | anyone still care to enlighten me as to how bzfs parses the options block from a world file? that's all the bz_eGetWorldEvent needs to be fixed |
| 20:11.48 | JeffM__ | it happens early |
| 20:11.54 | JeffM__ | so it's wierd |
| 20:12.36 | JeffM | it's kinda hard to make the plugin do that kinda stuff |
| 20:12.51 | JeffM | at least at the world loading part |
| 20:13.03 | JeffM | you may be able to edit game modes directly |
| 20:14.00 | allejo | but you can't edit anything else? i thought the event unloaded the world entirely |
| 20:14.29 | blast007 | I suppose it unloads the world database, but not options |
| 20:14.52 | JeffM | the world is not all that's in the map file |
| 20:14.58 | JeffM | the world is the obstacles |
| 20:15.03 | JeffM | the options are different |
| 20:15.10 | JeffM | they are handled by the command processor |
| 20:15.14 | blast007 | bzfs isn't designed to be re-initialized |
| 20:15.21 | JeffM | bassicly the thing that parses command line options |
| 20:15.32 | JeffM | and that isn't tied to the map database |
| 20:15.41 | JeffM | what options are you trying to set? |
| 20:16.45 | allejo | i'm trying to finish the bz_eGetWorldEvent since there's a todo that says you still have to load the map options so I just assumed it'd be possible |
| 20:17.09 | JeffM | yeah we have to specificly open the map, find the options section and call the command line argument processor |
| 20:17.17 | JeffM | it may not be possible |
| 20:17.21 | JeffM | or it may be REALLY hard |
| 20:18.03 | allejo | well that's a real buzz kill.... why was the event even put there in the first place? :( |
| 20:18.21 | JeffM | so that plugins can generate maps |
| 20:18.27 | JeffM | not all maps come from files |
| 20:18.37 | JeffM | the plugin can generate a world file programaticly |
| 20:18.48 | JeffM | the city builder thing does that |
| 20:19.00 | JeffM | the act of putting options in a map is kinda a hack and came later |
| 20:19.16 | JeffM | honestly I don't think it belongs in the map |
| 20:19.34 | allejo | so the options block was never meant to exist? |
| 20:19.36 | JeffM | I undertand the convienence of having some config options that make sense for the map |
| 20:19.47 | JeffM | it is a relativly newer addition |
| 20:20.04 | JeffM | really the server options should have NO bearing on the map geometry |
| 20:20.27 | JeffM | but in practice there are reasons to have specific options in effect for some maps, since the maps were designed with those effects in mind |
| 20:20.35 | JeffM | better would be to package a config snippit with the map |
| 20:20.41 | JeffM | but someone decided to throw it in the map |
| 20:21.11 | JeffM | initaly there were all kinds of security holes in the options block |
| 20:21.18 | JeffM | then we limited what it could set |
| 20:21.26 | JeffM | like no -password :) |
| 20:21.28 | allejo | security holes as in passwords? |
| 20:21.31 | allejo | ah beat me to it |
| 20:21.39 | blast007 | -set root_password cheezewiz |
| 20:22.02 | JeffM | I mean the fact that the map can load a plugin is super scarry |
| 20:22.34 | allejo | but that's only considering the plugin exists |
| 20:22.40 | JeffM | the main reson for wanting that event to reload options is to do a map restart plugin |
| 20:23.04 | JeffM | we could just make the plugin read the options first and set them using other methods |
| 20:23.10 | JeffM | cheezy but safer |
| 20:23.15 | JeffM | I dunno |
| 20:23.23 | JeffM | I know a lot of maps use options block |
| 20:23.30 | blast007 | I think we'd need to clean up a good bit of code in order to re-load options on the fly |
| 20:23.35 | JeffM | maybe we should refactor the options processor into something better |
| 20:23.37 | JeffM | yeah |
| 20:23.48 | blast007 | a lot of our code expects that stuff to not change |
| 20:24.02 | blast007 | (or at least assumes it won't change) |
| 20:24.09 | allejo | where's the current processor? CmdLineOptions.cxx? |
| 20:24.10 | JeffM | optimaly the server itself would be a class and the command line options would just fill out data for it |
| 20:24.15 | JeffM | allejo, probably |
| 20:25.28 | allejo | the only thing I don't see in that file is the jumping and ricochet options, otherwise it'd be tedious but you'd be able to change things if you parse the options block |
| 20:25.50 | JeffM | they should be in there somewhere |
| 20:26.02 | allejo | oh wait, it's in gameOptions |
| 20:26.22 | allejo | was expecting a jumping variable |
| 20:26.48 | JeffM | no, that's part of the game type bitmask |
| 20:26.54 | JeffM | it's super OLD :) |
| 20:27.12 | JeffM | any of the options that are sent to the list server, jump, rico, etc.. are in a bitmask |
| 20:27.23 | allejo | oh |
| 20:27.25 | JeffM | most newer things get put into bzdb vars and stuff |
| 20:27.37 | JeffM | but those core game options are sent out to a lot of places |
| 20:28.48 | allejo | for a protobreak, would those options be moved to bzdb? |
| 20:29.09 | JeffM | possibly but then we'd have to redo the list server too |
| 20:29.28 | JeffM | and some of them get wierd if they'd be changed mid game |
| 20:29.45 | JeffM | like rico, our shot system isn't good enough to start computing ricos for shots that are live already |
| 20:29.57 | JeffM | and you'd have timing issues when changing it |
| 20:30.11 | allejo | timing issues? |
| 20:30.12 | JeffM | so it's not really a problem I think needs to be solved just now |
| 20:30.23 | JeffM | lets say I turn on rico |
| 20:30.28 | JeffM | you have fired a shot |
| 20:30.39 | JeffM | on your system it's not rico because you shot before I saw it |
| 20:30.45 | JeffM | but I see the shot after I see rico turned on |
| 20:30.47 | *** join/#bzflag Delusional (~delusiona@pool-173-71-173-214.pitbpa.fios.verizon.net) |
| 20:30.47 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 20:30.49 | JeffM | so for me it bounces |
| 20:30.52 | JeffM | for you it does not |
| 20:31.00 | JeffM | now our states are very out of sync |
| 20:31.14 | JeffM | you'd have to have each shot have a flag saying to create it rico or not |
| 20:31.33 | JeffM | those kind of options are only meant to be changed when no players are connected |
| 20:31.46 | JeffM | and the advantage of bzdb variabls is they can be changed when players are connected :) |
| 20:32.04 | *** join/#bzflag unclelightning (~chatzilla@pool-64-222-228-72.port.east.myfairpoint.net) |
| 20:32.08 | allejo | ahh, similar to the issue on why you can't change shot types properly? |
| 20:32.14 | JeffM | yeah |
| 20:32.22 | JeffM | we can't change all kinds of things properly |
| 20:32.28 | JeffM | the simulatation just isn't that arbitrary |
| 20:33.11 | JeffM | the best thing to do would be to decouple the server simulation from the server exe and the network connections |
| 20:33.19 | allejo | :-/ |
| 20:33.25 | JeffM | then have the ability to kill and reload the server simulation, with options and worlds as needed |
| 20:33.30 | JeffM | with out disconnecting anyone |
| 20:34.03 | JeffM | then you can also have a single server run multiple games |
| 20:34.17 | JeffM | just hook the different network conenctions up to the various games |
| 20:34.38 | allejo | well that would certainly have its advantages |
| 20:34.53 | JeffM | there isn't a lot we can do with our current archetecture |
| 20:35.03 | JeffM | anything fancy is going to get messy really fast |
| 20:35.08 | blast007 | there's one thing we can do well |
| 20:35.12 | blast007 | spiral downward ;) |
| 20:35.17 | JeffM | heh |
| 20:36.43 | allejo | lol |
| 20:37.09 | JeffM | with our a major change to our newtworking structure I don't know if we can do a proper map change system with out reloading |
| 20:37.38 | blast007 | even forcing a reconnect, it would be a challenge |
| 20:37.44 | JeffM | for a proto break we could make a message that resends the world options, forces everyone to limbo status and then makes them bassicly reload the world |
| 20:37.55 | JeffM | then you would not force a reconnection, but just a reload |
| 20:38.12 | JeffM | and you ensure that the game is over when things like rico and jump change |
| 20:38.23 | JeffM | that's probalby the best we can hope for |
| 20:40.11 | allejo | :-/ |
| 20:41.41 | JeffM | with out changes to the simulation and networking we are going to have timing issues with most dynamic features we'd like to implement |
| 20:41.45 | JeffM | moving objects and the like |
| 20:44.26 | allejo | :( |
| 20:45.07 | JeffM | sorry to be negative but I mean the game was written in the early 90s |
| 20:45.23 | JeffM | we can make it do all the fancy thigns we want, it's just going to take much larger changes to the backend first |
| 20:45.47 | blast007 | we should just be glad it wasn't written to use IPX/SPX |
| 20:45.52 | JeffM | heh |
| 20:46.00 | JeffM | the first one may have been |
| 20:46.08 | blast007 | oh boy |
| 20:46.28 | JeffM | remeber we only have the results if the first rewrite |
| 20:46.44 | blast007 | though I did play an IPX/SPX game over the internets using a wrapper program called Kahn ;) |
| 20:48.30 | *** join/#bzflag Delusional (~delusiona@pool-173-71-173-214.pitbpa.fios.verizon.net) |
| 20:48.32 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 20:48.49 | JeffM | or just do it in unity and submit it to steam |
| 20:49.02 | allejo | steam! |
| 20:49.07 | JeffM | solves the debian update problem :) |
| 20:50.55 | allejo | JeffM, wanna be an awesome friend and explain to me what some variables are for in the source? :P |
| 20:51.10 | JeffM | depends on what they are |
| 20:51.16 | blast007 | 'i' |
| 20:51.19 | JeffM | x |
| 20:51.28 | allejo | parameters for certain functions |
| 20:51.34 | blast007 | allejo: just ask :P |
| 20:51.42 | JeffM | only if I can bag on your editor since it can't tell you :) |
| 20:51.43 | allejo | "what's this 'i' for in this for loop?" |
| 20:51.53 | allejo | static char **parseWorldOptions (const char *file, int &ac) |
| 20:51.56 | allejo | what's ac? |
| 20:52.11 | blast007 | check where parseWorldOptions is called from |
| 20:52.29 | JeffM | an int reference... that's odd |
| 20:52.40 | allejo | blast007 |
| 20:52.40 | allejo | <PROTECTED> |
| 20:52.41 | allejo | <PROTECTED> |
| 20:53.07 | allejo | this is from CmdLineOptions.cxx |
| 20:53.11 | JeffM | wierd |
| 20:53.14 | JeffM | it's a return value |
| 20:53.19 | JeffM | it gets set to 1 |
| 20:53.21 | JeffM | or 0 |
| 20:53.55 | JeffM | it's passed into parse as argc |
| 20:54.23 | JeffM | parse takes an argument count |
| 20:54.36 | JeffM | if the options can't be read then there are 0 arguments |
| 20:55.38 | JeffM | so in parseWorldOptions if confStrm.is_open() is false, there are no options, and since the return of the function is a char handle, it can't also return how many arguments it processed |
| 20:55.43 | JeffM | so it passes those back in ac |
| 20:55.57 | JeffM | then that argument count is sent into parse as the number to read from the returned char handle |
| 20:56.24 | JeffM | bassicly a function can't return 2 things, and this needs to return a count and an array of strings |
| 20:56.43 | blast007 | wouldn't that make the loop in parse() never do anything? 1 would never be less than 0 or 1. |
| 20:56.47 | blast007 | the for loop* |
| 20:56.53 | JeffM | yes |
| 20:56.55 | JeffM | that's the point |
| 20:57.12 | JeffM | if it wasn't able to get any options, it sets the size to 0 so it doesn't try to parse ANY options |
| 20:57.19 | JeffM | it's so it handles the error case |
| 20:57.40 | blast007 | my point is that it would *never* do anything, right? |
| 20:58.00 | blast007 | or am I missing something? |
| 20:58.07 | JeffM | if it's 1 then it parses a single value in the array |
| 20:58.19 | JeffM | if it can read the options it sets ac to 1 at the end |
| 20:58.26 | JeffM | so parse reads one time |
| 20:58.31 | blast007 | oh wait, I missed the ac++ inside the parseWorldOptions options used as the array index |
| 20:58.32 | JeffM | since zero is less then one |
| 20:58.55 | JeffM | yeah in the array |
| 20:59.00 | JeffM | man that's crapy coode |
| 20:59.01 | blast007 | I was thinking that ac would only ever be 0 or 1 and was wondering how our options block ever worked ;) |
| 20:59.03 | JeffM | hates inline ++ |
| 20:59.11 | JeffM | yeah that's how it counts the options |
| 20:59.21 | allejo | so it's checking the options block and ac is set to 1 (and then changes according to the number of settings) provided there is something to read in the options block. and it returns **av which is the list of arguments/settings in the options block? |
| 20:59.27 | blast007 | yep, makes a lot more sense now that I saw that bit |
| 20:59.37 | JeffM | ac is set to the number of options parsed |
| 20:59.51 | JeffM | and yeah it returns an array of character pointers that are the options |
| 21:00.00 | JeffM | then parse goes and processes them one by one |
| 21:00.06 | *** part/#bzflag blip (cz3141@gateway/shell/devio.us/x-tfzbgdwxktuauxyi) |
| 21:00.57 | allejo | this makes a lot more sense now |
| 21:01.20 | JeffM | you usualy know something is up when you see the & in a paramater list |
| 21:01.25 | JeffM | that means pass by reference |
| 21:01.54 | JeffM | so that you can change the paramater and it changes the value of the variable passed in, rather then the default pass by value that makes a copy |
| 21:02.54 | allejo | ahhh so you can keep track or two or more things since you can't return more than one thing |
| 21:03.19 | JeffM | yeah |
| 21:03.30 | JeffM | so you don't have to return a structure or something |
| 21:03.39 | JeffM | since that makes a copy too |
| 21:04.02 | JeffM | if your arguments are big, passing by value can get slow |
| 21:04.57 | blast007 | return libraryOfCongress; |
| 21:05.31 | JeffM | if that was a CCongressionalLibrary& you'd be fine |
| 21:05.36 | allejo | lol |
| 21:05.36 | JeffM | or a ^ |
| 21:05.46 | JeffM | or even a * |
| 21:06.01 | JeffM | allejo, you know that arguments are copied by default right? |
| 21:06.10 | blast007 | it's an array of uncompressed bitmaps scanned at 600DPI |
| 21:06.15 | allejo | in functions? yea |
| 21:06.21 | JeffM | k |
| 21:07.15 | allejo | I'm starting to think the getworldevent doesn't even work properly... |
| 21:07.17 | JeffM | passing them as * or & makes it so you can mod them |
| 21:07.21 | JeffM | it may not |
| 21:07.27 | JeffM | it's kinda hack |
| 21:07.44 | allejo | it allows for files to loaded but doesn't parse the file to check the game time |
| 21:07.59 | allejo | it just assumes one of the variables are set to true |
| 21:08.11 | allejo | that's the difference between an * and a & |
| 21:08.38 | JeffM | * can be used as an array, & can not |
| 21:08.43 | JeffM | & is strongly typed |
| 21:09.15 | JeffM | game time, or game type? |
| 21:09.28 | allejo | game type* |
| 21:09.30 | allejo | my bad |
| 21:09.33 | JeffM | yeah it can't change that |
| 21:09.37 | blast007 | type you probably can't change on the fly even if it did read it |
| 21:09.49 | blast007 | certainly not without a rejoin |
| 21:09.56 | JeffM | it's like I said, we don't really have the ability to do a full map reload |
| 21:10.03 | JeffM | not with out the ability to resend the connection info |
| 21:10.14 | allejo | the getworldevent is only called at start or a bz_restart() which is my intention |
| 21:10.25 | JeffM | it was intended to generate world geometry |
| 21:10.38 | allejo | and I shall change what it was intended for :p |
| 21:10.39 | JeffM | you can restat a map, but not restart a game :) |
| 21:10.55 | JeffM | you may not be able to with out some larger changes first |
| 21:11.14 | JeffM | I'd look at the place we send the game type and stuff |
| 21:11.23 | JeffM | and get it working so that you can resend that at any time |
| 21:11.35 | JeffM | and get the clients to respect it and all go into limbo (despawn) |
| 21:11.49 | JeffM | then you can have the event fully reload the server |
| 21:12.00 | JeffM | or at least the game/map aspects |
| 21:13.10 | allejo | from my understanding bz_restart does a superkill, unloads the map and then reloads it without an actual server instance restarting. the map unloading and loading triggers the defineWorld() function so that's where I'd plan on reading the map file and change the server options before players can even rejoin |
| 21:13.34 | allejo | so for the moment, i want it unload/load properly and then see if i can send players into limbo |
| 21:13.42 | JeffM | it disconnects everyone? |
| 21:13.50 | allejo | bz_restart() does |
| 21:13.54 | JeffM | thats lame |
| 21:13.58 | allejo | very |
| 21:17.53 | blast007 | allejo: changing the options is likely going to be more complicated than you are thinking |
| 21:18.22 | allejo | nothing can ever be simple :( |
| 21:18.24 | blast007 | some command line options may control how other parts of our code is executed and initialized |
| 21:19.04 | blast007 | for instance, the flag list... not sure if FFA mode creates team flags in the list |
| 21:19.32 | blast007 | and then if there are multiple team flags... |
| 21:19.59 | blast007 | you'd probably have to flush the flag list and reinitialize it |
| 21:21.16 | allejo | meh :x |
| 21:22.02 | JeffM | yeah I'd start by lookint at our init sequence so you understand exactly what has to be done |
| 21:23.27 | blast007 | most of our variables are likely only initialized at server start, so you'd have to redo all that again to some extent |
| 21:23.37 | allejo | weeee...... |
| 21:23.57 | blast007 | (for instance, it starts out in FFA mode, and there's no "this is FFA" option - it just assumes that if you don't pick another mode that it is FFA) |
| 21:24.59 | blast007 | you're looking at a substantial amount of work ;) |
| 21:25.33 | allejo | takes a deep breath |
| 21:26.09 | allejo | I'll try not to break anything :p |
| 21:32.07 | JeffM | good god, how does anyone actualy use fedora? |
| 21:32.57 | allejo | by putting it on their head? |
| 21:33.01 | allejo | oh wait wrong fedora |
| 21:33.04 | *** join/#bzflag gursis (~gursis@91.210.101.95) |
| 21:33.46 | JeffM | so really what crappy editor are you using that can't show you where an argument is used? |
| 21:35.50 | allejo | Xcode... I just couldn't figure out what the variables were used for, I was able to find where they were used just not helpful on first glance |
| 21:46.23 | allejo | hehe k-lined |
| 23:54.41 | *** join/#bzflag Pimpi_ (~frank@gondolin.pimpi.org) |