Timestamps are in GMT/BST.
| 00:47:12 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 01:07:54 | raptor | sam686: i think the editor is worse now |
| 01:19:45 | | CrazyLinuxNerd has joined |
| 01:34:22 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 02:21:12 | raptor | sam686: that last check-in of yours is what is creating a load of editor problems |
| 02:21:39 | raptor | i just narrowed it down to that one: f35c54050536 |
| 02:21:46 | raptor | using hg bisect |
| 02:38:41 | | koda Quit (Quit: koda) |
| 02:44:16 | raptor | found the problem: item.cpp:90 |
| 02:44:28 | raptor | your commenting out that line causes all the editor problems... |
| 02:44:40 | raptor | well, just the ones introduced recently.. |
| 02:44:44 | raptor | i wonder why? |
| 02:55:52 | | sam686` has joined |
| 02:56:25 | sam686` | i am kind of cold, that i feel like staying on my bed with a blanket, with my laptop |
| 02:56:37 | raptor | hi |
| 02:56:50 | raptor | brrrr - we finally got hail/snow here |
| 03:03:36 | raptor | are you currently attending college, sam686`? |
| 03:03:55 | sam686` | no.. |
| 03:04:16 | raptor | ok, just curious |
| 03:04:40 | sam686` | i guess only Item::setActualPos(pos) does setVert(point, 0), not MoveObject::setActualPos(pos) |
| 03:05:20 | raptor | i don't understand why it's needed |
| 03:05:24 | raptor | it boggle smy mind |
| 03:08:55 | raptor | is it because there are two copies of the item somehow? |
| 03:08:55 | sam686` | i think i may have found a way to get rid of PointGeometry.mPos, change it to getExtent().getCenter() |
| 03:09:21 | sam686` | its because there is multiple places MoveObject position get stored. |
| 03:09:39 | raptor | ah |
| 03:27:39 | raptor | want me to commit that minor change that fixes the editor? |
| 03:28:15 | raptor | actually - your copy constructor messes up stuff, too |
| 03:29:20 | raptor | when copying point items, they're team is reset and their position... |
| 03:30:25 | raptor | i will revert some changes and commit, unless you already did so |
| 03:36:00 | | BFLogBot - Commit 5e6cd8bc56d4 | Author: buckyballreaction | Log: Revert commented-out code - why on earth do we need this? This fixes starting position of some items in editor |
| 03:36:02 | | BFLogBot - Commit 0553825576b2 | Author: buckyballreaction | Log: Revert addition of Item copy constructor - fixes objects losing location and team when copied |
| 03:41:03 | raptor | back to the drawing board with that evil bug, i guess... |
| 03:58:10 | sam686` | there, i commited and pushed a change that removes PointGeometry::mPos, so one less place to store position for items. |
| 03:58:31 | raptor | ok |
| 03:58:34 | raptor | i'm trying to track down the evil bug again... |
| 03:58:56 | sam686` | it seems to fix not being able to select items in editor though.. |
| 03:59:03 | raptor | really?? |
| 03:59:05 | raptor | must test... |
| 04:01:06 | | BFLogBot - Commit 80aa48b2a7d9 | Author: sam8641 | Log: Remove PointGeometry::mPos, PointGeometry getVert now does getActualPos |
| 04:01:19 | raptor | evil bug is still there.. |
| 04:02:10 | sam686` | for which items? polygons? |
| 04:02:33 | raptor | do you have my level i made for the simple test on the wiki? |
| 04:02:46 | raptor | #39 here: http://bitfighter.org/wiki/index.php?title=Buglist_016 |
| 04:03:15 | raptor | just follow exactly what I do to duplicate the evil bug |
| 04:05:31 | sam686` | i seem to get a crash on undo (ctrl + Z), let me try rebuild the whole thing first and see if the crash is still there.. |
| 04:10:28 | sam686` | well, while it may happen on polygons, it doesn't happen to point items anymore... |
| 04:10:43 | raptor | is a spawn point a polygon? |
| 04:10:49 | sam686` | no |
| 04:11:20 | raptor | because it still happens with spawn points |
| 04:11:47 | raptor | move that spawn point on my test level outside the lineitem after an undo, and deselect it - you cannot reselect it |
| 04:20:50 | sam686` | i can see it is a problem... for both spawn and zone |
| 04:21:26 | raptor | yeah, i have no idea what the problem could be yet... |
| 04:21:51 | sam686` | but, the problem only starts happens on Undo it seems |
| 04:21:58 | raptor | correct |
| 04:22:19 | raptor | it could be something isn't saved properly in saveUndoState |
| 04:22:35 | raptor | when making a copy of the editorObjectDatabase... |
| 04:26:37 | raptor | we;ve got to reconcile the Geometry classes and BfObject some day... |
| 04:27:04 | raptor | PointGoemetry -> BfObject -> Geometry doesn't seem right |
| 04:29:07 | sam686` | I may have found that, objects are in grid database, but DatabaseObject have mDatabase = 0x00000, so it doesn't know how to update the grid database when extents have changes |
| 04:30:57 | raptor | it happens with both undo systems, so it can be with creating a new EditorObjectDatabase.. |
| 04:31:03 | raptor | *can't |
| 04:31:06 | raptor | can't be |
| 04:32:31 | sam686` | there is EditorObjectDatabase by itself, and there is DatabaseObject for all GameObjects / BfObjects |
| 04:32:47 | sam686` | the problem is DatabaseObject have a GridDatabase *mDatabase |
| 04:33:12 | sam686` | so if you call setExtent, the object itself need to know which database is in mDatabase.. |
| 04:33:30 | raptor | is that because it is a pointer? and that isn't copied when cloning? |
| 04:33:52 | sam686` | GridDatabase *mDatabase is simply a pointer.. |
| 04:36:02 | raptor | i see you are right, it's not in a database after undo |
| 04:46:03 | raptor | in EditorObjectDatabase::addToDatabase |
| 04:46:07 | raptor | adding eObj->addToDatabase(this); |
| 04:46:10 | raptor | doesn't work |
| 04:49:29 | sam686` | i think i may have got it working now.. |
| 04:50:02 | raptor | do you have a link to your hg repo i can see? |
| 04:53:20 | sam686` | http://208.107.12.78:8000/ |
| 04:53:43 | raptor | i'm going to pull from there.. |
| 04:54:55 | sam686` | note, you might end up pulling several un-merged branches... |
| 04:55:04 | raptor | ah, yes i did... |
| 04:55:07 | raptor | that's ok |
| 04:55:11 | raptor | i got the right one |
| 04:56:03 | raptor | you fixed the evil bug!! |
| 04:56:21 | raptor | so the real question - why isn't mDatabase set already when doing a copy? |
| 04:56:47 | sam686` | it might be pointing to wrong database? not sure.. |
| 04:58:05 | sam686` | maybe a better place to set mDatabase is in EditorObjectDatabase::copy |
| 04:58:18 | raptor | that's what i'm thinking, too... |
| 04:59:23 | sam686` | only problem, i don't see any object's clone... |
| 05:00:55 | sam686` | well, not sure which will be a better place to put in the set database object.. |
| 05:01:23 | raptor | let me test something... |
| 05:06:37 | sam686` | i think i have found a better and simpler place to put it.. --rev d675338d7b87 |
| 05:08:04 | raptor | that's it! |
| 05:08:08 | sam686` | i will push the changes on d675338d7b87 to google code |
| 05:08:15 | raptor | great!!! |
| 05:08:56 | raptor | wow, good find |
| 05:09:44 | raptor | want to do some more play testing? |
| 05:10:07 | sam686` | ok |
| 05:10:07 | raptor | or do you think the game itself is solid enough now? |
| 05:10:56 | sam686` | it seems like there is no more errors, are there? |
| 05:11:15 | | BFLogBot - Commit d675338d7b87 | Author: sam8641 | Log: Fix a problem with EditorObjectDatabase::copy, set new copy to new database |
| 05:11:17 | raptor | just the wall building with levelgen in editor? |
| 05:12:26 | raptor | here is watusimoto's short list of bugs: http://pastie.org/3221815 |
| 05:15:03 | sam686` | what happened to the in game turrets? http://sam686.maxhushahn.com/upload/turrets_problem.png |
| 05:15:11 | raptor | i'm in you level |
| 05:15:13 | raptor | i see it |
| 05:15:18 | raptor | rendering is wrong |
| 05:15:28 | raptor | because of using a different mPos? |
| 05:15:34 | raptor | err... i mean center |
| 05:16:28 | sam686` | must be something to do with pach / unpack problem... |
| 05:16:43 | raptor | i don't know - i think it's just the rendering |
| 05:16:58 | sam686` | because the server side appears fine, but the client side isn't, probably pack / unpack at wrong position |
| 05:18:50 | raptor | i will mark off the bug on the wiki |
| 05:40:09 | sam686` | ok, i have just fixed turret going out to space problem, in this case, by adding mPos to EngineeredItem |
| 05:40:43 | | raptor Quit (Remote host closed the connection) |
| 05:41:12 | | sam686 Quit () |
| 05:41:18 | | BFLogBot - Commit 32f86f1566de | Author: sam8641 | Log: turret going out to space, added mPos for EngineeredItem |
| 05:41:54 | | raptor has joined |
| 05:41:54 | | ChanServ sets mode +o raptor |
| 05:42:03 | | sam686` is now known as sam686 |
| 05:42:09 | raptor | back |
| 05:42:14 | | ChanServ sets mode +v sam686 |
| 05:42:53 | raptor | i'm going ot make a quick test level with all the items in it... |
| 05:43:01 | sam686 | double "016 test server on master"? |
| 05:43:35 | raptor | oops, killed one, let me update it... |
| 05:44:12 | sam686 | "016 test server on master" have a turret floating out to space problem... |
| 05:44:20 | raptor | yes, recompiliing... |
| 05:45:47 | raptor | ok, back up |
| 05:46:43 | sam686 | ok, looks good.. |
| 05:46:57 | raptor | yes? |
| 05:46:59 | raptor | ok |
| 05:47:02 | raptor | what should we test? |
| 05:47:44 | sam686 | not sure, maybe test if all my levels and bots still work? |
| 05:47:59 | raptor | ok |
| 05:51:30 | raptor | crash? |
| 05:51:44 | sam686 | "If this ever gets triggered, please remove the comment above, and add a note about how we get here..." |
| 05:51:51 | sam686 | its a TNLAssert |
| 05:52:08 | sam686 | Ship.cpp line 1622 |
| 05:53:37 | sam686 | by the way my engineer bot is http://sam686.maxhushahn.com/bitfighter/robots/engineer.bot |
| 05:54:17 | sam686 | looks like the problem is trying to set loadout.. |
| 05:56:35 | sam686 | i might as well try delete a "// Safe to delete this block? " |
| 05:56:53 | raptor | sure |
| 05:56:56 | raptor | clean-up time |
| 05:58:52 | sam686 | ***ROBOT ERROR*** in robots/engineer.bot ::: Robot error handling event Tick: robots/engineer.bot:15: Variable 'ResourceItemType' cannot be used if it is not first declared.. Shutting bot down. |
| 05:59:53 | sam686 | oh, my error, i see setEnumName(ResourceItemTypeNumber, "ResourceItem"); should be "ResourceItemType" |
| 06:03:52 | sam686 | ok, pushed a change, that makes engineer bot work again. |
| 06:04:37 | raptor | ok |
| 06:04:58 | sam686 | haha, something tells me the bots needs some fixing - look at my server test host.. |
| 06:05:43 | raptor | can't connect |
| 06:05:45 | raptor | high ping |
| 06:06:17 | sam686 | http://sam686.maxhushahn.com/upload/text1201/120122_00-01-14.txt it seems to have just crash |
| 06:06:22 | | BFLogBot - Commit 267def76ae2e | Author: sam8641 | Log: Fix a few robot problems, to make Engineer bot work again |
| 06:07:09 | raptor | ok restarted on master |
| 06:08:02 | raptor | found a crash when loading soccerball into bitmatch... |
| 06:08:05 | raptor | i think... |
| 06:09:00 | raptor | just an assert... |
| 06:14:16 | sam686 | i think i found a problem in game.cpp line 383: if(gServerGame->getClientInfo(i)->getName() != mName) |
| 06:14:18 | sam686 | isn |
| 06:14:30 | sam686 | is that going to set all players authenticated? |
| 06:15:29 | sam686 | because all clients except its own will be set authenticated on that loop, it appears |
| 06:15:41 | raptor | not sure |
| 06:16:24 | | BFLogBot - Commit 664d8fc9661a | Author: buckyballreaction | Log: Remove pointless assert |
| 06:16:27 | sam686 | there is one way to test... |
| 06:18:07 | sam686 | i think i see now, the loop suppose to tell all clients except its own, that this player is authenticated.. |
| 06:20:42 | raptor | found another bug... |
| 06:20:46 | raptor | go to your test server |
| 06:21:26 | | BFLogBot - Commit 186b79d063f8 | Author: sam8641 | Log: Fix an error, Robots have NULL getConnection |
| 06:23:44 | sam686 | oops, now it wants to wuit, hit the wrong button on assert.. |
| 06:23:53 | raptor | haha |
| 06:24:21 | sam686 | this time, i think i got your removal of assert gone.. |
| 06:24:26 | sam686 | from updating |
| 06:24:26 | raptor | ok |
| 06:29:01 | sam686 | VoteStart crash... |
| 06:29:11 | raptor | hmmm... |
| 06:29:19 | raptor | so is that soccerball bug a bug? |
| 06:29:41 | sam686 | the usual problem, getClientInfo(i)->getConnection()->mVote = 0; trying to access Null gameconnection from robots |
| 06:30:20 | raptor | removing gameconnection from robots has given us tons of bugs |
| 06:33:20 | sam686 | more Null connection problem: getClientInfo(i)->getConnection() |
| 06:33:24 | sam686 | getClientInfo(i)->getConnection() |
| 06:33:40 | sam686 | wrong line, i couldn't copy yet.. |
| 06:33:50 | sam686 | edit and continue, see if that works' |
| 06:34:08 | raptor | hotswap code? |
| 06:34:21 | raptor | well, so far the editor has been stable... |
| 06:34:47 | raptor | ah flagspawns with soccerball... |
| 06:34:52 | raptor | forgot about that. |
| 06:35:14 | sam686 | looks like edit and continue fail. |
| 06:38:08 | sam686 | more null connection problem.. |
| 06:42:05 | raptor | maybe we should just look for getConnection()-> anywhere in the code |
| 06:47:24 | raptor | i saw all names duplicated onscoreboard |
| 06:47:42 | raptor | i crashed |
| 06:47:59 | sam686 | i got some tnl asserts... |
| 06:48:25 | raptor | ah yes, that's what i got |
| 06:48:44 | raptor | "We need a clientInfo for this ship!" |
| 06:51:29 | | BFLogBot - Commit 85749e143d06 | Author: buckyballreaction | Log: Quiet some noisiness |
| 06:56:31 | | BFLogBot - Commit e2101557908b | Author: buckyballreaction | Log: Don't use loadout indicator logic server-side |
| 06:57:10 | raptor | ok sam686, i think i'm off to bed... |
| 06:57:35 | sam686 | ok, night |
| 06:58:01 | raptor | good work tonight |
| 06:58:05 | raptor | night |
| 06:58:21 | | raptor Quit (Remote host closed the connection) |
| 07:01:33 | | BFLogBot - Commit a5746ae4d587 | Author: sam8641 | Log: Fix some Null game connection pointer from robots |
| 09:37:53 | | Watusimoto has joined |
| 10:41:49 | | koda has joined |
| 10:49:33 | | LordDVG has joined |
| 10:57:29 | | LordDVG Quit (Remote host closed the connection) |
| 12:15:51 | | koda Quit (Quit: koda) |
| 14:03:29 | | CrazyLinuxNerd has joined |
| 15:04:10 | | raptor has joined |
| 15:04:10 | | ChanServ sets mode +o raptor |
| 15:04:15 | raptor | good morning! |
| 15:08:41 | CrazyLinuxNerd | good day! |
| 15:35:10 | karamazovapy | are we really down to TWO bugs? |
| 15:35:23 | raptor | looks like just minor things left... |
| 15:35:44 | karamazovapy | whoa whoa whoa whoa...so 016 is gonna exis? |
| 15:35:49 | karamazovapy | +t |
| 15:35:55 | raptor | haha, i sure hope so |
| 15:36:08 | karamazovapy | neat |
| 15:36:26 | raptor | Watusimoto: have you done any more work on bug #21.1 - the wall rendering in levelgen preview? |
| 15:38:12 | Watusimoto | I've confirmed it's still broken :-) |
| 15:38:30 | Watusimoto | I think there is only one small step to fix it |
| 15:38:39 | Watusimoto | well, one step |
| 15:38:41 | Watusimoto | maybe two |
| 15:38:53 | karamazovapy | I'm gonna have to make some Core levels for the next BBB |
| 15:38:57 | raptor | that was why you did the WSM refactor, correct? |
| 15:39:31 | Watusimoto | the editor needs to 1) insert the new walls into a serparate db, which I think it does already |
| 15:39:43 | raptor | yes |
| 15:39:48 | Watusimoto | then 2) it needs to rebuild all the wall edges and segments, using that database, which I think it does not yet do |
| 15:40:12 | Watusimoto | the rebuild methods need a minor refactor to get the various parts they need (edge database, etc.) from the main database they are handed |
| 15:40:21 | Watusimoto | right now they aer passed those parts separately |
| 15:40:54 | Watusimoto | and 3) when we draw, we need to draw from the main database and from the separate db |
| 15:41:03 | Watusimoto | which may or may not already happen |
| 15:41:22 | raptor | so what exactly was your refactor doing to make this easier? |
| 15:41:28 | raptor | i don't remember |
| 15:41:30 | Watusimoto | these aer all easy and straightforward, and i keep trying to work on them but am being distracted by real life |
| 15:41:49 | Watusimoto | the refactor put the wsm onto the database, so now we can do step 2 |
| 15:41:55 | raptor | ok |
| 15:42:02 | raptor | let me see what I can do... |
| 15:42:40 | raptor | oh, on your paper list... the selectWeapon one - did you mean for all the logic to be client-side? including the server->client message about switching weapons? |
| 15:43:08 | Watusimoto | yes -- the issue is clients can turn off weapon indicators |
| 15:43:23 | raptor | that doesn't seem like it's an issue... |
| 15:43:27 | Watusimoto | if indicators are off, they should get messages |
| 15:43:32 | Watusimoto | if indicators are on, they shoudl not |
| 15:43:38 | raptor | ahhh.... |
| 15:43:43 | raptor | now i get it |
| 15:43:43 | Watusimoto | the case is that the decision about messages is being made on the server |
| 15:43:53 | Watusimoto | whihc has no idea about whether indicators are on or off |
| 15:44:01 | Watusimoto | so messages are sent based on the server setting |
| 15:44:07 | Watusimoto | but |
| 15:44:07 | raptor | i didn't know that messages should not be sent if indicators are on.. |
| 15:44:19 | Watusimoto | "you've changed weapon to..." |
| 15:44:29 | raptor | Burst selected |
| 15:44:40 | Watusimoto | the real question, however, is if we want to allow disabling of indicators at all |
| 15:44:50 | Watusimoto | if we get rid of that, this whole case becomes moot |
| 15:45:14 | Watusimoto | k is, as far as I know, the only person who wants this option, and, as far as I know, he has disabled it because it doesn't work properly |
| 15:45:19 | raptor | I think i can fix this without the removal o fthe option |
| 15:45:42 | raptor | speaking of server options - should we allow an 'engineerAbuse' INI option? |
| 15:45:53 | Watusimoto | of course you can, but the question is do we want the option? it's something that (almost) no one uses, and will continue to be a support issue |
| 15:45:59 | Watusimoto | well, fix it if you like |
| 15:46:06 | Watusimoto | that;s the issue |
| 15:46:22 | raptor | ah |
| 15:46:27 | Watusimoto | there may be other problems with disabling indicators; I don;t know, as I don't ever do it |
| 15:46:46 | raptor | some of the more popular levels (Castles on the 'Gibbed' server) require the old engineer logic... |
| 15:47:07 | Watusimoto | old engineer logic being allowing ffs anywhere? |
| 15:47:16 | raptor | almost anywhere yes |
| 15:47:26 | Watusimoto | why do they require it? |
| 15:48:11 | raptor | the level is built to allow engineer anywhere and to allow both teams to use it that way |
| 15:48:28 | Watusimoto | and it somehow becomes "broken" wiht out new changes? |
| 15:48:33 | Watusimoto | with our |
| 15:48:56 | raptor | yeah - barriers are in lots of spots purposefully close to good places to do forcefields |
| 15:49:17 | raptor | have you not seen the level? |
| 15:49:22 | Watusimoto | but it lets you creat impossible levels, no? |
| 15:49:30 | raptor | no, not really |
| 15:49:45 | raptor | it was built well to always allow a way to still get the flag |
| 15:49:56 | Watusimoto | ok, so what do you propose? |
| 15:50:03 | Watusimoto | a "allowImpossibleLevels" special? |
| 15:50:09 | raptor | no |
| 15:50:11 | Watusimoto | that allows ffs to go anywhere? |
| 15:50:26 | raptor | just a server option to allowForcefieldAbuse |
| 15:50:31 | raptor | or something |
| 15:50:46 | Watusimoto | allowImpossibleLevels == allowForcefieldAbuse |
| 15:50:52 | raptor | oh yes |
| 15:50:53 | raptor | sorry |
| 15:50:57 | raptor | yes, that |
| 15:50:57 | Watusimoto | np :-) |
| 15:52:17 | raptor | that would require the abuse logic to move server-side; right now a hacked client could put forcefields anywhere they please |
| 15:52:55 | Watusimoto | the logic should run both client side and server side |
| 15:53:06 | Watusimoto | client side shoudl work as is |
| 15:53:16 | Watusimoto | same code could be run on the server, and could just fail silently |
| 15:53:50 | Watusimoto | the only way the serverside check would fail is if we have a hacked client, and they I don;t care about showing the player a nice message |
| 15:55:29 | Watusimoto | if we haev a allowForcefieldAbuse flag, we'll need to send that flag to the client (probably alongside the enableEngineer flag), and disable your nice client side checks |
| 15:56:18 | raptor | OK, but i'm still wondering if we should have a flag like that |
| 15:56:27 | raptor | or maybe it should be a level special? |
| 15:56:58 | Watusimoto | it would be a level special, sure, how else would we do it? |
| 15:57:10 | raptor | server option |
| 15:57:22 | raptor | just a particular server would allow it |
| 15:57:40 | Watusimoto | definitley a level parameter, not a server parameter |
| 15:58:30 | Watusimoto | I think I prefer allowFFAbuse to my proposal |
| 15:58:46 | raptor | as wording, you mean? |
| 15:58:48 | raptor | :) |
| 15:58:59 | Watusimoto | yes |
| 15:59:08 | Watusimoto | it sounds like you think we need this capability |
| 15:59:19 | Watusimoto | for certain levels |
| 15:59:29 | Watusimoto | it;s clear we need your abuse protection for most levels |
| 15:59:35 | Watusimoto | so a special is the only solution |
| 15:59:43 | Watusimoto | and not a difficult one |
| 15:59:47 | raptor | every week day i go on a play, it seems lots of school kids are playing that 'Castles' level on 'Gibbed' server |
| 16:00:08 | Watusimoto | nor, I think, does it violate the idea of consistent rules, at least not too much |
| 16:00:14 | raptor | ok |
| 16:00:25 | Watusimoto | people like engineer, sadly |
| 16:00:44 | Watusimoto | I've conluded it was probably a mistake to add, but that;s a done deal |
| 16:00:57 | Watusimoto | I don;t think we can take it away :-) |
| 16:01:20 | Watusimoto | so let's implemetn your flag idea |
| 16:01:25 | raptor | ok |
| 16:01:41 | raptor | so in editor, we have 'Allow engineer' and 'Allow Forcefield Abuse' now? |
| 16:02:22 | raptor | or maybe we hide it and let people have to figure out how to add the abuse flag to enable :) |
| 16:04:29 | Watusimoto | yes |
| 16:04:55 | raptor | to which? |
| 16:04:58 | Watusimoto | if allowEgineer is not speicified , allowFFAbuse or allowEngrAbuse would do nothing |
| 16:05:31 | Watusimoto | you were asking if we should expose it in the editor? |
| 16:05:35 | raptor | yes |
| 16:06:04 | Watusimoto | probably; maybe the editor can have a 3-way toggle |
| 16:06:31 | Watusimoto | Engineer: Disabled / Allowed / Allowed with Abuse (Not recommended) |
| 16:06:43 | raptor | ha! I like it |
| 16:07:03 | Watusimoto | or maybe disbaled/allowed/unlimited (n.r.) |
| 16:12:44 | Watusimoto | on a different topic |
| 16:12:47 | Watusimoto | my son has the following core suggestions: he thinks there should be an alarm or something when an enemy player comes within a certain radius of the core |
| 16:13:14 | Watusimoto | I could see that being cool, or annoying... |
| 16:13:19 | raptor | interesting |
| 16:13:34 | Watusimoto | maybe some sort of visual indicator when a core is under attack |
| 16:13:45 | Watusimoto | like the core symbol in the scoreboard flashing? |
| 16:13:54 | raptor | the game 'gate88' does this - if a building in your base is being attacked, the health bar starts going goofy |
| 16:14:07 | Watusimoto | since you like flashing |
| 16:14:17 | raptor | i think it's a good idea |
| 16:14:21 | Watusimoto | but I think some indicator might be useful |
| 16:14:38 | raptor | yes |
| 16:14:50 | Watusimoto | ok, well think about how to best represent it, and I say we try doing it if it isn;t too hard |
| 16:15:02 | raptor | ok, i'll add to wiki |
| 16:15:12 | Watusimoto | I'm being summoned to put togeteher more furnuture... I'll be back on later |
| 16:15:17 | raptor | later |
| 16:15:19 | raptor | and thanks |
| 16:15:24 | Watusimoto | :-) |
| 16:15:28 | Watusimoto | bye! |
| 16:15:35 | raptor | bye |
| 16:23:00 | raptor | can anyone tell me the general difference in usage between readControlState and unpackUpdate methods? |
| 16:45:15 | raptor | karamazovapy: now that the editor is pretty stable, want a copy of 016 to build with? |
| 16:51:20 | | raptor Quit (Read error: Operation timed out) |
| 16:58:21 | | raptor has joined |
| 16:58:21 | | ChanServ sets mode +o raptor |
| 17:17:24 | | BFLogBot - Commit 4ee6d8fb68c1 | Author: buckyballreaction | Log: Finish moving loadout indicator messages client-side |
| 17:25:09 | karamazovapy | sure |
| 17:27:06 | raptor | here you go: http://sam686.maxhushahn.com/upload/bitfighter-016-preRC.7z |
| 17:27:51 | raptor | this is a 'release' build, so you shouldn't get those annoying pop-up debug messages... but you may experience more crashes... |
| 17:27:56 | raptor | (but hopefully not) |
| 17:28:08 | karamazovapy | save early, save often |
| 17:28:15 | raptor | hehe, yep |
| 17:35:51 | raptor | should i make the level Special 'AbusiveEngineer' or 'EngineerWithAbuse' or just 'EngineerAbuse' |
| 17:36:01 | raptor | because whatever I choose sticks with us... |
| 17:36:23 | karamazovapy | is that actually going to be grandfathered in? |
| 17:36:33 | raptor | yeah - it is simple enough |
| 17:37:01 | karamazovapy | how about something like ProximityEffect |
| 17:37:05 | raptor | sigh - them grandfathers... |
| 17:37:32 | raptor | well, we may expand or change the logic... |
| 17:37:33 | karamazovapy | although I guess that isn't very descriptive of engineer itself |
| 17:37:47 | raptor | so i'm looking for a more generic name |
| 17:38:04 | karamazovapy | LimitedEngineer/FullEngineer |
| 17:38:06 | karamazovapy | ? |
| 17:38:28 | raptor | and in the editor, it will be three options: Off, Engineer, <abusiveEngineer?> |
| 17:39:09 | raptor | the third option to allow abuse will have a "(not recommended)" text next to it |
| 17:39:11 | karamazovapy | are we trying to make it so that all current engineer levels will use the limited rules? |
| 17:39:21 | raptor | oh yes - and they will |
| 17:39:40 | karamazovapy | so we really are looking for an alternate title for old engineer |
| 17:39:40 | raptor | level owners will have to explicitly specify this option to allow the previos abuse behavior |
| 17:40:05 | karamazovapy | because limited engineer will just be "engineer" |
| 17:40:29 | raptor | correct - but i like to think of it as 'normal engineer' |
| 17:40:30 | karamazovapy | why don't we leave the old one out of the editor entirely and make people adjust the code? |
| 17:40:41 | raptor | that was my suggestion too :) |
| 17:40:50 | karamazovapy | that might have my vote |
| 17:41:36 | karamazovapy | NoRulesEngineer? |
| 17:41:49 | karamazovapy | OpenEngineer |
| 17:42:01 | karamazovapy | SandboxEngineer |
| 17:42:10 | raptor | ooo... that is a good one |
| 17:42:40 | raptor | i only bring this up because we'd have to stick with it |
| 17:42:41 | karamazovapy | DugeonEngineer, PuzzleEngineer |
| 17:42:49 | karamazovapy | *DungeonEngineer |
| 17:43:02 | raptor | you think? |
| 17:43:04 | karamazovapy | if we're going to introduce a dungeon gametype at somepoint |
| 17:43:33 | raptor | Dungeon is synonymous to Sandbox for us, right? |
| 17:43:41 | karamazovapy | some of the dungeonesque puzzles might require forcefield placement near walls |
| 17:44:31 | karamazovapy | I don't think it makes a huge difference, but the option for consistency with the open gametype is available |
| 17:44:57 | raptor | yes, i think consistency is important |
| 17:45:25 | karamazovapy | Watusimoto - do you have a strong opinion on what the future dungeon gametype would be called? |
| 17:46:56 | raptor | I think 'Dungeon' was essentially already decided |
| 17:50:53 | raptor | EngineerExploit |
| 17:52:48 | raptor | I'll just make it 'DungeonEngineer' for now |
| 17:59:54 | | Watusimoto Quit (Ping timeout: 252 seconds) |
| 18:14:24 | raptor | sam686: if you're around, do you have a diff of what you tried to do to make the engineering test logic server-side? |
| 18:16:21 | sam686 | to disable engineerisng checking client side, engineerHelper.cpp line 189, try using if(true) instead of if(deployer.canCreateObjectAtLocation... |
| 18:17:08 | raptor | ah, there it is... i forgot it was called from the helper... |
| 18:17:13 | raptor | thanks! |
| 18:18:16 | raptor | ok, looks like it is already both client and server sided - did you do this? |
| 18:21:02 | sam686 | maybe, because you stopped using wall segment database for engineer checking which fixed the server side detection problem |
| 18:24:47 | raptor | ok |
| 18:24:57 | raptor | yes, that is good now |
| 18:25:45 | raptor | ok |
| 18:26:14 | raptor | i created another flag server-side in gameType: mEngineerAbuseEnabled |
| 18:26:33 | raptor | how would i send that client-side? |
| 18:29:44 | sam686 | i will be adding an easier way to show that engineering is not allowed at that location |
| 18:30:22 | raptor | ok |
| 18:30:53 | sam686 | maybe, you can send mEngineerAbuseAnabled with the mEngineerAllowed or similar... |
| 18:31:06 | raptor | yes |
| 18:31:32 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 18:32:31 | | BFLogBot - Commit d7e5ebe6056d | Author: sam8641 | Log: Check deployment, so square will be green if allowed, red if not allowed, helps engineering |
| 18:32:52 | sam686 | there, easier to engineer, i hope... |
| 18:34:09 | raptor | taking a look.. |
| 18:34:51 | sam686 | as for sending mEngineerAbuseEnabled, you can add that into s2cSetLevelInfo |
| 18:40:01 | raptor | isn't that an expensive check? |
| 18:40:02 | raptor | canCreateObjectAtLocation |
| 18:40:12 | raptor | to be put into a render method? |
| 18:40:19 | | Watusimoto has joined |
| 18:41:32 | sam686 | it doesn't seem expensive at all, my fps goes from 180 no checking to 120 fps with checking... |
| 18:42:08 | sam686 | besides, it only ckecks when you are trying to engineer.. |
| 18:42:14 | raptor | ok |
| 18:42:27 | raptor | i do like it |
| 18:42:32 | Watusimoto | hi |
| 18:42:35 | raptor | i was just worried about performance |
| 18:42:43 | Watusimoto | reading back in the history... |
| 18:43:11 | Watusimoto | I think when we get down to it, dungeon will have to be a Special, not a proper gametype in iteself |
| 18:43:18 | raptor | awww |
| 18:43:22 | Watusimoto | because there are dungeons built around many existing gametypes |
| 18:43:50 | Watusimoto | I don;t see how to create a single dungeon gametype that will let people do what they want |
| 18:43:54 | raptor | i already considered that |
| 18:44:01 | Watusimoto | and... |
| 18:44:09 | raptor | the scoring methods in gametypes |
| 18:44:25 | sam686 | its easy to tell the clients (for "Select Levels") to show any GameTyoe names,, |
| 18:44:27 | raptor | i was going to add every possible scoring event and allow for a point for each one |
| 18:44:29 | Watusimoto | (that was a prompt for you to continue, not that I was going to continue) |
| 18:44:48 | raptor | (i was typety typing... slowly...) |
| 18:45:09 | Watusimoto | so a sort of multi-gametype |
| 18:45:11 | Watusimoto | polygame |
| 18:45:28 | raptor | correct - i found this out when creating CoreGameType - it was easy to make anything a scoring event |
| 18:45:46 | Watusimoto | well... that's an interesting thought |
| 18:46:06 | Watusimoto | but flag handling is different in different gametypes, no? |
| 18:46:17 | raptor | not for scoring |
| 18:46:22 | Watusimoto | in ctf vs. zc, for example |
| 18:46:44 | raptor | ah, see that's a different scoring event |
| 18:47:06 | Watusimoto | right -- but in non-ctf games, different things happen if flags touch |
| 18:47:16 | Watusimoto | usually nothing -- in ctf, something |
| 18:47:33 | raptor | take a look at enum ScoringEvent in gameType.h |
| 18:47:40 | Watusimoto | also, flag handling is completely different in Nexus |
| 18:47:44 | raptor | those events are triggered by each game type |
| 18:48:03 | Watusimoto | but I'll bet that there are very few dungeons that depend on ctf flag handling or nexus scoring |
| 18:48:05 | raptor | and then scoring is done based on the event |
| 18:48:17 | raptor | i have seen none that do it |
| 18:48:20 | Watusimoto | right; but if I die, does my ship emit a flag in dungeon? |
| 18:48:37 | raptor | ha! i'm on a completely different topic |
| 18:49:06 | Watusimoto | if I have a flag and I fly into an open nexus, what happens? |
| 18:49:07 | sam686 | i haven't hardly seen any nexus dungeon game type... |
| 18:49:08 | raptor | that is gameType specific and has nothing to do with the scoring event |
| 18:49:17 | Watusimoto | right |
| 18:49:31 | Watusimoto | but you are saying that dungeon will not be based on an existing gametype |
| 18:49:35 | raptor | yes, well we can ignore nexus events |
| 18:49:39 | Watusimoto | but will enable all scoring events |
| 18:49:39 | raptor | correct |
| 18:49:50 | raptor | all events minus some specific ones, if we wish |
| 18:50:35 | karamazovapy | dungeons are made primarily around retrieve and ctf gametypes |
| 18:50:40 | karamazovapy | mostly retrieve |
| 18:50:43 | Watusimoto | sam -- what gametypes have you seen for dungeons? |
| 18:51:08 | karamazovapy | nexus, ZC, soccer, HTF never happen |
| 18:51:15 | Watusimoto | ok, well, retrieve and ctf behave differently if a player with a blue flag runs over a red flag |
| 18:51:15 | karamazovapy | obviously not bitmatch |
| 18:51:20 | sam686 | retrieve, and ctf, mostly.. |
| 18:51:36 | karamazovapy | ctf dungeons would be easy to adjust into retrieve dungeons |
| 18:51:50 | Watusimoto | I guess existing games can continue to exist wihtout being labeld "dungeons" |
| 18:52:01 | karamazovapy | also true |
| 18:52:17 | Watusimoto | and future dungeons will just base themselves around whatever ruleset we decide on if they want the extra features we'll unlock in dungeon mode |
| 18:52:30 | sam686 | i have seen a few zone control dungeons.. |
| 18:52:38 | karamazovapy | really? which ones are ZC? |
| 18:52:58 | raptor | yes, i think i've seen ZC, too |
| 18:53:00 | Watusimoto | I think zc is a natural for dungeons |
| 18:53:21 | karamazovapy | flag carrying and death make ZC inconvenient |
| 18:53:23 | Watusimoto | 5 zones, each requiring solution to a different puzzle |
| 18:53:53 | karamazovapy | unless you allow multiple flags, you can only work one puzzle at a time |
| 18:54:11 | karamazovapy | but if you allow multiple flags, what's the point of using zone control over retrieve? |
| 18:54:30 | Watusimoto | well, even if we enable all scoring events in dungeon mode, I think it makes sense to allow the game to be based on the different rulesets allowed by different gametypes |
| 18:54:42 | Watusimoto | which would argue for a dungeon flag, rather than a dungeon gametype |
| 18:54:55 | karamazovapy | I dislike dungeons in the first place, so my opinion doesn't matter so much on this one |
| 18:55:03 | Watusimoto | well, sure it does |
| 18:55:34 | Watusimoto | because part of this is figuring out how to identify dungeons so the rest of us don;t have to play them :-) |
| 18:55:40 | raptor | haha |
| 18:56:26 | Watusimoto | we could even add an indicator in the join server section that showed which servers were certified dungeon free |
| 18:56:29 | raptor | i guess i see how ZC and and retrieve would conflict |
| 18:56:33 | sam686 | i have these dungeon maps: 4 ctf, 1 htf, 1 nexus, 15 retrieve, 4 zone control.. |
| 18:56:51 | Watusimoto | ok, well it doesn;t have to be resolved tonight -- that's a 016a feature |
| 18:56:56 | karamazovapy | Not sure how I feel about this marketing: |
| 18:56:57 | karamazovapy | |
| 18:56:57 | karamazovapy | Dear Amazon.com Customer, |
| 18:56:57 | karamazovapy | Customers who have purchased or shown interest in textbooks might like to know that when they spend $50 or more on new textbooks they get $5 in free MP3s. |
| 18:57:02 | raptor | by using an entirely new GameType - BUT, what if we just code another option 'flavor' for the dungeonGameType |
| 18:57:31 | Watusimoto | what do you mean? |
| 18:57:44 | karamazovapy | what if we left the gametype alone and used a specials flag? |
| 18:57:57 | Watusimoto | that's what I'm thinking at the moment |
| 18:58:08 | sam686 | a simple flag that simply changes the game type name.. |
| 18:58:13 | Watusimoto | yes |
| 18:58:28 | Watusimoto | Gametype: Dungeon (based on Zone Control) |
| 18:58:37 | Watusimoto | or Dungeon (Zone Control rules) |
| 18:58:40 | Watusimoto | or something |
| 18:58:52 | raptor | ah, see you are all thinking much simpler than I am |
| 18:58:53 | Watusimoto | except I really hate the name dungeon |
| 18:59:08 | raptor | spaceMazeCraze |
| 18:59:10 | Watusimoto | Puzzle (brought to you by Soccer) |
| 18:59:21 | karamazovapy | Sandbox (brought to you by Mattel) |
| 18:59:35 | raptor | Gauntlet |
| 19:00:13 | Watusimoto | have you decided on the name of the flag for allowing ClassicEngineer? |
| 19:03:11 | raptor | I might just go with 'AbusiveEngineer' |
| 19:03:50 | karamazovapy | I still kind of like OpenEngineer, but I dislike engineer in general |
| 19:05:05 | raptor | easy enough to change... i still haven't checked in yet... |
| 19:10:37 | Watusimoto | ClassicEngineer / OldEngineer / UnlimitedEngineer / BrokenEngineer |
| 19:10:51 | Watusimoto | CrappyEngineer |
| 19:13:33 | raptor | sam686: i added the flag to s2cSetLevelInfo, but it is always falst on the client end... i am missing something somewhere |
| 19:13:38 | raptor | *false |
| 19:15:28 | sam686 | are you sure, in GAMETYPE_RPC_S2C(GameType, s2cSetLevelInfo,..., you added a mEngineerBlahBlahEnabled = engineerBlahBlahEnabled; ? |
| 19:15:41 | raptor | yeah, let me get you my patch |
| 19:16:13 | sam686 | is it always false server side? |
| 19:16:54 | raptor | here is patch: http://sam686.maxhushahn.com/upload/abusive_engineer.diff |
| 19:17:08 | raptor | i'm pretty sure i set it to true when processing the Specials param |
| 19:18:37 | Watusimoto | haven't tested it yte, but: |
| 19:18:41 | Watusimoto | square will be green if allowed, red if not allowed |
| 19:18:45 | Watusimoto | looks like a great idea |
| 19:19:13 | raptor | be back in about 15 min.. |
| 19:30:53 | sam686 | raptor , the patch you give me, there is nothing wrong with mEngineerAbuseEnabled and a level having "Specials AbusiveEngineer" |
| 19:31:01 | sam686 | more like, the editor is getting rid of |
| 19:31:11 | sam686 | "AbusiveEngineer" in editor |
| 19:32:46 | sam686 | must be something missing in "string GameType::getSpecialsLine()" |
| 19:34:27 | raptor | ahh... |
| 19:34:36 | raptor | that editor... |
| 19:36:50 | Watusimoto | maybe UnrestrictedEngineer ? |
| 19:36:52 | raptor | you're right! that was it |
| 19:36:57 | raptor | ok |
| 19:36:59 | Watusimoto | or EngineerUnrestricted |
| 19:37:14 | raptor | I'm about to commit the logic for it |
| 19:37:23 | raptor | 'EngineerUnrestricted' ok? |
| 19:37:31 | Watusimoto | maybe AllowEngineer and AllowEngineerUnrestrcted (rather than two separate keywords)? |
| 19:37:56 | raptor | so just 'Engineer' is used now |
| 19:38:00 | raptor | in level files |
| 19:38:04 | raptor | do we want to break it? |
| 19:38:09 | Watusimoto | ok so Engineer and EngineerUnrestricted? |
| 19:38:19 | raptor | sounds good to me |
| 19:38:20 | Watusimoto | no need to break what we've got |
| 19:38:21 | | CrazyLinuxNerd has joined |
| 19:38:53 | raptor | ok i'll hcange it to that |
| 19:38:57 | Watusimoto | ok |
| 19:48:11 | raptor | ok, pushed |
| 19:48:19 | raptor | still have to add the editor option (if we really want to) |
| 19:48:53 | raptor | i'm almost inclined to have it be something you have to manually add to the file |
| 19:49:54 | raptor | gotta go - i'll be back in a few hours |
| 19:50:08 | | raptor Quit (Remote host closed the connection) |
| 19:52:40 | | BFLogBot - Commit f980d7bc485e | Author: buckyballreaction | Log: Grandfather in the unrestricted engineer behavior. Use 'EngineerUnrestricted' in a level file in place of 'Engineer' |
| 20:54:14 | | koda has joined |
| 22:03:06 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 22:10:53 | | raptor has joined |
| 22:10:53 | | ChanServ sets mode +o raptor |
| 22:11:43 | raptor | did i miss anything? |
| 22:16:27 | raptor | Watusimoto, sam686, are either of you working on the levelgen-wall bug? (If not, I can start it...) |
| 22:22:08 | Watusimoto | I AM |
| 22:22:13 | Watusimoto | oops, caps lock |
| 22:22:29 | Watusimoto | got distracted by news about the primariy in SC |
| 22:22:30 | raptor | i'm temporarily deafened |
| 22:22:41 | Watusimoto | somewhat stunned by the news |
| 22:22:47 | raptor | which news? |
| 22:22:54 | raptor | the win or the lose? |
| 22:22:56 | Watusimoto | newt gingrich winning the primary |
| 22:22:58 | Watusimoto | both |
| 22:23:27 | Watusimoto | I thought he would do ok, but I was pretty sure Romney would win |
| 22:24:04 | Watusimoto | think all I have to do to finish the case is the rendering |
| 22:24:25 | raptor | i still don't know what to think... |
| 22:24:35 | raptor | about any of the prospective candidates |
| 22:25:05 | raptor | do Belgians (or other Europeans) worry about the US presidential elections much? |
| 22:26:23 | Watusimoto | only the ones who want to show off their worldliness :-) |
| 22:26:39 | Watusimoto | they probably will closer to november |
| 22:28:51 | raptor | i guess i'll look into why robots get stuck on FFs |
| 22:30:24 | Watusimoto | ok, good |
| 22:30:28 | Watusimoto | getting close! |
| 22:31:34 | raptor | oh, so your paper list: http://pastie.org/3221815 |
| 22:31:44 | raptor | #1 is done |
| 22:31:57 | raptor | #3, i haven't been able to duplicate since sam's spawnshield fixes |
| 22:32:15 | raptor | #5 is ambiguous :) |
| 22:33:07 | raptor | #6: I found that those errors are given because there is no method for passing LUA errors back as /command errors |
| 22:33:21 | raptor | and i'm not sure how to do it.. |
| 22:34:46 | Watusimoto | you wrote it up@ |
| 22:34:47 | Watusimoto | ! |
| 22:35:03 | raptor | was that bad? |
| 22:35:30 | Watusimoto | no, great |
| 22:36:01 | Watusimoto | so for #6, do we need a mechanism? |
| 22:36:21 | raptor | well, i got into LUA territory again, and sort of got lost... |
| 22:36:30 | raptor | it already write to the oglconsole |
| 22:36:33 | Watusimoto | I see |
| 22:36:40 | raptor | and says "file not found" |
| 22:36:42 | raptor | there |
| 22:36:54 | Watusimoto | though it doesn't actually involve lua specifically, only the calling framework |
| 22:37:15 | Watusimoto | so there are two ways I can see to deal with it |
| 22:37:30 | Watusimoto | 1) bubble the error back up to the original caller |
| 22:37:44 | Watusimoto | or 2) print a message to the user at the point of the error |
| 22:37:54 | Watusimoto | (or 3) leave things alone, I suppose) |
| 22:38:28 | Watusimoto | we handle the logprintf bit via #2, right? |
| 22:38:54 | raptor | i think so, yes |
| 22:39:02 | Watusimoto | and we don't have enough context about how the script was run to do #2 with printing the message to the chat area |
| 22:39:14 | Watusimoto | unless... |
| 22:39:39 | raptor | robot.cpp:1834 |
| 22:39:44 | Watusimoto | what if we created another log consumer that dumped messages to the game message area |
| 22:40:01 | raptor | is how it is printed... |
| 22:40:24 | Watusimoto | that way whatever was logprintf'ed would get sent to the player's screen |
| 22:40:54 | raptor | i think that may be a good idea... |
| 22:41:18 | raptor | but should we do it for 016 (I'm not exactly sure what's involved - i've never messed with the logging stuff) |
| 22:41:24 | Watusimoto | at 1824, we have the game |
| 22:41:32 | Watusimoto | the game gives us access to a lot of stuff |
| 22:41:39 | Watusimoto | sorrt, at 1834 |
| 22:42:12 | Watusimoto | 1834 should be changed to a single logprintf |
| 22:42:31 | Watusimoto | with a correct LogConsumer::xxx thingy |
| 22:42:48 | Watusimoto | and the message will end up in both the logfile and the oglconsole |
| 22:43:32 | raptor | i found setupLogging in main.cpp |
| 22:43:36 | raptor | 978 |
| 22:44:36 | Watusimoto | console gets these msg types: |
| 22:44:37 | Watusimoto | AllErrorTypes |LogConsumer::LuaLevelGenerator | LogConsumer::LuaBotMessage | LogConsumer::ConsoleMsg |
| 22:45:26 | Watusimoto | we seem to use LuaBotMessage for bot errors: |
| 22:45:28 | Watusimoto | if(thisShip.isNull()) // This will only happen when thisShip is dead, and therefore developer has made a mistake. So let's throw up a scolding error message! |
| 22:45:28 | Watusimoto | { |
| 22:45:28 | Watusimoto | logprintf(LogConsumer::LuaBotMessage, "Bad programmer!"); |
| 22:45:28 | Watusimoto | return NULL; // Not right |
| 22:45:30 | raptor | ahhh... you set up a LogConsumer class |
| 22:46:10 | Watusimoto | I'm changing 1834 to send message using LogConsumer::LuaBotMessage category |
| 22:46:28 | raptor | ok |
| 22:46:59 | Watusimoto | so we could also create a log consumer that listens for LogConsumer::LuaBotMessage messages and prints those to the console under certain circumstances |
| 22:47:06 | raptor | and then that LogConsumer class has a writeString() method to output wherever you want... |
| 22:47:18 | Watusimoto | yes |
| 22:47:27 | raptor | prints to console? you mean print to UI? |
| 22:47:33 | Watusimoto | yes |
| 22:47:40 | Watusimoto | sorry |
| 22:48:10 | raptor | so a new class, something like UIGameLogConsumer |
| 22:48:21 | Watusimoto | or we could have a separate logprintf category that prints only to the UI, with prettier messages |
| 22:48:34 | Watusimoto | because sometimes console messages get long and ugly |
| 22:48:41 | raptor | yes, yes they do |
| 22:49:10 | Watusimoto | logprintf(LogConsumer::GameUIMessage, "Bot file not found; see console for details"); |
| 22:49:33 | Watusimoto | not sure if that's a good solution... alternatively: |
| 22:49:58 | Watusimoto | game->printMessageToUI("Bot file not found; see console for details"); |
| 22:50:22 | Watusimoto | though the game we have there is almost certainlhy a serverGame |
| 22:50:55 | Watusimoto | not sure which is better |
| 22:51:14 | Watusimoto | but I think either would solve the problem without trying to cascade the error message up the stack |
| 22:51:48 | Watusimoto | which would be akward without a real exception chain |
| 22:52:28 | raptor | yeah - it's server game... |
| 22:52:50 | Watusimoto | it would have to be |
| 22:52:52 | raptor | it would still have to use the s2cDisplayMessage |
| 22:53:03 | raptor | to tell the client |
| 22:53:19 | Watusimoto | actually, which might be good anyway, for remote users trying to run commands |
| 22:53:51 | Watusimoto | game->s2cDisplayMessage("Robot file not found"); |
| 22:54:11 | Watusimoto | console details would only be available to local player for the moment |
| 22:54:25 | Watusimoto | though at some point we should make console contents available remotely |
| 22:55:07 | Watusimoto | maybe via a network aware logprintf listener |
| 23:07:30 | raptor | sounds more complicated than I wished for... |
| 23:08:51 | Watusimoto | no, not at all |
| 23:09:17 | Watusimoto | is the game->s2cDisplayMessage("Filenot found"); easy enough? |
| 23:09:27 | raptor | sounds easy to me |
| 23:09:33 | Watusimoto | the other stuff is a future enhancement |
| 23:10:09 | Watusimoto | I think the s2cDM solution would fix the issue I was concerned with |
| 23:10:50 | Watusimoto | if it works, it might be a pattern for doing the same with other bot errors in the future |
| 23:10:50 | raptor | except that method is part of gameConnection |
| 23:11:26 | raptor | not game |
| 23:11:28 | raptor | hmm.. |
| 23:11:43 | Watusimoto | ah, and we don't kwnow which client wants to see the message |
| 23:12:04 | Watusimoto | because we would only send it to the person running the command |
| 23:12:33 | raptor | yep, i could pass in the pointer in to the Robot::processArguments method... |
| 23:12:41 | raptor | but that seems sloppy |
| 23:12:45 | Watusimoto | but only for this? |
| 23:12:46 | Watusimoto | yues |
| 23:12:47 | Watusimoto | yes |
| 23:12:49 | Watusimoto | i agree |
| 23:14:07 | Watusimoto | could have processArguments() return a string, "" == success, anything else is an error message |
| 23:14:14 | Watusimoto | kind of yucky |
| 23:14:32 | raptor | i guess that's true.. |
| 23:14:39 | raptor | not elegant either... |
| 23:14:45 | raptor | but more versatile |
| 23:14:50 | Watusimoto | could pass a string &errorMessage which we fill with an error message in the event that the method returns false |
| 23:15:05 | raptor | i kind of like that the best so far.. |
| 23:15:17 | Watusimoto | those are the two ways I know of to propigate the message up the stack, which is what we seem to be left with |
| 23:15:30 | raptor | i'll do the argument.. |
| 23:15:39 | Watusimoto | or we could wrap the whole thing in a try/catch and throw an exception |
| 23:15:42 | Watusimoto | java style |
| 23:15:47 | raptor | nooooooooooooooooooooo |
| 23:15:54 | Watusimoto | no? you like java! |
| 23:16:01 | raptor | i do enough of that at work... |
| 23:16:05 | Watusimoto | ha |
| 23:16:12 | raptor | i like java because it gets stuff done fast |
| 23:16:37 | Watusimoto | do you happen to know how many levels up we need to go to make this work? is it only one? |
| 23:16:51 | Watusimoto | I'll look if you don;t know |
| 23:16:56 | raptor | just the one, i think - there are two instances of 'see error log' messages |
| 23:17:05 | raptor | and both are because of calling methods in Robot:: |
| 23:17:29 | karamazovapy | anybody want to buy a hot tub? |
| 23:17:47 | karamazovapy | http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=130634966072&ssPageName=ADME:L:LCA:US:1123 |
| 23:17:49 | Watusimoto | your club needs a hot tub! VIP baby |
| 23:17:55 | raptor | a hot tub would be fun, but the energy payments no so much... |
| 23:18:30 | karamazovapy | did I mention I've raised $50,000 in private investment capital? |
| 23:18:35 | raptor | WOW |
| 23:18:53 | Watusimoto | great |
| 23:18:59 | Watusimoto | your mom loves you |
| 23:19:12 | Watusimoto | and had 50 large lying around, right? |
| 23:19:13 | Watusimoto | :-) |
| 23:20:08 | Watusimoto | so if it's only one level, pick the least evil way to pass the message up and let's just do it that wya |
| 23:20:25 | Watusimoto | @k awesome job on the money |
| 23:26:11 | raptor | ok, i did the argument thingamajig |
| 23:26:22 | Watusimoto | not too horrible, I hope? |
| 23:26:26 | raptor | so your #6 is done |
| 23:26:38 | raptor | not too bad... |
| 23:26:56 | Watusimoto | great |
| 23:27:51 | Watusimoto | why not try the idea of alerting when a player is threatening the core? |
| 23:27:57 | raptor | oh, i made a level with all the objects in it to test: http://sam686.maxhushahn.com/upload/test_object_suite.level |
| 23:28:01 | | BFLogBot - Commit 876236d193ac | Author: buckyballreaction | Log: Bot error message about missing file is sent to the client |
| 23:28:04 | Watusimoto | or ist aht a new feature |
| 23:28:11 | Watusimoto | great |
| 23:28:18 | raptor | everything about Core is *a new feature* |
| 23:28:22 | raptor | :) |
| 23:28:47 | Watusimoto | ha |
| 23:28:52 | | Watusimoto Quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 23:29:47 | | Watusimoto has joined |
| 23:29:50 | Watusimoto | wtf??? |
| 23:30:00 | raptor | last comment: 'ha' |
| 23:30:02 | Watusimoto | I was saying... |
| 23:30:09 | raptor | then 'Watusimoto has left this server' |
| 23:30:29 | Watusimoto | my son's other idea was to color the walls as you approach a core, so you know you're getting warmer |
| 23:30:38 | Watusimoto | and to give it a bit of an alien feel |
| 23:30:39 | raptor | oh man |
| 23:30:48 | Watusimoto | might not work as well for a blue core, though |
| 23:31:11 | Watusimoto | I'm not so hot on that idea, but wanted to mention it in case anyone else likes it |
| 23:31:30 | raptor | i don't even know how I could even program that in with our current systems |
| 23:31:43 | Watusimoto | but it might be cool in the immediate vicinity, to kind of make the walls reflect the color of an item |
| 23:31:58 | Watusimoto | well... there;s that, i suppose :-) |
| 23:32:00 | raptor | you mean hue slightly? |
| 23:32:04 | Watusimoto | yes |
| 23:32:14 | Watusimoto | I'm not sure how it would work either |
| 23:32:17 | raptor | every moving object would have 'warmth' |
| 23:32:25 | Watusimoto | not every object |
| 23:32:29 | Watusimoto | maybe only cores |
| 23:32:43 | Watusimoto | his original idea was to do that when approaching enemy bases |
| 23:32:51 | raptor | this means everyobject will need to constantly do database searches for its neighbors |
| 23:33:05 | Watusimoto | but when I tried to pin him down on what a base was, the idea sort of evaporated |
| 23:33:13 | Watusimoto | maybe only walls |
| 23:33:15 | raptor | haha |
| 23:33:27 | Watusimoto | it came back when he saw the cores |
| 23:33:39 | Watusimoto | which, so far, have 100% positive feedback |
| 23:33:46 | raptor | haha |
| 23:33:47 | Watusimoto | my kids and my wife, that is |
| 23:33:51 | raptor | oh... |
| 23:34:09 | raptor | two things about core: 1. do we want the heartbeat louder? 2. do we want to repair them? |
| 23:34:31 | Watusimoto | 1 not sure, haven;t spent enough time with them to know, probably not |
| 23:34:42 | Watusimoto | 2 I think yes |
| 23:34:58 | Watusimoto | they're so easy to kill and repair will be difficutl due to the energy involved |
| 23:35:18 | Watusimoto | so it might be a temptation toward self-destructive bahavior |
| 23:35:30 | raptor | ha |
| 23:35:50 | Watusimoto | think how long it would take to repair a damaged core |
| 23:35:56 | raptor | so so long |
| 23:36:02 | Watusimoto | one that could be damaged in like 5 seconds |
| 23:36:06 | raptor | and anyone doing it is an open target |
| 23:36:12 | Watusimoto | i say let them try |
| 23:36:16 | raptor | haha, oik |
| 23:36:17 | raptor | ok |
| 23:36:27 | Watusimoto | it's consistent with other items that can suffer damage |
| 23:36:39 | Watusimoto | except asteroids |
| 23:37:10 | Watusimoto | Let me tell you my idea for that graphical improvement to cores I alluded to a while back |
| 23:37:17 | raptor | ok |
| 23:37:30 | Watusimoto | I was thinking of rendering a very faint gray hexagon pattern on them, sort of like chicken wire |
| 23:37:49 | Watusimoto | maybe that slowly glided off to one side (or maybe not) |
| 23:37:58 | Watusimoto | to give them a sort of carbon-fibery look |
| 23:38:10 | raptor | you mean bounce along the interior? |
| 23:38:19 | raptor | or more stationary? |
| 23:38:25 | Watusimoto | not just one hexagon, but a whole skin of them |
| 23:38:26 | raptor | ah, chicken wire... |
| 23:38:28 | Watusimoto | more stationary |
| 23:38:39 | Watusimoto | maybe moving slightly, not sur |
| 23:38:40 | Watusimoto | e |
| 23:38:45 | Watusimoto | I have no idea if it would look good |
| 23:38:51 | Watusimoto | or how hard it would be |
| 23:39:00 | raptor | hmmm, a constrained mesh that rotates... |
| 23:39:19 | raptor | probably not too hard once I find code that someone else has written for it... :) |
| 23:39:53 | Watusimoto | probably just need to set up some sort of clip buffer |
| 23:40:28 | sam686 | http://sam686.maxhushahn.com/upload/Bitfighter.mod |
| 23:41:28 | Watusimoto | but... likely to look good? |
| 23:41:33 | sam686 | it was probably my fist time making my own "MOD" |
| 23:41:35 | Watusimoto | or just busy? |
| 23:41:40 | raptor | sam686: did you make that?? |
| 23:41:52 | sam686 | i made it, using bitfighter sounds.. |
| 23:41:58 | raptor | haha, it made me smile |
| 23:42:51 | Watusimoto | that's pretty funny |
| 23:43:04 | Watusimoto | our sounds ain't pretty! |
| 23:43:46 | raptor | ok, let me try to get repair working... then i'll work on core alert... |
| 23:43:50 | sam686 | i will be back in about 40 minutes, food. |
| 23:45:02 | Watusimoto | good |
| 23:45:13 | Watusimoto | I'll finish this editor work! |
| 23:45:19 | raptor | go go go! |
| 23:45:24 | Watusimoto | spending all my time chatting |
| 23:53:58 | raptor | healing works! but only if you can get close enough to the core center... |
| 23:57:49 | raptor | ok, tell me what you think if this idea.... |
| 23:58:08 | raptor | ship.cpp:763 |
| 23:58:17 | raptor | i comment out that test and i can heal Core |
| 23:58:24 | raptor | what would the side-effects be? |
| 23:58:43 | raptor | i can already see that you could repair turret and forcefield a little farther away... |
