00:00:12 | raptor | for reference: http://sam686.maxhushahn.com/upload/1111screenshot_1.png |
00:00:36 | raptor | because that test means you have to be close to the center point of the object, instead of the extents |
00:00:55 | Watusimoto | I think that's it: you could repair turret and forcefield a little farther away... |
00:01:08 | raptor | and that won't be horribel? |
00:01:11 | raptor | horrible |
00:01:40 | Watusimoto | otherwise it falls back on repairing all objs in a square RepairRadius on a side |
00:01:45 | raptor | yes |
00:02:20 | Watusimoto | turns repairing radius into a square |
00:02:48 | raptor | so simple fix and remove it and call it good? |
00:03:22 | Watusimoto | alternative would be to have each object have it;s own repair radius |
00:03:40 | Watusimoto | and set cores with a larger radius than other items |
00:04:04 | raptor | not sure i like that... |
00:04:07 | Watusimoto | it seems that simply squaring off the repair radius wouldn;t solve the core issue |
00:04:09 | raptor | one more hting to keep track of |
00:04:38 | Watusimoto | you would have to be closer on the x/y axes than you would at (1,1) or (-1,-1) |
00:04:41 | Watusimoto | if that makes sense |
00:04:47 | raptor | yes |
00:04:53 | Watusimoto | that seems a bit weird |
00:04:58 | raptor | yes |
00:05:08 | Watusimoto | also, doesn;t the collisionRadius factor allow you to get further away? |
00:05:21 | raptor | yes |
00:05:25 | Watusimoto | I imagine the core;s collisionradious is quite big |
00:05:29 | Watusimoto | at least at first |
00:05:30 | raptor | ship's collision radius |
00:05:43 | raptor | so 24 + 65 |
00:05:50 | raptor | 65 being RepairRadius |
00:06:13 | Watusimoto | ah, so perhaps the initial search radiuis needs to be expanded slightly |
00:06:13 | raptor | unless you're thinking of something else... |
00:06:36 | Watusimoto | Maybe this line needs to change |
00:06:37 | Watusimoto | Point extend(RepairRadius, RepairRadius); |
00:06:46 | Watusimoto | Point extend(RepairRadius + 20, RepairRadius + 20); |
00:06:48 | Watusimoto | or something |
00:07:00 | raptor | did you see the screenshot? |
00:07:13 | Watusimoto | wait, no, let me look |
00:07:30 | Watusimoto | ok |
00:07:42 | Watusimoto | 3 cores |
00:07:53 | Watusimoto | mama, papa, and baby |
00:08:11 | raptor | that shot is the maximum distance from which i can repair a core with that one test removed on ship.cpp:763 |
00:08:16 | raptor | haha |
00:08:31 | Watusimoto | ok |
00:08:57 | raptor | so that seems far enough already |
00:09:01 | Watusimoto | you should be able to repair papa at a distancs of 89, right? |
00:09:15 | raptor | same distance to repair |
00:09:18 | raptor | for all |
00:09:21 | Watusimoto | 65 from the edgeo of the core |
00:09:51 | raptor | it's actually 65 from the edge of starting radius of the item (instead its center) |
00:09:55 | Watusimoto | the test you want to remove checks if ship is withing 89 of core |
00:10:03 | Watusimoto | right |
00:10:04 | Watusimoto | ok |
00:10:20 | Watusimoto | so you wrote that for large cores you had to be too close |
00:10:32 | raptor | correct, and couldn't repair them |
00:10:42 | Watusimoto | so you wanted to remove that check to allow you to be al ittle further away |
00:10:46 | raptor | yes |
00:10:56 | raptor | because the check is against the center point |
00:11:06 | Watusimoto | the reason you have to be so close is not the check you want to remove, but that earlier search radius |
00:11:30 | Watusimoto | if the first search was for Point extend(RepairRadius + 20, RepairRadius + 20); |
00:11:46 | Watusimoto | then you could be further from the large core, but would have no impact on smaller core |
00:11:51 | raptor | here is the distance from turret now: http://sam686.maxhushahn.com/upload/111screenshot_2.png |
00:12:10 | raptor | the search isn't the problem |
00:12:12 | Watusimoto | changing that initial check wouldn't affect turrets at all |
00:12:21 | Watusimoto | I think it's the entire problem |
00:12:23 | raptor | it already finds the item in the database based on extents |
00:12:27 | Watusimoto | right |
00:12:45 | Watusimoto | ok, let;s say you have a full core, radius what? 24? |
00:12:47 | raptor | i am not following your reverse psychology |
00:12:59 | Watusimoto | how big is a papa core? |
00:13:04 | raptor | 200 |
00:13:17 | Watusimoto | ok. so you are 250 from a papa, and want to repair |
00:13:22 | Watusimoto | you should be able to, right? |
00:13:27 | raptor | 200 width - radius 100 |
00:13:35 | Watusimoto | ok, 150 |
00:13:38 | raptor | 250 from which part of papa? |
00:13:46 | Watusimoto | you are 150 from center of papa |
00:13:50 | raptor | ok |
00:13:51 | raptor | yes |
00:13:53 | Watusimoto | you shoudl be able to repair, right? |
00:13:54 | Watusimoto | ok |
00:13:56 | raptor | correct |
00:14:00 | Watusimoto | but currently you cannot |
00:14:04 | Watusimoto | correct? |
00:14:08 | raptor | correct |
00:14:30 | Watusimoto | I'm asserting that the reason is because that initial check doesn't find the core |
00:14:56 | Watusimoto | and so it never gets evaluated during the line you want to remove |
00:15:18 | raptor | wrong! |
00:15:22 | raptor | it always finds the core |
00:15:25 | Watusimoto | if it was found by the intial check, then you would be able to repair at 150 |
00:15:30 | raptor | no! |
00:15:39 | Watusimoto | ok, so why can't you repair at 150? |
00:15:46 | raptor | i cannot repair at 150 because i am too far away from the center |
00:16:00 | raptor | the search finds the core based on extents |
00:16:09 | Watusimoto | it checks if len > RepairRadius + CollisionRadius |
00:16:13 | raptor | yes! |
00:16:18 | Watusimoto | len > 65 + 100 |
00:16:18 | raptor | which will always fail |
00:16:23 | raptor | nononono |
00:16:36 | raptor | 'CollisionRadius' is a constant = Ship::CollisionRadius |
00:16:36 | Watusimoto | collisionradius of core isn;t 100? |
00:16:44 | Watusimoto | oops |
00:16:45 | raptor | which is 24 |
00:16:49 | raptor | :) |
00:16:56 | Watusimoto | ok, then here is what makes sense |
00:17:20 | Watusimoto | you should be able to repair at RepairRadius from edge of itme, not RepairRadius of center of item |
00:17:49 | Watusimoto | so that check should be RepairRadius + CollisionRadius + s->CollisionRadius |
00:18:03 | Watusimoto | and RR should be lowered somewhat to compensate |
00:18:08 | raptor | yes, and i think to do that all i have to do is remove the check completely no? it already does that exact check in the database |
00:18:21 | Watusimoto | it's a different check |
00:18:32 | Watusimoto | the database check is a square check, the second one is round |
00:18:41 | Watusimoto | if that makes sense |
00:18:59 | Watusimoto | len() gives you straight line distance |
00:19:09 | raptor | yes, that makes sense |
00:19:11 | raptor | ok |
00:19:19 | raptor | i understand the purpose of that now |
00:19:22 | Watusimoto | ok |
00:19:45 | Watusimoto | so your proosal would sort of work, but only just because the numbers worked out just so |
00:20:16 | Watusimoto | so I would propose addikng s->CollRad, and reducing RR by the CollRad of a turret |
00:20:47 | raptor | ok |
00:20:58 | raptor | now to get the radius, i have to cast to Item class |
00:21:01 | Watusimoto | that should keep turret reparing the same, make you get slightly colser to a ff to repair, increase your distance slightly from a ship to repair, and totally fix cores, regardless of their size |
00:22:12 | raptor | can we cast to Item after a database search? |
00:22:18 | Watusimoto | it's kind of like adding a repairRadius to the objects, except ot's c;eaner |
00:22:21 | Watusimoto | typing! |
00:22:35 | raptor | ? |
00:22:37 | Watusimoto | I would change this |
00:22:38 | Watusimoto | GameObject *s = dynamic_cast<GameObject *>(foundObjects[i]); |
00:22:46 | Watusimoto | to be item * |
00:22:53 | Watusimoto | and check for null |
00:22:58 | raptor | ok |
00:23:00 | Watusimoto | we only repair items anyway |
00:23:10 | Watusimoto | and alreay dynamic cast, so it;s cheap |
00:23:17 | Watusimoto | or, rather, as cheap |
00:23:43 | raptor | ok |
00:23:44 | Watusimoto | and allows us to skip other tests that would inevitably fail |
00:23:50 | raptor | testing... |
00:24:19 | Watusimoto | we have a isWithHealthType??? |
00:24:28 | Watusimoto | my last point is rendered invalid |
00:25:31 | raptor | yes, i made that with the object refactor |
00:25:35 | raptor | :) |
00:25:58 | raptor | ok, to test... |
00:26:11 | Watusimoto | I can see levelgen walls in the editor |
00:26:13 | Watusimoto | bt |
00:26:14 | Watusimoto | w |
00:26:20 | raptor | yay! |
00:26:37 | Watusimoto | still a bit ugly, but it obvoiusly works fundamentally |
00:26:52 | raptor | speaking of 'ugly' |
00:26:59 | raptor | should we add code names to our releases? |
00:27:09 | Watusimoto | like what? |
00:27:16 | Watusimoto | 016 Ugly Bastard? |
00:27:22 | raptor | 016 released! codename Ugly |
00:27:24 | raptor | ye |
00:27:25 | Watusimoto | 016 Ugly Ungulate |
00:27:25 | raptor | s |
00:27:31 | raptor | just for fun of course |
00:27:38 | Watusimoto | We could, I suppose |
00:27:44 | Watusimoto | never been much of a fan |
00:27:56 | raptor | well, not of ubuntu names, of course... |
00:28:02 | Watusimoto | Ubuntu kind of posioned the well with me |
00:28:17 | Watusimoto | what would you propose? |
00:28:21 | raptor | their code names became official names and then no one could find anything about their correct version |
00:28:24 | Watusimoto | as a first name or two? |
00:29:10 | raptor | i don't really know, just a lame idea i had because i'm in that sort of mood... |
00:30:05 | sam686 | "016 test server on master" might need an update... |
00:31:05 | raptor | yes, definitely... soon |
00:32:12 | Watusimoto | well, propoase some lame names so I can shoot them down :-) |
00:33:28 | Watusimoto | we're using code numbers |
00:34:24 | raptor | well the repair radius of Core is always the starting radius... we end up using a different variable for the dynamic one |
00:35:52 | Watusimoto | we don;t always use collisionRadius? |
00:36:02 | Watusimoto | i.e. that doesn't get updated? |
00:36:14 | raptor | it's getRadius |
00:36:20 | raptor | oh.. collision radius... |
00:36:27 | raptor | let me see if there is a public method for that |
00:36:29 | Watusimoto | why not use that in the calculation? |
00:37:03 | Watusimoto | because we want the actual radius in this case, right? |
00:37:26 | raptor | yep |
00:38:52 | raptor | we only have radius and collision circle |
00:39:21 | raptor | and i guess for Core it is updating it's own radius instead of Parent::mRadius |
00:39:24 | raptor | blast |
00:39:39 | sam686 | getCollisionCircle ? |
00:41:01 | raptor | yeah |
00:41:59 | raptor | ok retesting... |
00:42:20 | raptor | fail |
00:46:12 | sam686 | select levels do have a problem when trying to scroll with a mouse, it keeps wanting to scroll up. |
01:01:53 | raptor | i can't sem to get the math right... |
01:02:40 | Watusimoto | ok trying to push latest edits |
01:02:52 | Watusimoto | getting abort: push creates new remote head |
01:02:59 | raptor | shame! |
01:03:07 | Watusimoto | (this is where I used -f the last time, and promised not to do it again) |
01:03:11 | Watusimoto | how can I resolve this? |
01:03:25 | Watusimoto | I have the latest from the repo on my machine |
01:03:26 | raptor | hg pull |
01:03:35 | raptor | then you have two heads somehow |
01:03:36 | raptor | locally |
01:04:02 | Watusimoto | will try cmd line. |
01:04:07 | Watusimoto | tortoise says I have it all |
01:04:41 | Watusimoto | C:\Users\Chris\Documents\bf-trunk>hg pull |
01:04:41 | Watusimoto | pulling from https://watusimoto%40bitfighter.org:***@bitfighter.googlecode.com/hg/ |
01:04:41 | Watusimoto | searching for changes |
01:04:41 | Watusimoto | no changes found |
01:04:41 | Watusimoto | C:\Users\Chris\Documents\bf-trunk>hg push |
01:04:42 | Watusimoto | pushing to https://watusimoto%40bitfighter.org:***@bitfighter.googlecode.com/hg/ |
01:04:45 | Watusimoto | searching for changes |
01:04:47 | Watusimoto | abort: push creates new remote head a2cbc98388bb! |
01:04:49 | Watusimoto | (did you forget to merge? use push -f to force) |
01:04:51 | Watusimoto | C:\Users\Chris\Documents\bf-trunk> |
01:05:04 | raptor | look for a2cbc98388bb |
01:05:07 | raptor | that is your head |
01:05:14 | raptor | or you need to merge... |
01:05:14 | Watusimoto | C:\Users\Chris\Documents\bf-trunk>hg stat -m |
01:05:14 | Watusimoto | C:\Users\Chris\Documents\bf-trunk> |
01:05:46 | sam686 | maybe if you scroll down in a list of revision, you might see un-merged heads... |
01:06:18 | Watusimoto | wait... |
01:06:20 | Watusimoto | there they are |
01:06:33 | Watusimoto | tortoise must have been very very slow to update |
01:06:43 | Watusimoto | I don;t haev to scroll down at all; they're right there |
01:07:01 | Watusimoto | it *is* rather late here |
01:07:30 | raptor | haha, repairing high-health cores is almost futile |
01:07:37 | raptor | but we can let people try... |
01:08:02 | raptor | unless we want to add a healing muliplier for Core? |
01:08:32 | Watusimoto | wbew |
01:08:34 | Watusimoto | whew |
01:08:38 | Watusimoto | rather |
01:08:45 | Watusimoto | I say not yet |
01:08:58 | Watusimoto | let;s try normal heal and revisit for 016a |
01:10:30 | raptor | dinner time! |
01:10:32 | sam686 | who will push first? |
01:10:36 | raptor | i'll be back and commit the healing... |
01:10:40 | sam686 | ok |
01:10:46 | raptor | i'll let Watusimoto push first... this time :) |
01:10:55 | raptor | i am not without compassion |
01:10:59 | Watusimoto | alreadyh done |
01:11:17 | Watusimoto | I appreciate your compassion, but it was useless :-) |
01:12:02 | Watusimoto | foo; can't select teleporters |
01:12:11 | Watusimoto | or teleporter destinations |
01:12:17 | Watusimoto | only origins |
01:13:09 | Watusimoto | can only select teleporters if their origin is already selected |
01:13:21 | | BFLogBot - Commit 94d899c0b428 | Author: watusim...@bitfighter.org | Log: Remove debugging prints |
01:13:22 | | BFLogBot - Commit fba436e2129e | Author: watusim...@bitfighter.org | Log: Remove dead code |
01:13:24 | | BFLogBot - Commit daa55314a886 | Author: watusim...@bitfighter.org | Log: Whitespace |
01:13:25 | | BFLogBot - Commit b4712445e91d | Author: watusim...@bitfighter.org | Log: Merge |
01:13:27 | | BFLogBot - Commit 55f353d198f2 | Author: watusim...@bitfighter.org | Log: Replace rect drawing with drawHollowRect |
01:13:28 | | BFLogBot - Commit b9eda0a665c8 | Author: watusim...@bitfighter.org | Log: Remove unused method |
01:13:30 | | BFLogBot - Commit 80d8c8fa2a8c | Author: watusim...@bitfighter.org | Log: Change message destination |
01:13:31 | | BFLogBot - Commit cbd65c9d7dba | Author: watusim...@bitfighter.org | Log: Hmmm.. this is an interesting checkin... |
01:13:33 | | BFLogBot - Commit 4aa012da1c7a | Author: watusim...@bitfighter.org | Log: Formatting |
01:13:34 | | BFLogBot - Commit a2cbc98388bb | Author: watusim...@bitfighter.org | Log: Script items now properly toggled with Ctrl+R; still some aeshetic issues remaining... |
01:13:36 | | BFLogBot - Commit 930fd0f12b43 | Author: watusim...@bitfighter.org | Log: Merge |
01:14:00 | Watusimoto | only applies to teleporters loaded in a level |
01:14:15 | Watusimoto | and once they get moved (via their origin) they're ok |
01:14:34 | Watusimoto | so something is not being built right in when loaded from disk |
01:17:34 | sam686 | most likely, the Extent is only at the teleport area, not the entire line, on level load,.. |
01:26:50 | Watusimoto | ah yes, probably that exactly |
01:30:07 | raptor | ok ok, may i make my compassionless commit? |
01:30:20 | raptor | (and yes dinner was tasty, thank you) |
01:31:46 | Watusimoto | yes |
01:31:55 | Watusimoto | going to bed; everything I've got is checked in |
01:32:00 | raptor | night! |
01:32:15 | Watusimoto | the editor bug is essentially fixed, still needs some aeshtetic work, but that's trivial |
01:32:25 | raptor | okey doke |
01:32:33 | raptor | did you fix the teleport thingy? |
01:32:35 | Watusimoto | need to make the editor stuff different color or transluscent or whatever; will tackel that tomorrow |
01:32:37 | Watusimoto | no |
01:32:59 | Watusimoto | but I think sam's suggestion is on the money and shoudl be really easy to fix |
01:33:00 | raptor | ok, get some sleep - maybe that will magically be fixed when you wake up |
01:33:03 | Watusimoto | goog night |
01:33:09 | Watusimoto | I like magic! |
01:33:11 | raptor | goog night |
01:33:16 | Watusimoto | night, sam |
01:33:39 | | BFLogBot - Commit 5929c51ba857 | Author: watusim...@bitfighter.org | Log: Less color setting and passing around |
01:37:33 | raptor | sam686: you working ok the teleport thing? |
01:38:41 | | BFLogBot - Commit 3dc782a557a2 | Author: buckyballreaction | Log: Healing items is now based on their radius; fixes not being able to heal Core because it was too big |
01:38:56 | sam686 | not yet.. |
01:39:04 | | Watusimoto Quit (Ping timeout: 240 seconds) |
01:42:06 | raptor | i don't see the luagen script rendering right still.. |
01:43:43 | | BFLogBot - Commit 650489142813 | Author: sam8641 | Log: Fix robot not being able to go through own forcefield |
01:43:58 | raptor | hooray! |
01:48:44 | | BFLogBot - Commit 63c970b20dfc | Author: sam8641 | Log: fix ZAP_DEDICATED |
01:56:21 | | koda Quit (Quit: I used to be chatting like you. Then I took an arrow in the knee) |
02:00:49 | raptor | i think eventually we should completely divide the render methods into separate classes |
02:01:05 | raptor | so Barrer::render -> BarrierRender::render |
02:01:23 | raptor | then we won't have to worry about ZAP_DEDICATED around all the UI stuff as much.. |
02:04:58 | raptor | sam686: can you load the test_object_suite level without crashing now? |
02:10:51 | sam686 | almost done with teleporter fix.. |
02:10:57 | raptor | ah ok |
02:15:46 | karamazovapy | got my first core level |
02:15:54 | raptor | sweet! |
02:15:58 | raptor | any crashes? |
02:17:21 | karamazovapy | I did it in 015a on my laptop, so I'm about to transfer it over here |
02:18:48 | | BFLogBot - Commit 17f60986126c | Author: sam8641 | Log: Fix editor teleporter not able to select distination, fix teleporter extent |
02:19:42 | sam686 | Undo have errors, on UIeditor line 438, mLoadTarget->getWallSegmentManager() returns a pointer 0f 0xFFFEFFFE |
02:19:55 | raptor | ha! i knew it! |
02:20:07 | raptor | i get a problem with deleteAndClear in Vector |
02:20:14 | karamazovapy | I'm in 016 now and I'm having some difficulties with forcefield placement |
02:20:34 | raptor | which type of difficulties? FFs always changing location? |
02:20:55 | karamazovapy | a couple really didn't want to snap into their intended places |
02:21:08 | karamazovapy | specifically, into the center on the end of a barrier |
02:21:26 | raptor | will holding spacebar allow you to do it? |
02:22:50 | raptor | i think watusimoto was coding too late... |
02:23:53 | karamazovapy | it got there eventually, it just took several tries |
02:25:30 | karamazovapy | I found another weird quirk...it's possible to shoot through a corner of a core |
02:25:46 | karamazovapy | it impacts the far side, so I'm not sure it matters, but it certainly looks funny |
02:26:32 | raptor | interesting... |
02:26:44 | karamazovapy | idea though, if the game ends with both teams having an equal number of cores, should the relative health of the cores be measured to determine a winner? |
02:26:58 | raptor | hmmm.... |
02:27:15 | sam686 | it's possible to shoot through a corner of a core ... i think you have the old revision where the core was square? |
02:27:20 | raptor | that might sound reasonable, actually |
02:27:31 | karamazovapy | raptor just sent me a revision today |
02:27:42 | raptor | no, i think getCollisionPoly might be wrong sometimes... |
02:27:47 | raptor | just slightly |
02:28:06 | raptor | maybe i should use a collision circle instead of trying to time the polygon rotation |
02:28:33 | karamazovapy | I'm really curious about the health question, though |
02:28:47 | karamazovapy | because then setting the health of a core too high could result in an unwinnable game |
02:29:20 | raptor | yeah - i think the health thing would make sense if the cores had un alterable health |
02:29:20 | sam686 | i think we should just use a collision circle, it is faster, and Core is nearly round, spinning around, making polygon collision difficult. |
02:30:00 | raptor | i thought i had problems with the collision circle... |
02:30:04 | raptor | like sticking to it |
02:30:07 | karamazovapy | I'll be really curious to see how core games play out with large groups |
02:31:05 | raptor | me too |
02:35:38 | karamazovapy | want to see this level? |
02:35:44 | raptor | yes! |
02:36:04 | karamazovapy | testing from the editor |
02:36:58 | raptor | sorry - new commits give me crashes... let me recompile at an older revision real quick |
02:46:55 | raptor | revision 4ee6d8fb68c1 is what you need to not crash... |
02:56:31 | raptor | so we have a bug in our collision algorithm - if using getCollisionPoly, a bullet can go through a corner of the polygon if aimed just right |
02:57:01 | raptor | but it may be too much of a headache to hunt down... |
02:57:13 | raptor | foir 016 at least |
02:57:15 | karamazovapy | of course, the beauty is that you don't actually have to aim, thanks to rotation |
02:57:28 | raptor | haha, yeah |
02:59:03 | karamazovapy | but I'm not sure it's anything more than a cosmetic problem |
03:01:28 | raptor | your test server is weird sam686 |
03:01:45 | sam686 | what is so weard? |
03:02:03 | raptor | cmdr's map zooms waaaay out |
03:02:11 | raptor | and it has a creepy lonely feel |
03:02:18 | karamazovapy | probably just the map? |
03:02:22 | raptor | then i came across a single solitary barrier |
03:02:53 | raptor | yeah, just the map |
03:02:54 | karamazovapy | I think I just crashed on join |
03:03:08 | raptor | yes - we have adding bugs since your revision |
03:03:14 | karamazovapy | ok |
03:03:37 | sam686 | Iit is just a level that is weard, zzzz71.level |
03:03:55 | karamazovapy | I'm gonna go sketch up a new level or two |
03:03:58 | karamazovapy | later |
03:04:02 | raptor | later |
03:04:08 | raptor | and thanks! |
03:08:37 | sam686 | this is where it delete WallSegmentEditor http://sam686.maxhushahn.com/upload/text1201/120122_21-01-21.txt |
03:10:08 | raptor | i think it was this rev that did it: https://code.google.com/p/bitfighter/source/detail?r=a2cbc98388bb1578463a11caba6ee64f4df49987 |
03:21:33 | raptor | something happened recently with soccer ball - it seems to slow down too fast |
03:23:25 | raptor | or maybe that has always been there? |
03:45:12 | | sam686 Quit (Read error: Connection reset by peer) |
03:49:26 | | sam686 has joined |
03:49:26 | | ChanServ sets mode +v sam686 |
03:51:29 | raptor | welcome back |
04:01:41 | | karamazovapy Quit (Read error: Connection reset by peer) |
04:28:11 | | karamazovapy has joined |
04:33:17 | raptor | sam686: want to do some more play testing? I just committed the Core-being-attacked-warning |
04:34:00 | | BFLogBot - Commit b8c7cd10a90a | Author: buckyballreaction | Log: Render a warning if a Core is being attacked |
04:34:12 | karamazovapy | what does that do? |
04:34:52 | raptor | just addes a flashing red/yellow circle around the team's Core score, let me get a screen shot |
04:35:09 | raptor | i couldn't think of much to render - so it can definitely use improvement |
04:35:11 | karamazovapy | glad it's not a global audio event...that could get pretty annoying |
04:36:51 | raptor | red: http://sam686.maxhushahn.com/upload/111screenshot_6.png |
04:37:00 | raptor | yellow: http://sam686.maxhushahn.com/upload/11screenshot_7.png |
04:37:13 | raptor | nothing special, but the framework for the alert is in |
04:38:25 | raptor | flashes about 3 times a second |
04:40:31 | karamazovapy | seems like a good system |
04:42:05 | raptor | i wasn't sure about one thing: it will continue flashing for 2 seconds after the last damage was done - is this too long? |
04:43:20 | karamazovapy | you could make it stop instantly, but I think you're probably okay |
04:43:42 | raptor | yeah, instant meant if a stray burst got it, you'd never know... |
04:43:50 | raptor | wasn't sure how i should weigh it... |
04:44:51 | karamazovapy | I think you have to ask, what's the point of the alert? |
04:45:28 | raptor | to tell me when i'm being attacked... so continuous attack is work coming back to base... but not a stray hit |
04:45:35 | raptor | so i will reduce the time |
04:46:36 | karamazovapy | yeah, I don't think the 2 second delay has a significant negative impact, but I'm not sure it helps |
04:54:03 | | BFLogBot - Commit 2243b327a992 | Author: buckyballreaction | Log: Remove noisyness; also reduce Core attack warning duration |
04:54:05 | | BFLogBot - Commit 8521d40a36ed | Author: buckyballreaction | Log: Fix dedicated compile on older GCC |
04:54:24 | raptor | argh! misspellings in commit messages |
05:01:39 | raptor | if we ever need database space for the forums - i know which forum i'm going to delete first |
05:04:07 | | BFLogBot - Commit 0fd75226833b | Author: buckyballreaction | Log: Slightly better Core warning duration |
05:21:45 | raptor | well, i'm falling asleep - sam686 i'm still not sure why that crash exists |
05:21:57 | raptor | so i'm heading to bed |
05:22:01 | raptor | night! |
05:32:46 | raptor | ok karamazovapy, so you can play on the latest without the rest of us crashing: http://sam686.maxhushahn.com/upload/bitfighter-016-preRC-2.7z |
05:33:08 | raptor | just don't try to undo/redo in the editor... |
05:33:17 | raptor | night1 |
05:33:24 | | raptor Quit (Remote host closed the connection) |
05:41:47 | karamazovapy | inb4 shitstorm... http://bitfighter.org/forums/viewtopic.php?f=44&t=1199 |
08:52:13 | | watusimoto has joined |
08:52:13 | | ChanServ sets mode +o watusimoto |
12:30:11 | | Zoomber Quit (Ping timeout: 252 seconds) |
14:38:17 | | raptor has joined |
14:38:17 | | ChanServ sets mode +o raptor |
14:42:27 | raptor | good morning! |
14:45:42 | raptor | hi watusimoto |
14:48:54 | raptor | your last check-in/merge introduced a segfault when doing an undo in the editor: http://pastie.org/3237290 |
14:49:19 | raptor | i always seem to ahve a hard time with these memory bugs... |
15:10:13 | | CrazyLinuxNerd has joined |
16:12:40 | | LoneWolfy has joined |
16:17:38 | | raptor Quit (Remote host closed the connection) |
17:33:22 | | watusimoto Quit (Ping timeout: 248 seconds) |
17:33:30 | | raptor has joined |
17:33:30 | | ChanServ sets mode +o raptor |
17:38:37 | raptor | haha, karamazovapy, i like Qui's response to your level |
18:05:14 | karamazovapy | yeah, that's a good one! |
18:06:17 | karamazovapy | I'm going to post another level later tonight, but I'm not going to say anything about either of them |
18:06:24 | raptor | great! |
18:45:12 | raptor | i hate xcode |
18:45:47 | raptor | looks like i'm going to have to divide up the Mac builds - I will do a 32bit (x86/pcc) universal, and a 64bit (x86_64 only) build |
18:57:39 | | LordDVG has joined |
19:01:15 | | LordDVG Quit (Remote host closed the connection) |
19:05:59 | | LordDVG has joined |
19:17:15 | | LordDVG Quit (Read error: Connection reset by peer) |
19:21:03 | | LordDVG has joined |
19:47:12 | | LordDVG Quit (Ping timeout: 255 seconds) |
20:43:33 | | LoneWolfy Quit (Ping timeout: 248 seconds) |
22:06:45 | | LoneWolfy has joined |
22:30:58 | | BFLogBot - Commit 6ea0cbc7d115 | Author: buckyballreaction | Log: Xcode project changes: - remove dedicated compile (sorry Zoomber) - modify DMG build script to also cut out needless architectures from framework fat binaries - some clean-up and addition of missing classes |
22:31:00 | | BFLogBot - Commit 711024591066 | Author: buckyballreaction | Log: Building and stripping all frameworks works now for both 32bit Universal and 64bit Intel release builds. Oh, and the game actually runs again... |
22:47:40 | | raptor Quit (Remote host closed the connection) |