Timestamps are in GMT/BST.
| 00:00:00 | | BFLogBot - Commit 135fbbec25ce | Author: watusim...@bitfighter.org | Log: Strip out some old cruft |
| 00:00:00 | | BFLogBot - Commit d43b49d972ae | Author: watusim...@bitfighter.org | Log: Var name |
| 00:00:00 | | BFLogBot - Commit 8b22f15d706a | Author: watusim...@bitfighter.org | Log: Better logging target |
| 00:00:00 | | BFLogBot - Commit 06622654efbb | Author: watusim...@bitfighter.org | Log: Improved text |
| 00:00:00 | Watusimoto | if you haven;t fixed this when I check in tomorrow, I can take care of it |
| 00:00:00 | | BFLogBot - Commit 95cffa71e6cd | Author: watusim...@bitfighter.org | Log: Get rid of some casts |
| 00:00:00 | | BFLogBot - Commit 6fb1a5ca558f | Author: watusim...@bitfighter.org | Log: Convert a bunch of dynamic_casts to static_casts |
| 00:00:00 | | BFLogBot - Commit 085358bec6e4 | Author: watusim...@bitfighter.org | Log: Get rid of some more casts |
| 00:00:00 | | BFLogBot - Commit b5d75a19908e | Author: watusim...@bitfighter.org | Log: Kill a whole bunch more dynamic_casts |
| 00:00:00 | | BFLogBot - Commit 3c176834f25b | Author: watusim...@bitfighter.org | Log: Merge |
| 00:00:00 | sam686 | i will need to go, will be back in maybe an hout |
| 00:00:00 | sam686 | hour |
| 00:00:00 | Watusimoto | see you |
| 00:01:00 | sam686 | later.. |
| 00:09:00 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 00:12:00 | | Watusimoto Quit (Ping timeout: 276 seconds) |
| 00:18:00 | | Little_Apple has joined |
| 00:20:00 | | Little_Apple Quit (Client Quit) |
| 00:21:00 | | Little_Apple has joined |
| 00:21:00 | Little_Apple | Sauce! |
| 00:23:00 | Little_Apple | Moo? |
| 00:23:00 | Little_Apple | Layers |
| 00:23:00 | | Little_Apple Quit (Client Quit) |
| 00:25:00 | | raptor has joined |
| 00:25:00 | | ChanServ sets mode +o raptor |
| 00:29:00 | | koda Quit (Quit: koda) |
| 00:48:00 | raptor | karamazovapy: what would you think of a slightly different burst render - instead if the center blinking, it would fade out or in? |
| 01:18:00 | raptor | !bug |
| 01:18:00 | BFLogBot | To enter a bug, please make sure it is reproducible and then go to http://code.google.com/p/bitfighter/issues/list | Also, see current buglist for 016: http://bitfighter.org/wiki/index.php?title=Buglist_016 |
| 03:59:45 | | -adams.freenode.net- *** Looking up your hostname... |
| 03:59:45 | | -adams.freenode.net- *** Checking Ident |
| 03:59:45 | | -adams.freenode.net- *** No Ident response |
| 03:59:45 | | -adams.freenode.net- *** Couldn't look up your hostname |
| 03:59:50 | | BFLogBot has joined |
| 03:59:50 | | Topic is 'Latest release 015a http://bitfighter.org | Forums: http://bitfighter.org/forums/ | GC Project: http://code.google.com/p/bitfighter/' |
| 03:59:50 | | Set by raptor!~raptor@unaffiliated/greenmachine on Sun May 01 05:51:58 GMT 2011 |
| 03:59:50 | | -ChanServ- [#bitfighter] Welcome to #bitfighter. This is an IRC channel, many or all of the users may not be paying attention. Please have patience when waiting for a response. |
| 04:00:14 | - *raptor* !hel | *raptor* !help |
| 04:00:17 | - *raptor* !command | *raptor* !commands |
| 04:00:41 | raptor | !help |
| 04:00:41 | BFLogBot | type !commands to see a list of commands |
| 04:02:53 | | -adams.freenode.net- *** Looking up your hostname... |
| 04:02:53 | | -adams.freenode.net- *** Checking Ident |
| 04:02:53 | | -adams.freenode.net- *** Couldn't look up your hostname |
| 04:02:53 | | -adams.freenode.net- *** No Ident response |
| 04:02:56 | | BFLogBot has joined |
| 04:02:56 | | Topic is 'Latest release 015a http://bitfighter.org | Forums: http://bitfighter.org/forums/ | GC Project: http://code.google.com/p/bitfighter/' |
| 04:02:56 | | Set by raptor!~raptor@unaffiliated/greenmachine on Sun May 01 05:51:58 GMT 2011 |
| 04:02:57 | | -ChanServ- [#bitfighter] Welcome to #bitfighter. This is an IRC channel, many or all of the users may not be paying attention. Please have patience when waiting for a response. |
| 04:08:10 | | -niven.freenode.net- *** Looking up your hostname... |
| 04:08:10 | | -niven.freenode.net- *** Checking Ident |
| 04:08:11 | | -niven.freenode.net- *** No Ident response |
| 04:08:11 | | -niven.freenode.net- *** Couldn't look up your hostname |
| 04:08:15 | | BFLogBot has joined |
| 04:08:15 | | Topic is 'Latest release 015a http://bitfighter.org | Forums: http://bitfighter.org/forums/ | GC Project: http://code.google.com/p/bitfighter/' |
| 04:08:15 | | Set by raptor!~raptor@unaffiliated/greenmachine on Sun May 01 05:51:58 GMT 2011 |
| 04:08:15 | | -ChanServ- [#bitfighter] Welcome to #bitfighter. This is an IRC channel, many or all of the users may not be paying attention. Please have patience when waiting for a response. |
| 04:20:10 | raptor | hello |
| 04:20:49 | sam686 | |-| E |_ |_ O |
| 04:21:01 | raptor | ha! |
| 04:21:18 | raptor | i changed the log files to have seconds and be a little cleaner: http://199.192.229.168/irclogs/index.php?date=2012-01-17 |
| 04:21:58 | raptor | the lines don't wrap... i'll have to work on that.. |
| 04:22:11 | raptor | say - did you ever fix the bot problem? |
| 04:23:22 | sam686 | almost done fixing.. |
| 04:23:47 | raptor | is it a complex fix? |
| 04:23:58 | raptor | nevermind - i'll let you get to work.. |
| 04:27:16 | sam686 | compiling.... compile compiling... waiting... |
| 04:29:40 | | raptor is twiddling his thumbs |
| 04:29:43 | sam686 | still waiting for compiler to get done, i had to update and merge, and test... |
| 04:31:28 | sam686 | linking.. still waiting |
| 04:31:58 | sam686 | time to test, its done compiling |
| 04:35:06 | sam686 | seems to work now.. |
| 04:35:31 | raptor | hooray! |
| 04:38:29 | | BFLogBot - Commit 94c964658f63 | Author: sam8641 | Log: Fix robot tick event calling 100 onTick for all 10 bots |
| 04:46:42 | raptor | sam686: do the bots move with spawnshield? |
| 04:52:36 | sam686 | seems like bots move with spawn shield on.. |
| 04:54:45 | sam686 | or maybe not? |
| 04:54:57 | raptor | seems like it happens on the first spawn? |
| 04:58:33 | sam686 | now i am finding robots get stuck when trying to cross the forcefields (even it's own team forcefield) |
| 05:00:27 | sam686 | robots keeps spawn shield while moving and shooting, might be a bug, but only seems to happens on robot first spawn |
| 05:02:08 | raptor | well, the game runs much better now... |
| 05:02:22 | raptor | ah, i see them stuck on forcefields too... |
| 05:03:10 | sam686 | it thinks forcefield is a wall, so it doesn't try to cross them |
| 05:03:20 | sam686 | but the bot paths tell them to go through them |
| 05:05:20 | raptor | do you know where the test is that it's using? |
| 05:05:29 | raptor | it's probably a bad test in gameObject.cpp |
| 05:09:42 | sam686 | . /showpaths /showzones ... |
| 05:13:37 | sam686 | hey, join my 016 "sam test" at the moment |
| 05:13:55 | sam686 | there might be a spawn shield go away bug faster then usual... |
| 05:14:11 | raptor | ok |
| 05:16:28 | sam686 | id you heard that crazy core sound? |
| 05:16:46 | raptor | oh no, i had the sound off... |
| 05:17:32 | sam686 | it was crazy sound with all that cores... |
| 05:18:38 | raptor | arranged connection not working? |
| 05:28:01 | sam686 | it seems like my debug build went buggy and needed a full rebuild... |
| 05:31:13 | raptor | your latest revision fixing the bot error is what introduced the spawnshield problem... |
| 05:31:34 | raptor | i mean with bots able to move with it on first spawn |
| 05:37:44 | sam686 | fixed the super fast spawn shield counting down too fast... |
| 05:38:28 | raptor | oh good |
| 05:53:38 | | BFLogBot - Commit 364f493137e4 | Author: sam8641 | Log: Fix spawn shield going counting too fast client side, fix robot shield won't turn off |
| 05:55:27 | raptor | ha! i think that's how we originally programmed the spawnshield |
| 05:55:55 | sam686 | it is still counting down on client side... |
| 05:56:20 | sam686 | there is "ClientIdleControlMain" and there is "ClientIdleControlReplay" |
| 05:56:57 | sam686 | "ClientIdleControlReplay" is used when the client receives the position, and have to go forward (replay) ahead of time due to Lag |
| 05:57:16 | sam686 | or high ping lag.. |
| 05:58:13 | raptor | ah |
| 05:59:10 | sam686 | midnight... i should go get some sleep now... |
| 05:59:38 | raptor | good night |
| 07:01:53 | | raptor Quit (Remote host closed the connection) |
| 07:14:27 | | sam686 Quit (Ping timeout: 245 seconds) |
| 10:33:31 | | CrazyLinuxNerd has joined |
| 11:31:46 | | LordDVG has joined |
| 14:29:02 | | watusimoto has joined |
| 14:29:03 | | ChanServ sets mode +o watusimoto |
| 15:17:47 | | raptor has joined |
| 15:17:47 | | ChanServ sets mode +o raptor |
| 15:17:58 | raptor | buenos |
| 15:26:45 | | raptor Quit (Remote host closed the connection) |
| 15:32:01 | | LordDVG Quit (Ping timeout: 252 seconds) |
| 15:42:53 | | LordDVG has joined |
| 16:35:57 | | raptor has joined |
| 16:35:58 | | ChanServ sets mode +o raptor |
| 16:36:13 | raptor | so i gave issue 88 a shot last night |
| 16:36:19 | raptor | lots of weird behavior |
| 16:38:18 | raptor | eats shoots and leaves |
| 16:38:23 | raptor | eats, shoots and leaves |
| 16:38:29 | raptor | eats, shoots, and leaves |
| 16:41:13 | watusimoto | which is 88? |
| 16:45:34 | raptor | hi |
| 16:45:38 | raptor | engineer abuse |
| 16:46:17 | raptor | i created a rect around the field that was a ship widths on either side of field |
| 16:46:35 | raptor | then did a search for all wall types |
| 16:46:35 | watusimoto | good idea |
| 16:47:00 | watusimoto | you'll still need to check for intersections in the rect |
| 16:47:06 | watusimoto | and you can't use a rect object |
| 16:47:09 | raptor | and used polygon intersect with all the walls |
| 16:47:14 | watusimoto | right |
| 16:47:23 | raptor | yes, i made the rect into a polygon |
| 16:47:32 | watusimoto | ok, also be careful about the end of the ff, which does touch a wall, legitimately |
| 16:47:42 | watusimoto | a rect, but not a Rect |
| 16:47:57 | raptor | let me show you my horrid code: |
| 16:48:03 | watusimoto | a 4 pointed polygon with 90degree corners |
| 16:48:15 | watusimoto | do I want to see this? |
| 16:48:28 | raptor | no: http://pastie.org/3202261 |
| 16:48:30 | raptor | but |
| 16:49:16 | raptor | so yes, i test if polygons intersect - each wall with the rect i made |
| 16:49:33 | raptor | maybe it's the end of the forcefield that is making it difficult... |
| 16:49:42 | watusimoto | I think queryRect is defined wrong -- pas all points into it to get a true bounding box |
| 16:50:09 | watusimoto | I think there is a rect constructor that takes a point of vectors and computes a bounding box around it |
| 16:50:17 | watusimoto | if not, there should be |
| 16:50:34 | raptor | ahh... ok, a Rect is *always* a rectangle along x/y axis, correct? |
| 16:50:38 | raptor | i mean parallel |
| 16:50:40 | watusimoto | yes |
| 16:50:44 | raptor | ah, yes |
| 16:50:50 | watusimoto | is that yourproblme? |
| 16:50:58 | raptor | that sure looks like it.. |
| 16:51:05 | raptor | let me fix and see if the behavior improves |
| 16:51:14 | watusimoto | that's why I tried to clarify what you meant by rect :-) |
| 16:51:48 | raptor | sounds good... i keep telling myself i should stop coding late a night... |
| 16:51:49 | watusimoto | take the ff start point and endpoint, and expand that by ship's width + ff width |
| 16:51:58 | watusimoto | but make it no longer |
| 16:52:00 | raptor | stuff makes so much more sense in the middle... |
| 16:52:06 | raptor | in the morning, i mean |
| 16:52:07 | watusimoto | :-) |
| 16:52:33 | raptor | yes, i did that |
| 16:52:34 | watusimoto | then compute the boundingbox to select items from the db, and I think your code will work pretty well |
| 16:52:51 | watusimoto | it's not badly structured, just has a small bug :-) |
| 16:53:07 | raptor | bugs must be squished |
| 16:53:21 | watusimoto | yes, indeed |
| 17:00:59 | watusimoto | did the bot performance improve with sam's fix? |
| 17:01:06 | raptor | oh yes, tremendously |
| 17:01:20 | raptor | i'm not worried anymore |
| 17:01:27 | watusimoto | well, either that, or my dynamic_cast fixes! |
| 17:01:54 | raptor | i am sorry to be the bearer of bad news, but i tested directly before and afterwards... |
| 17:02:02 | raptor | and sam's was the ticket :) |
| 17:02:26 | watusimoto | phooey |
| 17:02:54 | watusimoto | it was both an obvious bug and a very subtle one |
| 17:03:02 | watusimoto | I was thinking today how I would have found it |
| 17:03:09 | watusimoto | and I'm not sure I would have |
| 17:03:34 | watusimoto | there were no obvious signs, and the bots would work the same with or without it |
| 17:03:44 | raptor | engineered forcefields can't be killed... |
| 17:03:53 | raptor | rats |
| 17:04:03 | raptor | yeah, i wasn't sure where the bug was either |
| 17:04:16 | watusimoto | glad he found it |
| 17:04:20 | watusimoto | he's got a keen eye |
| 17:04:28 | raptor | for sure |
| 17:05:00 | watusimoto | ok, gotta run |
| 17:05:04 | raptor | ok |
| 17:05:08 | raptor | later |
| 17:05:10 | watusimoto | will try to get that editor bug fixed tonight |
| 17:05:22 | raptor | ok |
| 17:05:35 | raptor | quick question - do you know by how much the forcefield end overlaps? |
| 17:06:29 | raptor | this is my test level: http://sam686.maxhushahn.com/upload/1screenshot_16.png |
| 17:07:31 | raptor | well i'll ask later |
| 17:10:11 | | watusimoto Quit (Ping timeout: 276 seconds) |
| 17:42:02 | | Watusimoto has joined |
| 17:51:15 | raptor | i think java logging will be the death of me |
| 17:51:40 | Watusimoto | I doubt it -- properties will kill you first |
| 17:51:52 | raptor | oh no - i've master properties last year |
| 17:52:01 | raptor | err, lost 1 life to it, i mean |
| 17:52:22 | Watusimoto | not when they're used the way we used them at my last job |
| 17:52:35 | Watusimoto | they made C macros look sane |
| 17:52:39 | raptor | oh no |
| 17:52:43 | raptor | that's horrible |
| 17:53:17 | raptor | can i show you where i am with engineer? |
| 17:53:22 | Watusimoto | sure |
| 17:53:29 | raptor | here is my lovely test level: http://sam686.maxhushahn.com/upload/1screenshot_16.png |
| 17:53:42 | Watusimoto | ok |
| 17:53:57 | raptor | the forcefield i'm pointing at doesn't work the other way |
| 17:54:08 | raptor | if the projector were at the other end, i mean |
| 17:54:09 | karamazovapy | I wonder if I could turn #3 into a levelgen: http://www.npr.org/blogs/krulwich/2012/01/10/144991340/don-t-make-me-do-this-the-equations-screamed?ps=cprs |
| 17:54:46 | Watusimoto | @r, is there more coming, or is that screenshot all you wanted to show me |
| 17:55:23 | raptor | this is the code now: i fed the poly into queryRect like you suggested: http://pastie.org/3202593 |
| 17:55:36 | raptor | karamazovapy: ha! |
| 17:57:27 | Watusimoto | crossVec.normalize(2 * Ship::CollisionRadius + 1); will also need width of ff itself in it |
| 17:58:32 | Watusimoto | so what works? do you get the rectangle you expect in your print? |
| 17:59:06 | raptor | yes |
| 17:59:14 | raptor | for better reference: http://sam686.maxhushahn.com/upload/1screenshot_17.png |
| 17:59:23 | raptor | red arrow - should work but doesn't |
| 17:59:33 | raptor | green arrow deploy disallowed OK |
| 17:59:49 | Watusimoto | code looks ok |
| 18:00:26 | Watusimoto | what do your arrows mean again? various deploy locations? |
| 18:00:28 | karamazovapy | what's happening with engineer? new rules to make it harder to break levels? |
| 18:00:43 | raptor | green = should disallow deploy, and it does |
| 18:00:49 | Watusimoto | yes -- no ffs within a ship's distance of a wall |
| 18:00:51 | raptor | red = should allow deploy, but it doesn't |
| 18:01:10 | Watusimoto | ok |
| 18:01:24 | raptor | so all the reds are problems - my code seems OK right now |
| 18:01:25 | Watusimoto | I'd suggest drawing the various parts you're calculating to see what actually hits |
| 18:01:38 | raptor | explain |
| 18:02:06 | karamazovapy | maybe you're not seeing problems where they really do exist |
| 18:02:29 | Watusimoto | uh... copy your rectangle generating code into the ff render function and see if you're getting the rectangle you expect |
| 18:02:43 | raptor | ah, ok |
| 18:02:53 | Watusimoto | you'll be able to see any wayward intersectionst that you're not considering |
| 18:03:58 | karamazovapy | I don't understand why some of those green arrows should be disallowed |
| 18:04:26 | Watusimoto | if ff "grazes" a wall, it is disallowed |
| 18:04:28 | karamazovapy | I mean logically, not mathematically |
| 18:04:46 | Watusimoto | it must be one ship width from any wall except where it starts and ends |
| 18:04:48 | raptor | karamazovapy: yes, those are edge cases that i'll need to handle afterwards |
| 18:05:09 | Watusimoto | we'll end up disallowing some seemingly legitmiate cases |
| 18:05:18 | karamazovapy | oh, okay |
| 18:05:25 | Watusimoto | but I think it will eliminate impossible levels |
| 18:05:39 | karamazovapy | oh how the tweens will weep |
| 18:06:01 | Watusimoto | maybe we need a setting "allow_impossible_levels" |
| 18:06:54 | raptor | i was thinking of the weeping tweens last night, too |
| 18:07:50 | Watusimoto | damn! even a paused s_bot killed me |
| 18:08:21 | karamazovapy | I find it frustrating that the younger players gravitate toward the most "broken" aspects of the game |
| 18:09:58 | Watusimoto | yes, well... |
| 18:10:07 | Watusimoto | everyone likes hacks |
| 18:13:53 | raptor | ok, picture time: |
| 18:14:06 | raptor | http://sam686.maxhushahn.com/upload/1screenshot_18.png |
| 18:14:36 | raptor | maybe my issue is just that i need to reduce the that collision poly slightly from the end.. |
| 18:15:15 | raptor | like maybe a ship's width from the end... |
| 18:15:18 | Watusimoto | ok |
| 18:15:26 | Watusimoto | try that |
| 18:16:09 | raptor | do we have a method for reducing a segment along the same line a certain amount? |
| 18:17:10 | Watusimoto | not as such... |
| 18:17:23 | Watusimoto | I can't think of an easy way to do it with what we've got |
| 18:17:54 | Watusimoto | can we move a point in a certain driecion a certain distance? |
| 18:17:59 | Watusimoto | we have the direction |
| 18:18:09 | raptor | maybe point.normalize() |
| 18:19:11 | Watusimoto | I see nothing in geomUtils |
| 18:19:19 | Watusimoto | I don't think point.norm will work |
| 18:19:27 | Watusimoto | that will move it towards (0,0) |
| 18:20:00 | Watusimoto | so you could pre-offset, normalize, un-pre-offset |
| 18:20:19 | Watusimoto | but by that point, you might as well just do it with sin/cos |
| 18:21:48 | Watusimoto | how strange... a paused bot will sometimes miss when stepped forward |
| 18:21:53 | Watusimoto | if I'm not moving |
| 18:21:59 | Watusimoto | I'd expect it to always hit |
| 18:22:10 | raptor | sam built in an error factor |
| 18:22:15 | Watusimoto | ah |
| 18:22:20 | Watusimoto | thanks for saving me a ton of time |
| 18:22:26 | raptor | s_bot is usually really accurate though |
| 18:22:31 | Watusimoto | it is |
| 18:22:50 | raptor | though it can be set to very innacurate - i told him he should release a modification called 'spaz_bot' |
| 18:23:09 | Watusimoto | when so close, even inaccurate bots can be damaging |
| 18:23:11 | raptor | because it shoots just as fast but misses by 120 degrees... |
| 18:23:15 | Watusimoto | ha |
| 18:23:25 | Watusimoto | maybe he should code a restriction on turn speed |
| 18:24:22 | Watusimoto | whoever thought my orbitbot had a future? |
| 18:24:29 | Watusimoto | all serious bots since then have orbited |
| 18:25:42 | raptor | he's the grand-daddy |
| 18:41:50 | raptor | i got the math! |
| 18:41:59 | raptor | it was with normalize() |
| 18:42:10 | Watusimoto | great! |
| 18:49:23 | raptor | picture!: http://sam686.maxhushahn.com/upload/screenshot_19.png |
| 18:49:37 | raptor | all angled barriers are at exactly 45 degrees |
| 18:49:43 | raptor | relatively |
| 18:50:01 | raptor | it seems like that angle ones work about 75% of the time |
| 18:51:27 | Watusimoto | well, that's an improvement. |
| 18:51:44 | Watusimoto | getting false rejections or false acceptances |
| 18:51:46 | Watusimoto | ? |
| 18:51:52 | raptor | for instance, the yellow arrows here don't work: http://sam686.maxhushahn.com/upload/screenshot_20.png |
| 18:52:01 | raptor | no false acceptances |
| 18:52:15 | karamazovapy | <Watusimoto> all serious bots since then have orbited |
| 18:52:20 | karamazovapy | all serious players orbit! |
| 18:52:30 | Watusimoto | ha |
| 18:52:34 | Watusimoto | stole my strategy |
| 18:53:25 | Watusimoto | I think walls at a more acute angle will be a problem |
| 18:54:20 | Watusimoto | it would be nice to see the bounding boxes for rejected ffs... perhaps you can disable rejection and see what bbs we get for the yellow arrows |
| 18:55:00 | raptor | yes ok |
| 18:58:16 | raptor | http://sam686.maxhushahn.com/upload/screenshot_21.png |
| 18:58:23 | raptor | ^^ those are the boxes for rejected ones |
| 18:58:31 | raptor | my guess is that it's a matter of 1 px off |
| 19:00:05 | Watusimoto | I concur |
| 19:00:06 | Watusimoto | but |
| 19:00:16 | Watusimoto | if those angles are any steeper, they'll be more than 1 pix off |
| 19:00:26 | raptor | yes |
| 19:00:33 | raptor | so, where do we stand now? |
| 19:00:46 | raptor | this is probably a little better than not having wall detection |
| 19:00:47 | Watusimoto | does it make sense to completely discount segment on which ff terminates? |
| 19:00:55 | Watusimoto | that is easy to get and exclude from the checks |
| 19:01:13 | raptor | not sure, i bet karamazovapy could come up with appropriate scenarios |
| 19:01:35 | Watusimoto | better yet, we throw something out there and let little_apple use it |
| 19:01:37 | raptor | but it'd have to be segment, not barrier |
| 19:01:40 | Watusimoto | yes |
| 19:01:44 | raptor | haha |
| 19:01:44 | karamazovapy | what's that? |
| 19:01:47 | Watusimoto | that's all we can have, anyway |
| 19:02:02 | Watusimoto | trying to figure out which ffs create impossible game |
| 19:02:05 | Watusimoto | s |
| 19:02:27 | karamazovapy | oh - you also want to check for turrets that block off ffs |
| 19:02:29 | raptor | karamazovapy: would it be good to exclude the terminating wall segment from a forcefields search |
| 19:02:45 | karamazovapy | not sure what you're asking |
| 19:02:59 | raptor | so when a forcefield ends, it hits a barrier |
| 19:03:06 | karamazovapy | yes |
| 19:03:11 | Watusimoto | I'm going to draw some examples in the editor |
| 19:03:27 | raptor | with my new logic, i search for all barriers around the forcefield and disallow the ff if it is too close |
| 19:03:38 | karamazovapy | right |
| 19:03:53 | raptor | my question was if we should ignore the terminating barrier from that search for walls around the ffs |
| 19:04:12 | raptor | that way we could ignore steeper angles and such |
| 19:04:22 | karamazovapy | oh, the barrier the forcefield lands on? |
| 19:04:25 | raptor | yes |
| 19:04:54 | raptor | because some of these wouldn't work if the barrier was at a steeper angle: http://sam686.maxhushahn.com/upload/screenshot_21.png |
| 19:04:54 | karamazovapy | what if the barrier is continuous and creates a "breaky" scenario? |
| 19:05:21 | raptor | well, we would only ignore the one straight segment piece that the ff lands on |
| 19:05:41 | raptor | brb.. |
| 19:06:36 | karamazovapy | what if it's a curve? |
| 19:07:40 | Watusimoto | curves are a bunch of short segments |
| 19:07:47 | Watusimoto | we're only discussing actual 2-pt segment |
| 19:07:54 | karamazovapy | oh, okay |
| 19:07:57 | karamazovapy | not the full barrier |
| 19:08:14 | karamazovapy | I kind of thought that might be the case |
| 19:09:04 | karamazovapy | I see no reason to worry about the terminating barrier |
| 19:09:30 | karamazovapy | although you should probably put turrets into your ship-width search |
| 19:11:07 | raptor | ok, consensus about the walls? |
| 19:11:21 | karamazovapy | I'm with you |
| 19:11:33 | raptor | search for wall segments instead of walls, then ignore the ff terminating from the search |
| 19:11:44 | raptor | (then I'll move on to turrets...) |
| 19:11:58 | raptor | Watusimoto: you said it was each to find the terminating segment? |
| 19:12:06 | raptor | each = easy |
| 19:12:33 | Watusimoto | yes\ |
| 19:12:37 | Watusimoto | yes |
| 19:12:40 | Watusimoto | it is |
| 19:13:19 | karamazovapy | http://img10.imageshack.us/img10/9846/turretblockedfield.png |
| 19:13:34 | raptor | i should save my math for shortening a segment... where would a good place be, Watusimoto? |
| 19:13:44 | Watusimoto | ffp->getEndSegment() |
| 19:13:51 | Watusimoto | geomUtils |
| 19:14:01 | raptor | okey doke |
| 19:14:14 | Watusimoto | getEndSegment gives you a segment "serial number" |
| 19:14:36 | Watusimoto | sorry, it gives you a pointer to the segment itself |
| 19:15:00 | Watusimoto | should just be able to compare when doing your collision detection |
| 19:15:20 | raptor | ok, i'll have to search the wallsegmentdatabase instead... |
| 19:15:25 | Watusimoto | you might be able to discard your shortening... don't know if we need it anymore |
| 19:15:41 | raptor | we won't.. but would it be useful to save? |
| 19:15:57 | Watusimoto | though it might allow some otherwise rejected but legal ffs |
| 19:16:02 | Watusimoto | sure |
| 19:16:07 | Watusimoto | save it -- why not/ |
| 19:20:09 | | BFLogBot - Commit 7032dcfe6b88 | Author: watusim...@bitfighter.org | Log: Provisional fixes for merging purposes -- DO NOT UPDATE TO THIS VERSION! |
| 19:20:12 | | BFLogBot - Commit 7054d142d07e | Author: watusim...@bitfighter.org | Log: Merge |
| 19:20:14 | | BFLogBot - Commit 89da5f8444c8 | Author: watusim...@bitfighter.org | Log: Fix possible bug with pausing bots; move pause indicator to UR corner; move all pausing into EventManager; get Robot out of event management; get Robot out of controlling pausing and unpausing of bots; probably more Actually, a lot of these changes were done in rev. 3481/7032dcfe6b885ba9fa734b48b01bab82213661e2 |
| 19:20:29 | raptor | what the |
| 19:20:59 | raptor | looks like you were updating the commit message as you were coding... |
| 19:21:21 | Watusimoto | just in my head |
| 19:21:25 | karamazovapy | quick opinion poll - my VPS had a big server crash and I'm being relocated |
| 19:21:33 | karamazovapy | Los Angeles, Phoenix, or Washington DC? |
| 19:21:52 | Watusimoto | Phoenix or WashDC |
| 19:22:16 | karamazovapy | I'm wondering if DC might benefit the europeans |
| 19:22:19 | Watusimoto | probably washdc for you |
| 19:22:31 | raptor | phoenix or DC |
| 19:22:31 | karamazovapy | it's a couple thousand miles closer |
| 19:22:35 | | koda has joined |
| 19:26:00 | karamazovapy | DC it is. |
| 19:26:34 | Watusimoto | the hamburger buns my wife got are called "American Mega Burger" |
| 19:26:43 | Watusimoto | I love how we're seen over here |
| 19:27:06 | raptor | haha |
| 19:28:09 | Watusimoto | Come down today for the year end closeouts of our American Fat-Assed SUVs! We're clearing out the 2011 models! |
| 19:28:29 | Watusimoto | someone told me he heard Americans don't read |
| 19:28:40 | Watusimoto | that's the sterrotye in Portugal, at least |
| 19:28:55 | Watusimoto | and you if you pass someone when you're bike racing, you shout out "American!" |
| 19:29:06 | Watusimoto | I think it means you're slow |
| 19:29:27 | Watusimoto | though apparently after Lance Armstrong won the Tour de France, that one became less common |
| 19:29:57 | raptor | wow |
| 19:30:00 | raptor | i believe it |
| 19:30:56 | Watusimoto | there were a few others, but I stopped listenting, as the speaker was obviously intoxicated |
| 19:31:07 | Watusimoto | he went on to talk about Germans and French people next |
| 19:31:33 | Watusimoto | at least I think, but I wasn't listenting |
| 19:31:38 | Watusimoto | ok, dinner time |
| 19:31:39 | Watusimoto | later |
| 19:32:34 | raptor | bye |
| 19:36:16 | | Watusimoto Quit (Ping timeout: 252 seconds) |
| 19:40:19 | | BFLogBot - Commit d15fa5dc6bfc | Author: buckyballreaction | Log: Save method to shorten a segment |
| 20:06:37 | | sam686 has joined |
| 20:06:37 | | ChanServ sets mode +v sam686 |
| 20:18:27 | raptor | i can't believe how complex walls are in the code.. |
| 20:20:30 | karamazovapy | the wiki should probably be updated to reflect the fact that there's no yum package for mercurial on centos |
| 20:20:50 | raptor | there isn't? i thought there was... |
| 20:21:28 | karamazovapy | maybe rpmforge needs to be updated or something first? |
| 20:21:40 | karamazovapy | I wound up using this > http://edvanbeinum.com/install-mercurial-on-centos |
| 20:22:42 | raptor | yikes - that makes for a messy system |
| 20:23:20 | karamazovapy | as in a messy file system, or a messy system for building bitfighter? |
| 20:23:45 | raptor | filesystem |
| 20:24:34 | karamazovapy | yeah, it seems excessive, but I only really use my vps for bitfighter and some occasional web hosting |
| 20:26:46 | raptor | ah, add the epel repo |
| 20:26:53 | raptor | that's how i got it, i think.. |
| 20:27:49 | raptor | you do the following (for CentOS 5): rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm |
| 20:28:02 | raptor | and a whole host of packages are now open to you |
| 20:28:11 | karamazovapy | be good to put that in the wiki |
| 20:28:32 | raptor | fine fine fine... |
| 20:29:04 | raptor | which page is that? |
| 20:29:45 | karamazovapy | <raptor> ah, add the epel repo |
| 20:29:45 | karamazovapy | <raptor> that's how i got it, i think.. |
| 20:29:47 | karamazovapy | bah |
| 20:29:50 | raptor | found it... |
| 20:29:57 | karamazovapy | stupid copy/paste |
| 20:30:01 | karamazovapy | I meant to post http://bitfighter.org/wiki/index.php?title=Building_Bitfighter |
| 20:32:55 | raptor | ok, i updated that page |
| 20:33:06 | raptor | under bulding a dedicated server |
| 20:33:14 | raptor | i hope i didn't cause a collision with you |
| 20:35:59 | karamazovapy | yeah, that's a much easier way to get mercurial |
| 20:36:56 | raptor | also you'll have a ton of other packages available |
| 20:48:56 | karamazovapy | what do I have to checkout if I want to build an 016 server? |
| 20:49:17 | raptor | oh let see real quick... |
| 20:50:55 | karamazovapy | I like this thread the way it is, right now, without any additional posts. http://bitfighter.org/forums/viewtopic.php?f=9&t=1184 |
| 20:50:57 | raptor | yum install SDL-devel |
| 20:51:31 | raptor | hahaha |
| 20:51:39 | raptor | start with SDL-devel |
| 20:51:47 | karamazovapy | ye |
| 20:53:42 | raptor | also gcc-c++ libstdc++-devel |
| 20:53:50 | raptor | ok, and 'make' |
| 20:53:55 | sam686 | building 016 ZAP_DEDICATED shouldn't need SDL... |
| 20:54:01 | raptor | wait! SDL is not needed |
| 20:54:08 | raptor | ha! thanks sam686 |
| 20:54:18 | karamazovapy | too late, but no big deal |
| 20:54:21 | raptor | don't install SDL - it may install too much garbage |
| 20:54:23 | raptor | ah ok |
| 20:55:02 | karamazovapy | I was just wondering what code I need to grab to build 016 |
| 20:55:21 | sam686 | hg pull (or clone) then "hg up tip" |
| 20:57:06 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 20:57:48 | karamazovapy | okay, so instead of hg up -c bitfighter-015, it'd be hg up tip |
| 20:57:55 | raptor | correct |
| 20:57:59 | karamazovapy | then still 'make dedicated' |
| 20:58:03 | raptor | yed |
| 20:58:05 | raptor | yes |
| 20:58:08 | karamazovapy | hip |
| 20:58:20 | raptor | hopefully it will compile - sam686 has been constantly fixing the dedicated compile as we go.. |
| 20:59:02 | sam686 | it seems to compile zap_dedicated as of the latest changes (d15fa5dc6bfc) |
| 20:59:52 | | Watusimoto has joined |
| 21:00:44 | karamazovapy | looks like it built! |
| 21:00:49 | karamazovapy | I'll test it later |
| 21:01:05 | raptor | cool |
| 21:02:16 | raptor | i think i finally have the wall detection done.. works well so far.. |
| 21:05:00 | Watusimoto | good. doesn't need to be perfect, just better |
| 21:05:13 | Watusimoto | was excluding the end the key? |
| 21:05:16 | raptor | finally |
| 21:05:18 | raptor | yes |
| 21:05:21 | raptor | but that was tricky |
| 21:05:36 | | BFLogBot - Commit 546a5a466f64 | Author: buckyballreaction | Log: Engineering a forcefield now has built in wall detection. A force field cannot be deployed if it is within a ship's width of a wall, excluding the wall segment that terminates the field |
| 21:05:45 | raptor | o hey there it is |
| 21:06:32 | raptor | i shoudl probably do karamazovapy's case, too: http://img10.imageshack.us/img10/9846/turretblockedfield.png |
| 21:07:36 | raptor | actually, what do you think about that case? maybe only if it is an un engineered turret? (and is there a flag for that?) |
| 21:09:28 | Watusimoto | could make it 1 ship width + 1 turret width from any wall |
| 21:10:12 | raptor | that's like getting rid of most of the level! |
| 21:11:07 | Watusimoto | maybe we could show the prospective turret and bounding box (exclusion zone?) when placing, making it clear what the restrictions are |
| 21:12:00 | Watusimoto | because people will create impossible levels by placing ffs then turrets... you know they will@ |
| 21:12:03 | Watusimoto | ! |
| 21:12:30 | raptor | not impossible - you can shoot the turrets |
| 21:12:38 | raptor | engineered ones, i mean |
| 21:12:54 | Watusimoto | oh |
| 21:13:04 | Watusimoto | and if you kill them, they disappear |
| 21:13:07 | raptor | correct |
| 21:13:09 | Watusimoto | well, then, yes, ok |
| 21:13:22 | Watusimoto | sure; what you said before |
| 21:13:27 | raptor | is there a flag to differentiate between engineered turret and non-eng, type? |
| 21:13:35 | Watusimoto | there must be |
| 21:14:03 | Watusimoto | vc++ misbehaving... |
| 21:14:17 | sam686 | engineer turrets are destroyable... only worry about undestroyable turrets |
| 21:14:18 | Watusimoto | something knows what to do when they die |
| 21:14:23 | Watusimoto | yes |
| 21:14:37 | Watusimoto | sam; how did you figure out the bot problem last night? |
| 21:14:56 | sam686 | the tick problem? |
| 21:15:02 | sam686 | i may have fixed that.. |
| 21:15:19 | Watusimoto | yes |
| 21:15:23 | Watusimoto | you did fix that |
| 21:15:32 | Watusimoto | I was just trying to figure out how I could have found it |
| 21:15:39 | Watusimoto | as it was not at all obvious |
| 21:15:53 | Watusimoto | even knowing what the problem is, I'm not sure how to find it |
| 21:16:02 | Watusimoto | bots behave the same if they run once or 10x |
| 21:16:03 | sam686 | mostly, all i did is move tick event to serverGame::idle |
| 21:16:12 | Watusimoto | just as an experiment? |
| 21:16:35 | sam686 | not all bots behave the same, if on tick ran 10 times more... (my Timer Bot) |
| 21:16:45 | Watusimoto | ah, a timerbot |
| 21:17:02 | sam686 | my timer bot prints timing 10 times faster when onTick is run 10 times more |
| 21:17:13 | Watusimoto | yes, that would be a giveaway |
| 21:17:38 | Watusimoto | well, good job |
| 21:17:43 | Watusimoto | I'd still be working on it |
| 21:20:57 | raptor | i don't see where we can determine if teh engineered turret is different than one that starts with the level... |
| 21:21:04 | raptor | but it's gotta be somewhere.. |
| 21:24:19 | sam686 | raptor, EngineeredItem.cpp line 661 ? |
| 21:24:48 | raptor | what method? i have that class all messed up |
| 21:25:07 | sam686 | find if(mHealth == 0 && mResource.isValid()) |
| 21:25:16 | Watusimoto | if(mHealth == 0 && mResource.isValid()) |
| 21:25:27 | Watusimoto | ha |
| 21:25:31 | raptor | what |
| 21:25:33 | raptor | does |
| 21:25:34 | raptor | that |
| 21:25:36 | raptor | mean |
| 21:25:37 | Watusimoto | beat me by 8 secs |
| 21:25:51 | Watusimoto | if mResource.isValid() it's been engineered |
| 21:26:11 | Watusimoto | that's the resource item that was used to create it |
| 21:26:12 | Watusimoto | if it has one, voila! |
| 21:26:19 | raptor | ah |
| 21:26:42 | Watusimoto | why not create a method called isEngineered() { return mResource.isValid() } |
| 21:26:50 | Watusimoto | for documentation purposes and readability |
| 21:31:57 | raptor | ok, i think i got it - time to test... |
| 21:35:24 | raptor | except mResource.isValid() is returning false for some reason... |
| 21:35:41 | karamazovapy | is the turret engineered...? |
| 21:36:27 | raptor | what is your question? |
| 21:36:48 | karamazovapy | well it would return false if it wasn't an engineered turret |
| 21:36:52 | karamazovapy | I realize that's obvious |
| 21:37:56 | raptor | yeah - i need a way to tell an engineered turret apart from on that starts out in the level |
| 21:40:29 | raptor | sorry sam crash |
| 21:41:15 | sam686 | i didn't crash, i went disconnect... |
| 21:42:10 | raptor | bug: can't use spacebar in chat with engineer equipped |
| 21:42:33 | sam686 | it comes to a point that checking is the engineer forcefield is allowed should be checked server side |
| 21:45:39 | raptor | yeah - that too |
| 21:45:49 | raptor | also, mResource.isValid() is not working |
| 21:46:10 | raptor | mybe that's why - it needs to be server side? |
| 21:47:57 | raptor | huh - i think it is server side.. |
| 21:55:07 | Watusimoto | oh |
| 21:55:09 | Watusimoto | yes |
| 21:55:09 | sam686 | there is a problem with ForceFieldProjector::getCollisionPoly returning zero points (where it shoudn't) |
| 21:55:21 | Watusimoto | that's certainly it, raptor |
| 21:55:26 | Watusimoto | duh! |
| 21:55:26 | raptor | what |
| 21:55:39 | Watusimoto | resource is only known on the server |
| 21:55:45 | | BFLogBot - Commit b8c1e42e8866 | Author: sam8641 | Log: Add a TNLAssert |
| 21:55:48 | Watusimoto | a turret is a turret on the client |
| 21:56:22 | Watusimoto | perhaps we need to send a flag over with the initial turret packet |
| 21:56:23 | raptor | what? |
| 21:56:44 | Watusimoto | when we tell the client about a turret, maybe we need to add a flag and have a state var: mIsEngineerred |
| 21:57:24 | raptor | wait wait wait |
| 21:57:25 | Watusimoto | then you, on the client end, will know the status of a given turret (or ff, would suggest doing it at the engineeredItem level) |
| 21:57:54 | Watusimoto | ok; create a new member var called mEngineered on EngineeredItem,default to false |
| 21:58:26 | Watusimoto | then when sending the initial packet from server to client (EngineerItem::packUpdate) send the flag, and populate it on the client |
| 21:58:57 | raptor | ah ok |
| 21:58:58 | Watusimoto | then we'll have a flag on the client side we can check to see if a turret/ff was engineered |
| 21:59:28 | Watusimoto | set the flag on the server side when creating an engineered turret, so it will always be a reliable indicator of engineered state |
| 22:00:16 | Watusimoto | I found a snapping bug for engineered items -- it's why I haven;t been able to create the scenarios I wanted to to help figure out what rules we should apply to the stuff you're doing |
| 22:03:16 | raptor | maybe that has to deal with my snapping bug.. |
| 22:06:24 | Watusimoto | maybe, hopefully |
| 22:07:11 | raptor | it works! |
| 22:07:20 | raptor | i'm going to close this issue next... |
| 22:10:48 | | BFLogBot - Commit 804052140830 | Author: sam8641 | Log: Fix some cases of mCollisionPolyPoints.size() being zero |
| 22:11:01 | raptor | ok committed |
| 22:11:06 | sam686 | i may have fixed a problem with ForceFieldProjector::getCollisionPoly returning zero on my latest commit.. |
| 22:11:17 | raptor | oh good! i ran into that a few times |
| 22:11:23 | raptor | wasn't sure why it was happening |
| 22:12:25 | raptor | fixed!: http://code.google.com/p/bitfighter/issues/detail?id=88 |
| 22:12:40 | raptor | i wonder if this will be the greatest cause of community uproar |
| 22:13:02 | sam686 | are you sure it is fixed? test with me? |
| 22:13:11 | raptor | it is still client side |
| 22:13:25 | sam686 | haha, move to server side? |
| 22:13:55 | raptor | maybe... i don't really want to at the moment - i have a couple little bugs i need to solve first |
| 22:14:25 | raptor | like spacebar with engineer module and chat |
| 22:14:37 | sam686 | a modified client cound send anything, like not checking if forcefield is allowed |
| 22:14:56 | raptor | yes, i think it is important to move to server side |
| 22:15:18 | raptor | i'll write it down for later, unless you want to do it :) |
| 22:15:51 | | BFLogBot - Commit f297e3e4ac66 | Author: buckyballreaction | Log: Make forcefield placement logic aware of non-destructible turrets |
| 22:19:39 | | LordDVG Quit (Ping timeout: 252 seconds) |
| 22:32:45 | sam686 | oh and your forcefield stuff doesn't work with polywall, does it? |
| 22:33:15 | Watusimoto | It should... |
| 22:33:24 | Watusimoto | polywalls have segments too! |
| 22:33:27 | raptor | i didn't do enough testing with polywall.. do polywalls have segments? |
| 22:33:37 | raptor | oh good |
| 22:33:41 | raptor | then it should be ok |
| 22:34:08 | Watusimoto | probably should treat ff projectors just like turrets |
| 22:34:17 | raptor | already are |
| 22:34:22 | raptor | oh wait |
| 22:34:23 | raptor | no |
| 22:34:31 | Watusimoto | check for chokepoints with ffps |
| 22:34:34 | raptor | yes |
| 22:34:36 | raptor | that |
| 22:34:37 | raptor | easy fix |
| 22:34:51 | Watusimoto | and maybe reactors as well |
| 22:34:54 | Watusimoto | sorry, cores |
| 22:35:49 | raptor | i can't figure out this current bug: in chat, with engineer equipped, space bar doesn't work and isntead brings up engineer menu |
| 22:36:09 | raptor | i've been comnparing with 015a which works, and most looks the same so far... |
| 22:37:31 | sam686 | the problem is "wallSegmentDatabase->findObjects(isWallType, fillVector, queryRect);" always returns zero server side |
| 22:37:57 | raptor | ah yes, that'd be a problem... |
| 22:38:12 | raptor | Watusimoto: are segmetns saved server side? |
| 22:38:25 | Watusimoto | mmm |
| 22:38:28 | Watusimoto | probably not |
| 22:38:43 | Watusimoto | no wait |
| 22:38:44 | sam686 | gameObjectDatabase->findObjects(isWallType, fillVector, queryRect); might work, but that makes you never be able to place any forcefields |
| 22:38:47 | Watusimoto | segmens should be |
| 22:39:04 | raptor | man, this issue has been ballooning |
| 22:39:12 | Watusimoto | I don't think raw walls are used for collision detection |
| 22:39:19 | Watusimoto | :-) |
| 22:39:52 | sam686 | polywall walls will have to be raw, or it won't work.. as polywall don't have segments, does it? |
| 22:39:54 | raptor | maybe we could just keep it our secret that engineer placement is client side... |
| 22:40:17 | raptor | polywalls do have segments according to Watusimoto |
| 22:40:24 | Watusimoto | I said before that polywalls produce segments, but now I'm less confient |
| 22:40:32 | sam686 | the secret will eventually be... spoiled by reading the source code (or even this irc log) |
| 22:40:39 | Watusimoto | ha! |
| 22:41:27 | sam686 | polywall don't need segments to work.. |
| 22:43:53 | raptor | well, the trick to my logic was to exclude the FF terminating segment |
| 22:49:19 | sam686 | i think i found a new problem, engineer forcefield, destroy forcefield projector, and the forcefield stays there |
| 22:57:53 | Watusimoto | just to put this issue to rest: |
| 22:57:55 | Watusimoto | // Polywalls will have one segment; it will have the same geometry as the polywall itself |
| 22:57:55 | Watusimoto | if(wall->getObjectTypeNumber() == PolyWallTypeNumber) |
| 22:57:55 | Watusimoto | { |
| 22:57:55 | Watusimoto | WallSegment *newSegment = new WallSegment(mWallSegmentDatabase, *wall->getOutline(), wall->getSerialNumber()); |
| 22:57:55 | Watusimoto | mWallSegments.push_back(newSegment); |
| 22:57:58 | Watusimoto | } |
| 22:58:02 | Watusimoto | the comment says it all |
| 22:58:21 | Watusimoto | so I was sort of right, but in a misleading sort of way |
| 22:59:27 | Watusimoto | that said, things might work if we added the polywall as a sequence of 2-pt segments forming a loop |
| 22:59:42 | Watusimoto | but I'm not sure |
| 23:01:57 | sam686 | i don't think polywall need any more WallSegment, and might even make editor run faster without it.. Used to be for Turret snapping, but now turret snapping can be done without wall manager |
| 23:08:34 | sam686 | also, it turns out wallSegmentManager is empty even on a client side, unless the client test from editor.. |
| 23:10:58 | | BFLogBot - Commit 8fa8e2d3d4bf | Author: sam8641 | Log: Fix engineer ForceField stays begind when projector is destroyed |
| 23:21:04 | raptor | wonderful.. |
| 23:21:10 | raptor | and i thought i fixed an issue... |
| 23:22:07 | sam686 | restart your client, and join my "sam test" host without entering editor, and try engineer |
| 23:22:32 | raptor | ok |
| 23:22:33 | sam686 | or, hosting without entering editor would show the same bug too |
| 23:24:42 | raptor | sam686: can you use the spacebar with engineer? |
| 23:24:47 | sam686 | Sound should never be null at all!!! |
| 23:24:57 | raptor | crash? |
| 23:25:25 | sam686 | in "void SoccerGameType::itemDropped(Ship *ship, MoveItem *item)" |
| 23:25:42 | raptor | what |
| 23:25:50 | sam686 | it happens when dropping resource item |
| 23:26:25 | sam686 | "Shound never run at all!!!"" |
| 23:26:42 | raptor | sounds like a Watusimoto assert |
| 23:26:59 | Watusimoto | it was |
| 23:27:12 | Watusimoto | why is it in soccergametype? ah |
| 23:27:12 | sam686 | so.... looks like SoccerGameType::itemDropped get run when dropping resouce item |
| 23:27:13 | Watusimoto | I see |
| 23:27:22 | Watusimoto | ok, so make a note and remove the assert |
| 23:27:30 | sam686 | and i was in a soccer game type (with no soccer ball) |
| 23:27:40 | Watusimoto | but maybe the whole function should be removed |
| 23:27:53 | Watusimoto | and let it fall back on the parent's itemDropped |
| 23:28:18 | Watusimoto | since there is nothing special about item dropping in soccer (anymore) right? |
| 23:28:29 | raptor | right! |
| 23:28:38 | Watusimoto | this snapping problem is making me crazy |
| 23:28:54 | Watusimoto | the more I play with it, the worse it gets, even when I revert the code |
| 23:29:04 | raptor | to the brink of insanity? |
| 23:29:10 | Watusimoto | yes |
| 23:29:53 | raptor | well, you have a choice - continue in this state until 3am; or, sleep and solve it in 15 min. in the morning |
| 23:29:56 | raptor | :) |
| 23:29:57 | sam686 | but i don't have such "press spacebar" crash while holding engineer item bug that raptor might have? |
| 23:31:02 | | BFLogBot - Commit 81b7dcb59c5d | Author: sam8641 | Log: Fix SoccerGameType::itemDropped |
| 23:31:25 | raptor | argh i have to rewrite portions of the FF wall detection.. |
| 23:31:54 | raptor | thanks sam686, you crashed my server somehow... |
| 23:32:00 | raptor | :] |
| 23:32:05 | sam686 | all i did is join |
| 23:32:34 | raptor | you can use spacebar in chat with engineer equipped? |
| 23:33:14 | | CrazyLinuxNerd has joined |
| 23:33:44 | sam686 | pressing space while chat, pops up "what do you want to engineer" |
| 23:33:57 | raptor | yes!! |
| 23:34:02 | raptor | it's driving me crazy!! |
| 23:34:08 | raptor | i can't find the problem |
| 23:37:30 | sam686 | GameUserInterface::onKeyDown |
| 23:37:55 | sam686 | UIGame.cpp line 1120 |
| 23:38:14 | raptor | that's where i'm looking - it's the same as 015z |
| 23:38:16 | raptor | 015a |
| 23:40:48 | sam686 | maybe, its becuase of entering engineer menu while in chat menu? |
| 23:44:33 | Watusimoto | thyis is a laugh |
| 23:44:45 | Watusimoto | I just accidentally reimplemented the shorten line function |
| 23:44:53 | raptor | ha! |
| 23:44:59 | raptor | is it better than mine? |
| 23:44:59 | Watusimoto | using a totally (probably) differnt mechanism |
| 23:45:15 | Watusimoto | void Point::interp(float t, const Point &p1, const Point &p2) |
| 23:45:15 | Watusimoto | { |
| 23:45:15 | Watusimoto | float oneMinusT = 1.0f - t; |
| 23:45:15 | Watusimoto | x = p1.x * t + p2.x * oneMinusT; |
| 23:45:15 | Watusimoto | y = p1.y * t + p2.y * oneMinusT; |
| 23:45:17 | Watusimoto | } |
| 23:45:28 | Watusimoto | using the structure from Color of the same name |
| 23:46:01 | Watusimoto | to shorten a line, just feed in t=newlinelen/origlinelen, p1=start, p2=end |
| 23:46:40 | raptor | ha, well mine is documented... so there... |
| 23:46:44 | Watusimoto | :-) |
| 23:47:02 | Watusimoto | I;m not using it to shorten a line, at least not directly, but rather to find a point between two other points |
| 23:47:20 | Watusimoto | but very near one |
| 23:47:31 | Watusimoto | but it's really the same ting |
| 23:47:35 | Watusimoto | :-) |
| 23:48:00 | raptor | yeah mine just returns a new end point given start, end, and reduction |
| 23:51:06 | raptor | i dont' know why i'm having such a hard time with this space bar thing - i think i need to take a break |
| 23:52:11 | sam686 | space bar crash for you? |
| 23:52:30 | raptor | no, just can't use it in chat with engineer equipped |
| 23:52:41 | raptor | i keep running around the UIGame methods |
| 23:52:48 | raptor | need a break |
| 23:52:52 | raptor | i wrote it on the wiki |
| 23:52:55 | sam686 | i think i know the problem... |
| 23:53:00 | sam686 | and know how to fix |
| 23:53:09 | raptor | !! |
| 23:53:17 | raptor | i give you permission to do it :-) |
| 23:53:45 | sam686 | ok, i can fix it... |
| 23:56:21 | Watusimoto | one step forward, one step back |
| 23:56:32 | raptor | that's been this whole day! |
| 23:56:47 | Watusimoto | fixed the snap issue, but when you move a wall, ffs jump around and change pos, even if there's no reason for it |
| 23:57:10 | raptor | ha |
