Timestamps are in GMT/BST.
| 00:20:00 | | karamazovapy_ is now known as karamazovapy |
| 03:20:00 | | raptor_ has joined |
| 03:20:00 | | ChanServ sets mode +o raptor_ |
| 03:24:00 | | raptor Quit (Remote host closed the connection) |
| 03:25:00 | | raptor_ is now known as raptor |
| 03:56:00 | karamazovapy | today is the anniversary of Led Zeppelin IV, in case you didn't know |
| 04:13:00 | raptor | also marie curie's birthday |
| 04:16:00 | karamazovapy | fuck that radioactive bitch |
| 04:16:00 | karamazovapy | ALL HAIL GOJIRA! |
| 04:22:00 | raptor | man what was i smoking when i wrote this new joystick code |
| 05:26:00 | raptor | sam686: are you around? |
| 06:48:00 | | raptor Quit (Remote host closed the connection) |
| 07:22:00 | | CrazyLinuxNerd has joined |
| 07:52:00 | | koda Quit (Quit: koda) |
| 08:52:00 | | kodax has joined |
| 09:54:00 | | CrazyLinuxNerd has left |
| 09:54:00 | | CrazyLinuxNerd has joined |
| 10:37:00 | | CrazyLinuxNerd Quit (Remote host closed the connection) |
| 10:45:00 | | CrazyLinuxNerd has joined |
| 11:07:00 | | watusimoto has joined |
| 11:07:00 | | ChanServ sets mode +o watusimoto |
| 11:53:00 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 12:03:00 | watusimoto | >>> woah, i gotta be more careful with my levelgen coding xD I crashed bitfighter with it woops! <<< |
| 12:03:00 | watusimoto | how? |
| 12:10:00 | sam686 | not hure how CrazyLinuxNerd ho it to crash, but there a way it can freeze in a LUA. "while true do end" |
| 12:41:00 | watusimoto | you can freeze it with an endless loop |
| 12:41:00 | watusimoto | I'm worried less about that than a crash. I'll ask him again when he comes back on |
| 12:41:00 | watusimoto | oh yes, I see you had posted an endless loop :-) |
| 13:08:00 | | CrazyLinuxNerd has joined |
| 13:57:00 | | watusimoto Quit (Read error: Operation timed out) |
| 15:32:00 | | watusimoto has joined |
| 15:32:00 | | ChanServ sets mode +o watusimoto |
| 15:32:00 | watusimoto | >>> woah, i gotta be more careful with my levelgen coding xD I crashed bitfighter with it woops! <<< |
| 15:32:00 | watusimoto | why? |
| 15:32:00 | watusimoto | how did you do it? |
| 15:33:00 | watusimoto | that query is for CrazyLinuxNerd |
| 16:25:00 | | sam686 has left |
| 16:36:00 | CrazyLinuxNerd | back, sorry i was afk |
| 16:38:00 | CrazyLinuxNerd | i made the levelgen abort the game due to incorrect coding, it's a coder error more than anything. I'll take a look at my code, though i fixed it since. I'll try to remember how :-) |
| 16:46:00 | CrazyLinuxNerd | ah yes that was it, i accidently fed a math.random into a levelgen:additem where it was expecting a string |
| 16:46:00 | CrazyLinuxNerd | resulting in this error |
| 16:46:00 | CrazyLinuxNerd | LevelGenerator:addItem() expected string arg at position 8 |
| 16:46:00 | CrazyLinuxNerd | terminate called after throwing an instance of 'LuaException' |
| 16:46:00 | CrazyLinuxNerd | what(): LevelGenerator:addItem() expected string arg at position 8 |
| 16:46:00 | CrazyLinuxNerd | Aborted |
| 16:47:00 | CrazyLinuxNerd | clearly my own mistake |
| 17:17:00 | karamazovapy | and that crashed the whole server? |
| 17:18:00 | CrazyLinuxNerd | wasn't on my server, it was my game editing via level editor, crashed the whole thing :-) |
| 17:18:00 | CrazyLinuxNerd | but hey, it's bad code, it happens lol. |
| 17:19:00 | karamazovapy | hm. usually the script just doesn't run. |
| 17:19:00 | CrazyLinuxNerd | this levelgen:addItem("TextItem", -1, -1.15, -8.1, -0.942671, -8.1, 23, randommaze) should have been levelgen:addItem("TextItem", -1, -1.15, -8.1, -0.942671, -8.1, 23, randomizemaze) - I simply made a typo and put the wrong var in :-) |
| 17:19:00 | karamazovapy | that's interesting. |
| 17:21:00 | CrazyLinuxNerd | sorry, it was the randommaze that was the wrong one I think. randommaze being randommaze = true; while randomize maze being randomizemaze = math.random(0,3) |
| 17:21:00 | karamazovapy | well it's the fact that it crashed the editor instead of just aborting the script that's interesting |
| 17:22:00 | CrazyLinuxNerd | oh well :-) it's just bad code and a bug in my own code that's all :-) |
| 17:22:00 | CrazyLinuxNerd | was easy to fix (just put the right var in..) |
| 17:23:00 | | raptor has joined |
| 17:23:00 | | ChanServ sets mode +o raptor |
| 17:24:00 | raptor | watusimoto: what would be a better format for buttons in the INI?: |
| 17:25:00 | raptor | Button1=0,A,Blue,Circle (SDL raw, label, label color, button shape) |
| 17:25:00 | raptor | or |
| 17:26:00 | raptor | Button1=0 |
| 17:26:00 | raptor | Button1Label=A |
| 17:26:00 | raptor | Button1Color=Blue |
| 17:26:00 | raptor | Button1Shape=Circle |
| 17:27:00 | watusimoto | or Button1=Label:A;Color:Blue;Shape:Circle |
| 17:27:00 | watusimoto | css style! |
| 17:27:00 | karamazovapy | what? |
| 17:27:00 | raptor | then I have one more level of parsing.. |
| 17:28:00 | watusimoto | more than Button1=0,A,Blue,Circle ? |
| 17:28:00 | CrazyLinuxNerd | I like the css one.. not that it matters lol. |
| 17:28:00 | raptor | sure - i'd have to find 'Label' ane 'Color' instead of hard-coding index 0,1 of the split Vector... :) |
| 17:29:00 | watusimoto | oh I see, because things could be in any order |
| 17:29:00 | raptor | yes |
| 17:29:00 | watusimoto | I'm just heading out; I have one other proposal I'll give you when I get home |
| 17:29:00 | raptor | or maybe I should just use JSON? |
| 17:29:00 | raptor | ok |
| 17:29:00 | watusimoto | I'll be home in about 15 minutes |
| 17:29:00 | raptor | k |
| 17:30:00 | karamazovapy | wait. what? |
| 17:30:00 | watusimoto | read this; it will give you a preview |
| 17:30:00 | watusimoto | http://www.lua.org/pil/25.html |
| 17:30:00 | watusimoto | later |
| 17:30:00 | raptor | bye |
| 17:30:00 | raptor | karamazovapy: I am rewriting the joystick presets to be editable from an INI file |
| 17:31:00 | raptor | then people can share presets |
| 17:31:00 | raptor | because it's not in the compiled code |
| 17:31:00 | CrazyLinuxNerd | that sounds a lot easier raptor |
| 17:31:00 | CrazyLinuxNerd | well for the end user, not so much your self having to make that work xD |
| 17:31:00 | karamazovapy | I think I understand. |
| 17:32:00 | raptor | karamazovapy: are you ok? |
| 17:32:00 | karamazovapy | at first I didn't get that you were talking about controller buttons |
| 17:32:00 | karamazovapy | and I was trying to imagine where buttons could possibly come in |
| 17:33:00 | raptor | ah - sorry, i guess i picked up in the middle of a conversation i had with watusimoto yesterday like there was no pause... |
| 17:33:00 | CrazyLinuxNerd | ooh i think he was getting mixed up with my levelgen crash of game and your buttons? I think. |
| 17:33:00 | karamazovapy | I wasn't mixing anything together, I was just imagining how buttons would work inside the game |
| 17:33:00 | karamazovapy | for any purpose |
| 17:34:00 | CrazyLinuxNerd | fair enough :-) |
| 17:34:00 | CrazyLinuxNerd | raptor: Fedora 16 is out btw.. |
| 17:35:00 | | watusimoto Quit (Ping timeout: 256 seconds) |
| 17:39:00 | raptor | CrazyLinuxNerd: doesn't look like Fedora 16 is imported into the Open Build Service yet - may be a few weeks befoer I can build bitfighter for it.. |
| 17:39:00 | CrazyLinuxNerd | that's ok for two reasons: 1 I'm on 15 for now, till i upgrade at some point.. really fearing that grub2..... and 2, i can easily compile on my own :-) |
| 17:41:00 | CrazyLinuxNerd | thing i'm worried about though is fedora 16 upgrade, will replace my current grub and mbr... if it goes wrong.. i gotta learn grub2 and fast to install it properly :/ |
| 17:42:00 | | kodax Quit (Remote host closed the connection) |
| 17:45:00 | | kodax has joined |
| 17:51:00 | | sam686 has joined |
| 17:51:00 | | ChanServ sets mode +v sam686 |
| 17:57:00 | | Watusimoto has joined |
| 17:58:00 | raptor | so I read much of that LUA chapter Watusimoto |
| 17:58:00 | raptor | are you suggesting that long-term we move away from INI and do LUA config files? |
| 18:06:00 | Watusimoto | hi, ok, back |
| 18:06:00 | Watusimoto | no |
| 18:06:00 | Watusimoto | I was thinking of suggesting that, but I don't think I am |
| 18:07:00 | Watusimoto | the more I think about it, the more problems it seems to create; |
| 18:07:00 | Watusimoto | the solution I like best of those we've discussed is the css format one |
| 18:07:00 | raptor | i think staying with a data format, instead of a programming language would be simplest |
| 18:07:00 | Watusimoto | I like it because it's compact and readble |
| 18:07:00 | Watusimoto | and writable |
| 18:08:00 | Watusimoto | if we go this route, we'd obvously want some tool that reads a line and spits out a map<string><string> |
| 18:08:00 | raptor | yes |
| 18:08:00 | Watusimoto | with the first item being param name and teh second being param value |
| 18:08:00 | raptor | funny thing: i don't think i've used maps much in c++ |
| 18:08:00 | Watusimoto | and probably one to go the other way |
| 18:09:00 | Watusimoto | I've used them a couple of times |
| 18:09:00 | Watusimoto | but mostly recently |
| 18:09:00 | Watusimoto | I don't thing writing a parser would be hard at all |
| 18:09:00 | raptor | me neither |
| 18:09:00 | raptor | ok, i can do that... |
| 18:09:00 | raptor | (I already started the joysticks_presets.ini) |
| 18:10:00 | Watusimoto | the main advantage of using lua is that it would save us writing the parser; but then we'd need to process the resulting tables anyway, which might even be harder |
| 18:10:00 | raptor | yeah... |
| 18:10:00 | raptor | i'll just write a parser |
| 18:10:00 | Watusimoto | ok |
| 18:11:00 | Watusimoto | so the general format will be; key=name1:val1; name2:val2; name3:val3 |
| 18:11:00 | raptor | yes |
| 18:11:00 | raptor | ok |
| 18:11:00 | Watusimoto | the parser need not worry about vals other than strings |
| 18:11:00 | Watusimoto | or names other than strings |
| 18:12:00 | Watusimoto | but we'll probably need to allow for name1:"name with a ; in it"; name2:blah |
| 18:12:00 | Watusimoto | but I think we can discard the case "funky name with : in it":value |
| 18:12:00 | Watusimoto | i.e. no quotes in name |
| 18:13:00 | raptor | i'll just check for the first ':' |
| 18:13:00 | raptor | or we can use an obscure delimiter |
| 18:13:00 | raptor | like | |
| 18:13:00 | raptor | (pipe) |
| 18:13:00 | Watusimoto | another advantage that occured to me on the way home is that we can use this to normalize some of the syntax that sam added for things like rotating speedzones |
| 18:14:00 | Watusimoto | and to extend various aspects of level files |
| 18:14:00 | raptor | or one of my favorites: Ø |
| 18:14:00 | Watusimoto | :-) |
| 18:14:00 | Watusimoto | let;s stick with ; |
| 18:14:00 | raptor | ah, so you're thinking of adding the parser to .level files? |
| 18:14:00 | Watusimoto | | is not so obscure that we could ignore it inside quotes, and that other one is untypable on my keyboard |
| 18:15:00 | Watusimoto | and the ; looks rather normal and expected to me, at least, given that I've been doing a bumch of css lately |
| 18:16:00 | Watusimoto | how do we handle cases like this? |
| 18:16:00 | Watusimoto | key=no colons here |
| 18:16:00 | Watusimoto | I guess return an empty map |
| 18:16:00 | raptor | wait wait |
| 18:16:00 | raptor | are you suggesting we extend the INI parser? |
| 18:16:00 | Watusimoto | I was just about to clarify my thinking on that |
| 18:16:00 | Watusimoto | no |
| 18:17:00 | Watusimoto | in short |
| 18:17:00 | Watusimoto | so the ini still reads in a string value |
| 18:17:00 | Watusimoto | just as it does to day. |
| 18:17:00 | Watusimoto | so if we have key=name1:val1; name2:val2; name3:val3 |
| 18:17:00 | Watusimoto | it just comes back as the string key=name1:val1; name2:val2; name3:val3 |
| 18:17:00 | Watusimoto | sorry |
| 18:17:00 | Watusimoto | the string name1:val1; name2:val2; name3:val3 |
| 18:17:00 | raptor | ok that makes sense |
| 18:18:00 | raptor | then we call the secondary parser on a per-case basis? |
| 18:18:00 | Watusimoto | then since we know that we're expecting a set of joystick thinggies, we pass that on to something like parseMultiString() |
| 18:18:00 | Watusimoto | yes |
| 18:18:00 | Watusimoto | I think that makes the most sense |
| 18:19:00 | raptor | ok that was my original thought |
| 18:19:00 | Watusimoto | mabye map<string><string> parseMultiString(string multiString) |
| 18:19:00 | raptor | but you mention rotating speed-zones - isn't that in the .level files? |
| 18:19:00 | Watusimoto | yes; but we can use the same parser to digest those strings |
| 18:20:00 | Watusimoto | because now we'll have a general way to turn a string into a map |
| 18:20:00 | raptor | ok, simple enough |
| 18:20:00 | Watusimoto | or maybe parseMultiString(string multiString, map<string,string> fillMap) |
| 18:20:00 | Watusimoto | deneding on what you feel like |
| 18:21:00 | Watusimoto | (where you pass the empty map to avoid copying costs) |
| 18:21:00 | Watusimoto | at the risk of reduced clarity |
| 18:22:00 | Watusimoto | parseMultiString()? unpackMultiString()? multiStringToMap()? |
| 18:22:00 | raptor | yeah, that's a funny thing: I am seeing a movement in the c++ community back to returning objects instead of passing in fill objects... |
| 18:22:00 | raptor | parseMultiDimensionalString |
| 18:22:00 | Watusimoto | returning pointers to objects, or the objects them selves? |
| 18:22:00 | raptor | both |
| 18:23:00 | Watusimoto | pointers makes sense |
| 18:23:00 | raptor | just the 'return' vs 'pass in' |
| 18:23:00 | raptor | because of increased readability |
| 18:23:00 | Watusimoto | returning the object incurs unneeded copy cost |
| 18:23:00 | raptor | yes |
| 18:23:00 | Watusimoto | which for somethings, like Point, are probably insignificant |
| 18:23:00 | Watusimoto | but for a long vector might be a bit bigger |
| 18:24:00 | Watusimoto | all of this will run at startup time, so performance isn't critical |
| 18:25:00 | raptor | see first answer: http://stackoverflow.com/questions/5212794/pass-reference-to-output-location-vs-using-return |
| 18:25:00 | Watusimoto | does this plan make sense? |
| 18:25:00 | raptor | yep |
| 18:28:00 | raptor | looks like GCC already does return value optimization |
| 18:29:00 | raptor | ok, i'll be back... |
| 18:29:00 | | raptor Quit (Remote host closed the connection) |
| 18:33:00 | | raptor has joined |
| 18:33:00 | | sam686 Quit (Read error: Connection reset by peer) |
| 18:33:00 | | ChanServ sets mode +o raptor |
| 18:33:00 | raptor | back |
| 18:36:00 | Watusimoto | http://msdn.microsoft.com/en-us/library/ms364057(v=vs.80).aspx |
| 18:36:00 | Watusimoto | mildly interesting. looks like vc++ does it too |
| 18:37:00 | Watusimoto | so write it however you want |
| 18:38:00 | | sam686 has joined |
| 18:38:00 | | ChanServ sets mode +v sam686 |
| 18:40:00 | raptor | vc++ doesn't do it with debug code it looks like |
| 18:40:00 | raptor | but my gcc does |
| 18:42:00 | Watusimoto | I'm less concerned with performance in debug code |
| 18:45:00 | | raptor Quit (*.net *.split) |
| 18:45:00 | | raptor has joined |
| 18:45:00 | | raptor Quit (Changing host) |
| 18:45:00 | | raptor has joined |
| 18:45:00 | | ChanServ sets mode +o raptor |
| 18:47:00 | | kodax Quit (Quit: Sto andando via) |
| 19:43:00 | | Watusimoto Quit (Ping timeout: 260 seconds) |
| 19:44:00 | | sam686 Quit (Ping timeout: 258 seconds) |
| 19:56:00 | | sam686 has joined |
| 19:56:00 | | ChanServ sets mode +v sam686 |
| 20:19:00 | | sam686 has left |
| 20:23:00 | | sam686 has joined |
| 20:23:00 | | ChanServ sets mode +v sam686 |
| 20:35:00 | | LordDVG has joined |
| 20:39:00 | | LordDVG Quit (Remote host closed the connection) |
| 20:58:00 | | Watusimoto has joined |
| 21:09:00 | sam686 | http://208.107.52.15/bitfighter/016_editor.png selecting multiple turret and press TAB don't look that good. Overlapping spybugs visible area from different teams don't look good either... |
| 21:28:00 | | koda has joined |
| 21:28:00 | | CrazyLinuxNerd has left |
| 21:36:00 | raptor | reading up on lambda function support for c++ |
| 21:37:00 | karamazovapy | in spite of this answer, I don't think he understands what compiling is. |
| 21:37:00 | karamazovapy | http://bitfighter.org/forums/viewtopic.php?f=29&t=946&p=7988#p7982 |
| 21:38:00 | raptor | hmmm |
| 21:38:00 | Watusimoto | sam -- what would you propose as something that would look good? Perhaps a solid red area for the red spybugs, a solid blue one for the blue bugs, with a purple area where they overlap? |
| 21:39:00 | raptor | well, if sam686 or Watusimoto has time, they could add to the readme here: http://code.google.com/p/bitfighter/source/browse/README.txt |
| 21:39:00 | Watusimoto | though not sure how to do that |
| 21:39:00 | Watusimoto | yes, they could |
| 21:39:00 | Watusimoto | :-) |
| 21:40:00 | karamazovapy | the turret squares appear to overlap properly, while the spybugs just cover each other up |
| 21:40:00 | Watusimoto | I think for windows, it's just a matter of installing vc++, downloading the code, and compiling |
| 21:41:00 | karamazovapy | new users need more descriptive step-by-step instruction than that |
| 21:41:00 | Watusimoto | @k yes, if they are on the same team -- but what if, as in sam's pic, yellow overlaps red, which overlaps green? |
| 21:42:00 | karamazovapy | the rgb values are averaged for the overlapping area? |
| 21:42:00 | Watusimoto | then you end up with a muddled brown |
| 21:42:00 | karamazovapy | sometimes |
| 21:42:00 | karamazovapy | more likely grayscale,though |
| 21:42:00 | Watusimoto | luckily, this situation only occurs in the editor, not in the game |
| 21:42:00 | sam686 | also, turrets can't fire all angles, only about a little more then 180 degree angles.. |
| 21:43:00 | Watusimoto | that's true -- they also can't fire through walls |
| 21:43:00 | karamazovapy | I agree that it would be nice, but far more complicated to apply line of sight to the turret ranges |
| 21:43:00 | Watusimoto | absolutely |
| 21:43:00 | Watusimoto | I'm wondering if the turret ranges are really worth showing at all |
| 21:44:00 | karamazovapy | it's kind of nice when you're designing a level |
| 21:44:00 | karamazovapy | you can see how deadly different areas are |
| 21:50:00 | sam686 | turrets visible area only shows when selected, so i guess that ok, but spybug from multiple teams overlap may be a problem, right now in 016, spybug always shows visible area even when not selected.. |
| 21:50:00 | sam686 | then pressing TAB |
| 21:50:00 | Watusimoto | trying to figure out how to improve the situation |
| 21:51:00 | karamazovapy | test averaging the rgb values. you won't get brown very often. |
| 21:51:00 | Watusimoto | can't jsut draw areas as translucent, because overlapping red spybugs shoould not be different than areas that don't overlap |
| 21:51:00 | | raptor Quit (Remote host closed the connection) |
| 21:51:00 | Watusimoto | but where red and blue overlap, they should be different' |
| 21:51:00 | Watusimoto | maybe there is a glMode that will do this... |
| 21:52:00 | | koda Quit (Quit: koda) |
| 21:53:00 | sam686 | i don't think glMode oe other GL stuff might do for orange,gray, brown, and other non-primary light colors (red, green, blue) |
| 21:53:00 | | koda has joined |
| 21:54:00 | sam686 | maybe, they could be rendered off-screen, one per team, then blend into screen.. |
| 21:57:00 | karamazovapy | rgb works for some values, but not for others |
| 21:57:00 | karamazovapy | what if each team had its own fill pattern? |
| 21:58:00 | Watusimoto | might need one of these |
| 21:58:00 | Watusimoto | http://www.opengl.org/sdk/docs/man/xhtml/glBlendFunc.xml |
| 21:58:00 | Watusimoto | not sure, need to try and error |
| 21:58:00 | Watusimoto | I dislike fill patterns!!! |
| 21:58:00 | karamazovapy | I dislike kooky blending more |
| 21:59:00 | sam686 | fill patterns might look ugly at low resolutions, i think (640 x 480 or less) |
| 22:00:00 | karamazovapy | you might look ugly at low resolutions |
| 22:01:00 | sam686 | another way is to do some kind of smart overlap calculation, but only render one time transparently... |
| 22:02:00 | sam686 | or maybe make use of z-buffer to prevent overlap semi- transparent rendering of same team.. |
| 22:02:00 | Watusimoto | I'm not really concerned with low-res editing |
| 22:02:00 | Watusimoto | I don't think it's a use case we need to consider |
| 22:03:00 | Watusimoto | I was thinking about doing a merge of the polygons, somehow |
| 22:07:00 | Watusimoto | could run the polys through clipper |
| 22:07:00 | Watusimoto | to generate one merged polygon per team |
| 22:07:00 | Watusimoto | then draw those with transluceny |
| 22:12:00 | | raptor has joined |
| 22:12:00 | | ChanServ sets mode +o raptor |
| 22:14:00 | | BFLogBot - Commit 05d0b6ead2a2 | Author: sam8641 | Log: Fix Pick up flags through barrier, Make SpeedZone snap work even when partially on wall |
| 22:14:00 | raptor | sam686: did you really just make plumbing work? |
| 22:15:00 | sam686 | well, what else should it work? |
| 22:15:00 | Watusimoto | I looked at that speedzone video posted a while back, and didn't see the problem |
| 22:16:00 | Watusimoto | you presented three cases |
| 22:16:00 | Watusimoto | the first, where you bounced back into the wall, was obviously broken |
| 22:16:00 | sam686 | turning on snapping causes speedzone not to work on 015a, thats the fix i kind of done... |
| 22:16:00 | sam686 | if speedzone is partially on the wall |
| 22:16:00 | Watusimoto | the second case seemed to work great |
| 22:17:00 | Watusimoto | the thrid, where you missed the slot, seemed to be broken |
| 22:17:00 | Watusimoto | but what was wrong with the second case? |
| 22:17:00 | Watusimoto | you always hit the slot |
| 22:18:00 | Watusimoto | it seemed that the video suggested that was the current version |
| 22:18:00 | Watusimoto | and that the thrid case, where you misseed the slot, was a proposed fix |
| 22:18:00 | sam686 | so, a new snapping option instead? |
| 22:19:00 | Watusimoto | no, sorry |
| 22:19:00 | Watusimoto | I'm referring to the three examples in the video link you posted a few days ago |
| 22:19:00 | Watusimoto | but I can't produce the url |
| 22:19:00 | sam686 | SpeedZone.cpp line 407 thats where we can enable the speedzone snap only when lined up.. |
| 22:20:00 | raptor | http://www.youtube.com/watch?v=_xAlDRarlUM |
| 22:20:00 | Watusimoto | a man a plan a canal panama |
| 22:20:00 | Watusimoto | so the "currently on 015a" case looks like it works right |
| 22:21:00 | raptor | http://www.azlyrics.com/lyrics/weirdalyankovic/bob.html |
| 22:21:00 | raptor | i like 'No x in Nixon' |
| 22:22:00 | sam686 | so what are you going to do with http://code.google.com/p/bitfighter/issues/detail?id=140 ? as a "Won't fix" or what? |
| 22:23:00 | sam686 | i can easily revert back to how 015a have it for snapping.. |
| 22:23:00 | raptor | i figure sam's third case is: if my ship cannot snap (because of a wall in the way) just propell at the same vector where it hits anyways |
| 22:23:00 | Watusimoto | what was the problem with it? |
| 22:24:00 | sam686 | as sky_lark put a picture up, http://i.imgur.com/Gx3gJ.png doesn't work with snapping on in 015a |
| 22:25:00 | Watusimoto | ok, so your theory is that if you can't get to the center of the gofast (due to wall), snapping should not occur? |
| 22:25:00 | sam686 | kind of, or more like, get to as close to snapping as possible.. |
| 22:26:00 | raptor | right now if you cannot get to the center and snapping is enabled, you are not propelled |
| 22:26:00 | raptor | sam686 |
| 22:26:00 | raptor | 's solution: propel at same vector anyways at current location |
| 22:26:00 | Watusimoto | is that true? doesn't 2nd video show snapping with inability to get to center? |
| 22:27:00 | raptor | yes, the issue is that if snapping is enable and center in unreachable no propulsion |
| 22:27:00 | raptor | is unreachable, no propulsion occurs |
| 22:28:00 | Watusimoto | i contend that if snapping is on, you should always end up in the same place |
| 22:28:00 | Watusimoto | that is, after all, the point |
| 22:28:00 | sam686 | from what the old Zap had it, it looks like it doesn't snap, but sets velocity to zero when hitting speedZone |
| 22:28:00 | Watusimoto | I'm less concerned with when gofast is effectivley disabled because it's partially blcoked |
| 22:29:00 | Watusimoto | old zap didn;t have snapping |
| 22:29:00 | raptor | my idea was have a third speedzone option: lock vector |
| 22:29:00 | Watusimoto | what does that do? |
| 22:29:00 | raptor | makes sure you go in the direction of the speedzone no matter at what angle you hit it |
| 22:30:00 | sam686 | old zap appears to just throw away old velocity, preventing drifting from coming into speedzone from the side when snap is off... |
| 22:30:00 | sam686 | bitfighter speedzone, just adds on velocity when snap is off.. |
| 22:31:00 | raptor | 'lock direction' may be better |
| 22:32:00 | karamazovapy | this problem only currently exists for one level, since it's a slightly ridiculous application |
| 22:34:00 | Watusimoto | I'm surprised there's even one |
| 22:34:00 | Watusimoto | probably a dungeon |
| 22:34:00 | karamazovapy | nope an old zap level called Plumbing |
| 22:34:00 | sam686 | not a dungeon... |
| 22:34:00 | karamazovapy | from when speedzones functioned differently |
| 22:35:00 | Watusimoto | well my point is this, and only this: when snap is on, you should end up in a predefined lcoation, regardless of how you hit the speedzone |
| 22:36:00 | Watusimoto | the thrid example in the video seemed to voilate that |
| 22:36:00 | sam686 | but Plumbing level, that problem in bitfighter doesn't really kill gameplay, all flags have been gotten before... |
| 22:36:00 | karamazovapy | the issue is what the behavior should be when the center of the speed zone is blocked by a barrier |
| 22:36:00 | sam686 | also, another problem is with "Armor" and speedzone go a lot farther.. |
| 22:37:00 | raptor | is that a problem? |
| 22:37:00 | raptor | armor adds more 'momentum' |
| 22:37:00 | Watusimoto | if you want to talk physics, it is a problem |
| 22:37:00 | sam686 | well, armor can make it much harder to control in Plumbing level, expecially when hitting speedzone |
| 22:38:00 | Watusimoto | if you want to talk gameplay, that's a different question |
| 22:38:00 | Watusimoto | maybe we need an adjustment factor to the speed added when you ahve armor, so you end up in the same location |
| 22:38:00 | Watusimoto | you get flung less fast, but travel further |
| 22:38:00 | Watusimoto | balancing out in the end |
| 22:39:00 | sam686 | as for speed zone snapping, better to just keep using the 015a way of snapping and won't fix the problem in the google code bug? |
| 22:39:00 | raptor | physics shmisics |
| 22:39:00 | raptor | or not think of it as a snapping issue and add 'lock direction' - which could be used in other cases |
| 22:40:00 | raptor | or ignore |
| 22:40:00 | raptor | keep calm and carry on |
| 22:41:00 | sam686 | thats a lot of "OR", which one to go with? |
| 22:41:00 | Watusimoto | which bug? |
| 22:41:00 | Watusimoto | 140? |
| 22:41:00 | sam686 | http://code.google.com/p/bitfighter/issues/detail?id=140 yes |
| 22:42:00 | sam686 | turn off snapping, and you can use speedzone even when partially on the wall... |
| 22:43:00 | Watusimoto | is it essentially a question of when collision occurs? |
| 22:44:00 | Watusimoto | actually, maybe not, as snapping doesn't change the collisino calculations |
| 22:44:00 | raptor | snapping normalizes the vector, which is what he wants |
| 22:44:00 | Watusimoto | it does seem that in that second pic, you should be going fast |
| 22:44:00 | sam686 | the way 015a works for snapping, if ships cannot line up, ships can't speed up. is snap is off, then ships can speed up... |
| 22:44:00 | raptor | i.e. no addition of approach vector to the propulsion |
| 22:45:00 | Watusimoto | so because you can't "snap into poisition", you just don't go? |
| 22:45:00 | karamazovapy | yes |
| 22:45:00 | Watusimoto | what if we disabled wall collisions for the snap phase? |
| 22:46:00 | sam686 | go through walls problem... |
| 22:46:00 | karamazovapy | that might be the way it was in 014 where you could get trapped |
| 22:46:00 | raptor | that was 014 |
| 22:46:00 | Watusimoto | oh |
| 22:46:00 | raptor | yes and much trapping occured |
| 22:46:00 | Watusimoto | that was the first video |
| 22:46:00 | sam686 | each way have a problem, it seems... |
| 22:47:00 | karamazovapy | the vector lock isn't a bad solution, I just don't see it as a serious problem to begin with |
| 22:47:00 | Watusimoto | well, if you snap onto the wall, then get flung, being on the wall shouldn;t make a pro... |
| 22:47:00 | Watusimoto | WHO THE HELL MAKES THESE LEVELS?!??!??! |
| 22:47:00 | karamazovapy | that was hamster, back in the day |
| 22:47:00 | Watusimoto | JUST MAKE A NORMAL LEVEL, AND IT WILL BE FINE |
| 22:48:00 | raptor | this is a backwards-compatibility issue |
| 22:48:00 | karamazovapy | well it's the only implementation of the problem I've ever seen |
| 22:48:00 | raptor | me too |
| 22:49:00 | Watusimoto | looks liek the 014 problem was snapping without going fast |
| 22:49:00 | karamazovapy | the quick fix would be to shift the speedzones just a tiny bit off the barriers |
| 22:49:00 | karamazovapy | I assume they work correctly if the centerline gets moved |
| 22:50:00 | karamazovapy | maybe not? |
| 22:51:00 | sam686 | i would probably make speedzone like 015a, where ships can't use speedzone until ships can snap and line up, to stay the same as 015a.. |
| 22:51:00 | Watusimoto | fine by me |
| 22:51:00 | karamazovapy | looks like even a slight parallel overlap of barrier and sz makes it useless |
| 22:52:00 | raptor | yep |
| 22:52:00 | sam686 | so, http://code.google.com/p/bitfighter/issues/detail?id=140 would need to close with a reason, as a "won't fix"? |
| 22:53:00 | Watusimoto | how about: MAKE A NORMAL LEVEL!!!!! |
| 22:54:00 | Watusimoto | or, perhaps more politic: Hard to fix, obsure case, too much work for the benefit |
| 22:54:00 | raptor | I can create that one... |
| 22:54:00 | Watusimoto | or we can defer to 017 :-) |
| 22:54:00 | raptor | the magic wand of procrastination! |
| 22:59:00 | sam686 | so there, I have undo my speedzone change. 2863 (af72071519c0) Issue 140 will be delayed or won't be fixed. |
| 22:59:00 | | BFLogBot - Commit af72071519c0 | Author: sam8641 | Log: Issue 140 will be delayed or won't be fixed. |
| 23:14:00 | Watusimoto | falling asleep... see y'all tomorrow |
| 23:14:00 | raptor | night |
| 23:19:00 | Watusimoto | tomorrow I'm going to solve the overlapping spybug problem using clipper in union mode |
| 23:19:00 | Watusimoto | GL_ONE |
| 23:19:00 | Watusimoto | http://www.cs.man.ac.uk/~toby/alan/software/gpc.html |
| 23:22:00 | raptor | i remember studying this... |
| 23:22:00 | raptor | for a long slog through nav mesh zone land |
| 23:24:00 | | Watusimoto Quit (Ping timeout: 258 seconds) |
