Timestamps are in GMT/BST.
| 00:03:01 | | Watusimoto Quit (Ping timeout: 248 seconds) |
| 00:25:05 | | raptor Quit () |
| 01:16:50 | | sam686 has joined |
| 01:16:50 | | ChanServ sets mode +v sam686 |
| 02:00:59 | | sam686 Quit (Ping timeout: 245 seconds) |
| 02:02:19 | | sam686 has joined |
| 02:02:19 | | ChanServ sets mode +v sam686 |
| 03:28:53 | | raptor has joined |
| 03:28:53 | | ChanServ sets mode +o raptor |
| 03:30:28 | raptor | hi hi |
| 03:31:38 | sam686 | hi |
| 03:32:48 | kaen | hello |
| 03:33:48 | kaen | raptor, I think that core bug might have to do with the core's position being updated when dragged in the editor |
| 03:34:15 | kaen | actually, the vertices of it |
| 03:34:55 | raptor | we've had many editor-item position problems... |
| 03:35:07 | raptor | i'm actually suprised it works as well as it does... :) |
| 03:35:11 | kaen | lol |
| 03:35:17 | kaen | well I think I'm closing in anyway |
| 03:35:23 | raptor | excellent! |
| 03:35:29 | raptor | any questions about how anything works? |
| 03:35:46 | kaen | nope. that's what I love about the source code: I understand things the first time I read them |
| 03:35:56 | raptor | oh good |
| 03:36:00 | kaen | I'll have to show you some of the fdrpg code some day |
| 03:36:05 | kaen | you'll vomit a little I think |
| 03:36:15 | raptor | we've tried to use reallyLongAndDescriptiveVariableNames |
| 03:36:20 | sam686 | i have seen several times the getActualPos and getVert is mismatched (returns different positions) |
| 03:38:06 | sam686 | it goes with nearly all move obects as well (pressing tab in editor shows newly added move objects at (0,0)) |
| 03:43:01 | raptor | i actually looked at the freedroid rpg code when refactoring our input system to SDL... |
| 03:43:19 | raptor | i couldn't really make heads or tails of it, if i remember correctly... |
| 03:43:32 | kaen | I could tell you stories |
| 03:43:46 | raptor | so were you a regular developer on that project? |
| 03:44:05 | kaen | for about 4 months before I got tired of the devs |
| 03:44:37 | kaen | *because they were not nice |
| 03:44:56 | kaen | oh, and regular contributer |
| 03:45:01 | kaen | not a dev proper |
| 03:45:51 | kaen | for instance, the original devs misspelled 'droid' as 'Druid' (they were german) throughout the entire source code, and this was not changed until just a few months ago |
| 03:46:12 | raptor | hehe - i work with germans at work |
| 03:46:23 | kaen | whoa, nice |
| 03:46:32 | kaen | germans are cool dudes |
| 03:46:32 | raptor | no one thinks they are nice... i wonder if it is a culture clash? |
| 03:46:39 | kaen | haha |
| 03:46:49 | kaen | actually it was the frenchies that I couldn't handle |
| 03:46:54 | raptor | ha! |
| 03:47:05 | raptor | my boss is french, but she hates other french... |
| 03:47:08 | kaen | lol |
| 03:47:12 | raptor | and she is great to work with |
| 03:47:42 | kaen | that's good to know; I had almost given up on them |
| 03:47:49 | raptor | haha |
| 03:50:09 | raptor | ok, now i have to pretend i know what i'm doing and start fixing the engineered teleporter... |
| 03:54:00 | raptor | sam686: do you know why the engineering method is on ClientInfo?: ClientInfo::sEngineerDeployObject(U32 type) |
| 03:54:28 | raptor | is that the appropriate place? or should it go on gameConnection or Ship? |
| 03:59:07 | sam686 | no gameConnection, because of EngineerBot, and robots don't have GameConnection.. |
| 03:59:20 | raptor | ahh, ok |
| 03:59:32 | raptor | does ClientInfo still make sense, then? |
| 04:00:49 | sam686 | i mostly don't care whether it is on ClientInfo or Ship, I often leave it the way it is.. |
| 04:00:57 | raptor | ok |
| 04:01:06 | raptor | i'll leave it |
| 04:04:13 | sam686 | as for the forum, i removed nearly all the "Topic Moved" green ship icon, often called "shadow topic", but the topic itself is still there. |
| 04:04:27 | raptor | yay cleanup |
| 04:04:39 | raptor | curious, is off-topic still active much? |
| 04:05:21 | sam686 | the off-topic appears to be a lot more popular now, it appears.. |
| 04:06:08 | sam686 | "off-topic" topics: 403, posts: 5527, more then anyything else.. |
| 04:06:38 | sam686 | maybe more then the sum of everything else, or close to more.. |
| 04:07:06 | raptor | wow |
| 04:08:15 | sam686 | the topic count of "Off-Topic" is more then the sum of everything else, Posts coult is not quite more then sum of everything else.. |
| 04:09:23 | raptor | do you think anyone would get mad if we just deleted it all and reset the forum? :) |
| 04:10:05 | | raptor is just kidding |
| 04:10:06 | sam686 | should first gave a warning to everyone first, i think... |
| 04:16:26 | raptor | kaen: do you know much about packaging for linux distros? |
| 04:20:30 | kaen | not much, but I've built some .debs and arch packages |
| 04:21:03 | raptor | arch.. now that's a system i need learn about.. |
| 04:21:36 | kaen | it'll make you really familiar with pretty much all of your system |
| 04:22:03 | kaen | it's kind of a lot of work though |
| 04:22:11 | raptor | sounds like slackware |
| 04:22:23 | kaen | I've heard that comparison before |
| 04:22:28 | raptor | hmmm... |
| 04:22:33 | kaen | does slackware come with a DE? |
| 04:22:40 | kaen | or any gui at all? |
| 04:22:54 | raptor | yes, but they have had few releases in recent years |
| 04:23:12 | raptor | and usually side on the stable instead of bleeding edge packages |
| 04:23:13 | kaen | arch comes with only an ncurses installer. the default install boots to a command line |
| 04:23:24 | kaen | arch is all about bleeding edge software |
| 04:23:37 | raptor | ha |
| 04:23:45 | kaen | well, I mean in their packages |
| 04:23:46 | raptor | yeah, that'll teach you... |
| 04:23:58 | kaen | lol yeah |
| 04:24:11 | kaen | they have a nice wiki, so if you read along you're alright |
| 04:24:38 | kaen | and #archlinux is probably the best linux channel I've idled in |
| 04:26:10 | raptor | that's cool |
| 04:26:23 | raptor | one thing most linux distros need is a nice community... |
| 04:26:34 | kaen | definitely |
| 04:27:36 | kaen | I liked ubuntu as a learning distro for that reason, I got lots of help on the forums |
| 04:29:42 | raptor | yes, you can usually tell that someone is serious about linux when they move on from ubuntu... :) |
| 04:31:22 | kaen | agreed |
| 04:36:19 | raptor | i broke everything! |
| 04:36:22 | raptor | bah! |
| 04:37:28 | kaen | hrm, can't ctrl+alt+click virtual methods in code lite |
| 04:37:34 | kaen | I would expect a search dialog :/ |
| 04:38:06 | raptor | yeah, virtual methods aren't followed correctly in eclipse-cpp either |
| 04:38:06 | kaen | oh, ctrl + d |
| 04:38:11 | raptor | wait.. really? |
| 04:38:16 | kaen | it searches for symbol name |
| 04:38:24 | kaen | that's friggin sweet! |
| 04:47:01 | kaen | getVertCount() returns 1 for CoreItem s |
| 04:47:07 | kaen | that's unexpected, correct? |
| 04:47:17 | raptor | actually... i think that's right... |
| 04:47:20 | kaen | oh |
| 04:47:23 | kaen | :| |
| 04:47:28 | raptor | oh... i have something that may help you: |
| 04:47:56 | raptor | http://bitfighter.org/~raptor/doxygen/current/class_zap_1_1_core_item.html |
| 04:48:27 | kaen | ah, excellent |
| 04:48:28 | raptor | CoreItem is a child of PointObject, which *i think* only has one Vertex |
| 04:48:43 | raptor | makes sense... maybe... |
| 04:49:13 | kaen | now that I think about it, it makes sense |
| 04:49:42 | kaen | I was thinking about the 10-item array called 'vert' within the CoreItem, and assumed those two 'vert's meant the same thing :P |
| 04:50:03 | raptor | also, if you ever come up with better variable names or clearer in-code documention, feel free to change/add... |
| 04:50:14 | raptor | goodness knows we always could use better doc.. |
| 04:50:17 | kaen | will do |
| 04:50:28 | kaen | I'm all about documentation :) |
| 04:50:58 | raptor | oh yay |
| 05:01:47 | raptor | kaen: what DE do you use? (and do you use a graphical diff tool?) |
| 05:02:48 | kaen | kde on suse, awesomewm on arch. and I've never tried a graphical diff tool |
| 05:02:59 | kaen | I'm starting to like KDE over GNOME, which feels strange |
| 05:03:07 | raptor | haha |
| 05:03:39 | raptor | well, there's loads you can do to your ~/.hgrc file to make mercurial work better on linux (unless you are using tortoiseHG?) |
| 05:03:54 | kaen | nope, just plain old hg |
| 05:04:21 | raptor | ok good, me too... let me get you my .hgrc which has made lots easier |
| 05:04:44 | kaen | alright :) |
| 05:06:36 | raptor | here you go: http://pastie.org/4090370 |
| 05:07:08 | raptor | if you install the program kdiff3, you'll have a really powerful graphical diff tool |
| 05:07:53 | raptor | each of those extensions allow a useful utility in hg |
| 05:08:59 | raptor | here is an explanation: http://mercurial.selenic.com/wiki/UsingExtensions |
| 05:09:08 | raptor | oops: http://mercurial.selenic.com/wiki/UsingExtensions#Extensions_bundled_with_Mercurial |
| 05:10:43 | kaen | whoa thanks |
| 05:12:48 | kaen | \o/ |
| 05:12:50 | kaen | I fixed it |
| 05:12:55 | raptor | really! |
| 05:13:05 | kaen | yeah, just need an onItemDragging() method |
| 05:13:16 | kaen | to recalc the panel geometry |
| 05:13:34 | kaen | ~4 lines |
| 05:13:37 | raptor | ahh |
| 05:13:39 | raptor | cool |
| 05:13:53 | raptor | ok, so... before you commit |
| 05:14:02 | raptor | please pull recent changes... |
| 05:14:28 | kaen | you bet ;) |
| 05:14:58 | raptor | watusimoto has this habit of forking himself because he tends to pull changes after doing crazy things and then can't merge quite right |
| 05:15:07 | kaen | I don't even want to think about manual merging yet |
| 05:15:35 | kaen | I've done that too many times myself ._. |
| 05:15:57 | raptor | well, if you use that hgext.extdiff= extension |
| 05:16:02 | raptor | and install kdiff3 |
| 05:16:11 | raptor | merging is a lot nicer |
| 05:16:24 | kaen | ah, I didn't think about that |
| 05:16:31 | raptor | a little be of a learning curve, of course... |
| 05:16:34 | raptor | *bit |
| 05:18:36 | kaen | so, this method declaration and implementation, where should I put it? just append it to the bottom of the CoreItem dec/imp? |
| 05:18:48 | kaen | or is there a method to this method ordering? |
| 05:18:56 | raptor | method to the madness? |
| 05:18:58 | kaen | s/put it/put them |
| 05:19:01 | kaen | / |
| 05:19:02 | kaen | lol yeah |
| 05:19:23 | raptor | i usually look at other Item objects that implement it |
| 05:19:28 | raptor | and do the same... |
| 05:19:49 | kaen | brilliant |
| 05:20:08 | raptor | but yeah... looks like i'd just add it in a spot that looks good |
| 05:21:30 | kaen | I'll just slide it next to the other onFoo method it has |
| 05:21:53 | raptor | excellent! |
| 05:27:25 | kaen | oh whoa I messed myself up |
| 05:27:30 | kaen | I did hg pull |
| 05:27:33 | kaen | then committed |
| 05:27:39 | raptor | hg rollback! |
| 05:27:50 | kaen | need to do `hg merge` too? |
| 05:27:57 | kaen | I'm used to get merging with pull :/ |
| 05:28:10 | raptor | yeah, it's a bit different than git... |
| 05:28:18 | raptor | in hg 'pull' = git fetch |
| 05:28:21 | kaen | ah |
| 05:28:34 | kaen | then it asks me to make a merge commit, won't that show up when I push? |
| 05:29:01 | raptor | yes... you shouldn't have to merge though... |
| 05:29:04 | raptor | this is waht i do |
| 05:29:06 | raptor | wait |
| 05:29:11 | raptor | did you rollback your commit? |
| 05:29:26 | kaen | yup. sure did. |
| 05:29:26 | kaen | lol |
| 05:29:29 | raptor | ok good |
| 05:29:34 | raptor | now do: hg pull -u |
| 05:30:02 | raptor | that is equivalent to: 'hg pull' then 'hg up' |
| 05:30:03 | kaen | no changes found |
| 05:30:09 | raptor | excellent |
| 05:30:20 | raptor | now do 'hg sum' to see what rev you are at |
| 05:30:23 | raptor | (just to make sure) |
| 05:30:26 | kaen | hg diff shows all of the commits I just pulled :/ |
| 05:30:39 | kaen | 4733 |
| 05:30:42 | kaen | I think? |
| 05:30:49 | raptor | what about the hash? |
| 05:30:59 | kaen | 4733:202f9e54b9f4 |
| 05:31:08 | raptor | ah ok |
| 05:31:17 | raptor | do 'hg up tip' |
| 05:31:33 | kaen | ah, there we go |
| 05:31:44 | raptor | now what does 'hg diff' show? |
| 05:32:02 | raptor | (hopefully just your latest changes...) |
| 05:32:27 | kaen | yes |
| 05:32:33 | kaen | all seems right with the cosmos |
| 05:32:35 | raptor | ok, now commit :) |
| 05:34:15 | kaen | push'd |
| 05:34:29 | kaen | thanks for the help |
| 05:34:45 | kaen | now, if I could just stop typing `git commit -am 'message'` |
| 05:35:08 | raptor | haha |
| 05:35:21 | raptor | i think github is waaay cool |
| 05:35:29 | kaen | me too |
| 05:35:51 | kaen | I love how easily you can fork commit and make a pull request |
| 05:35:53 | raptor | problem is sam686 and watusimoto both use windows as their dev machines, and there doesn't seem to be nice git integration for windows |
| 05:36:13 | raptor | yeah, the pull request feature is great |
| 05:36:14 | kaen | that's one of the advantages of hg I hear: windows support is strong |
| 05:36:17 | kaen | (er than git) |
| 05:37:10 | kaen | have you ever tried darcs? |
| 05:37:40 | raptor | never heard of it.. |
| 05:37:53 | raptor | is that a DVCS too? |
| 05:38:01 | kaen | it's like... the plan 9 of DVCSs |
| 05:38:03 | raptor | (i've used bazaar once or twice...) |
| 05:38:07 | raptor | ha |
| 05:38:19 | kaen | the user base is fanatic about it |
| 05:38:33 | kaen | the guy who wrote it developed a 'theory of patches' |
| 05:38:37 | raptor | is plan9 still around? i think i last looked at that 5 years ago.. |
| 05:38:39 | kaen | to help automate merges |
| 05:38:56 | kaen | I know you can still get t-shirts :) |
| 05:39:03 | kaen | I dunno about development though |
| 05:39:17 | raptor | darcs uses cabal... |
| 05:39:26 | raptor | does that mean it's written in... |
| 05:39:26 | sam686 | theres hg-git that adds hg the ability to push and pull from git.. see my screenshot http://sam686.maxhushahn.com/upload/hg-git.png |
| 05:39:32 | raptor | what was that called... |
| 05:40:01 | kaen | haskell? |
| 05:40:05 | raptor | haskell! |
| 05:40:11 | kaen | would not surprise me, but I don't know |
| 05:40:29 | raptor | that one.. that's impossible to find the right dependencies for |
| 05:40:30 | kaen | yep, it is |
| 05:40:41 | | BFLogBot - Commit 1f6116529c65 | Author: kaen | Log: update CoreItem panel geometry when dragging |
| 05:40:50 | kaen | lol that just makes perfect sense to me |
| 05:41:09 | kaen | once you meet some darcs fanboys you'll get what I'm saying. |
| 05:41:16 | raptor | haha |
| 05:42:08 | kaen | but yeah, the developer is a mathematician iirc |
| 05:42:26 | raptor | neat sam686.. i guess that's one way to interface with git on windows |
| 05:42:32 | kaen | and formalized some math for merging patches |
| 05:42:34 | raptor | ah those math types |
| 05:42:44 | raptor | they love their short one letter variable names |
| 05:42:48 | kaen | lol |
| 05:42:57 | kaen | and lambda functions @_@ |
| 05:43:09 | raptor | well, not necessarily... but a lot of the 'research code' looks very cryptic |
| 05:43:17 | kaen | definitely |
| 05:43:50 | | kaen secretly really likes anonymous functions |
| 05:44:23 | raptor | ha! |
| 05:46:08 | raptor | if you want to see a crazy programming language: https://www.youtube.com/watch?v=a9xAKttWgP4 |
| 05:46:56 | raptor | APL needs its own keyboard to use it... |
| 05:47:08 | kaen | lol I was just gonna say |
| 05:47:16 | kaen | I don't even know how to type a phi character |
| 05:47:36 | raptor | this is the keyboard: https://en.wikipedia.org/wiki/File:APL-keybd2.svg |
| 05:48:01 | kaen | whoa that's pretty cool |
| 05:48:08 | kaen | I like how it uses set theory and stuff |
| 05:48:36 | kaen | I see some FOPC stuff too |
| 05:49:16 | sam686 | that "crazy programming language" video looks more like a scientific calculater and not much of a program.. |
| 05:49:30 | raptor | it does the game in one line of code.. |
| 05:50:04 | kaen | D: |
| 05:50:10 | kaen | I just skipped to that part |
| 05:50:19 | kaen | that's incredible |
| 05:50:31 | kaen | wow I wish I had audio :< |
| 05:50:56 | sam686 | oh sure... lets turn bitfighter source code, combine all .cpp and .h file into 1, and cram into one single line of code, even if that line would have a million characters... good luck on readability.. |
| 05:51:06 | raptor | haha |
| 05:51:29 | kaen | express as a series of bitwise operations |
| 05:51:32 | kaen | it'll be cool |
| 05:53:02 | raptor | well good job kaen. i scratched that bug off |
| 05:53:06 | kaen | in all sincerity though, that's easily the coolest life port I've seen |
| 05:53:10 | kaen | oh, thanks :) |
| 05:55:54 | raptor | well, if you're still up for something, there #11 here: http://bitfighter.org/wiki/index.php/Running_Bug_List |
| 05:56:17 | raptor | (and if you still like Bitfighter after that last bug...) |
| 05:56:20 | raptor | :) |
| 06:09:45 | raptor | one of these years we'll be able to move to the c++11 standard and be able to forward declare enums! |
| 06:13:37 | sam686 | only problem with c++11 i heard is trying to get it to support poor old mac OS that uses PPC (can't do software mac upgrades) |
| 06:13:50 | raptor | oh yeah... |
| 06:13:51 | raptor | hmm |
| 06:13:57 | raptor | forgot about that.. |
| 06:14:33 | sam686 | it might be possible for old mac os ppc to switch to linux, but i don't know about hardware compatibility... |
| 06:14:50 | raptor | they can, i've done it |
| 06:15:05 | raptor | most people keep old macs around for their kids to play old games |
| 06:15:19 | kaen | aren't there distros with ppc builds? |
| 06:15:49 | raptor | yes... I installed SLES on ppc once |
| 06:16:27 | raptor | but bootloader stuff is really, really weird |
| 06:16:39 | sam686 | some linux distros can work with many different CPU, like debian, while other distros only made work on one or two CPU types.. |
| 06:29:22 | raptor | ok falling asleep |
| 06:29:27 | raptor | good night! |
| 06:29:33 | kaen | same |
| 06:29:34 | sam686 | night |
| 06:29:34 | kaen | g'night |
| 06:29:43 | sam686 | good night too, going to bed too |
| 06:29:57 | | sam686 has left |
| 06:40:04 | | raptor Quit () |
| 06:40:49 | | BFLogBot - Commit f298e91b5d69 | Author: buckyballreaction | Log: Some engineer clean-up. Also differentiate between teleport entrance and exit objects |
| 06:40:51 | | BFLogBot - Commit 492a1f258df2 | Author: buckyballreaction | Log: Use deployer mDeployPosition for teleport, too |
| 06:40:52 | | BFLogBot - Commit bd9b24424756 | Author: buckyballreaction | Log: Set Lua enum for engineered teleport entrance/exits |
| 06:40:54 | | BFLogBot - Commit c615e52a7ef7 | Author: buckyballreaction | Log: Allow endpoint of teleport to be changed |
| 06:58:36 | | koda has joined |
| 07:23:19 | | koda Quit (Quit: koda) |
| 07:27:29 | | zoomber_mbp has joined |
| 07:31:55 | zoomber_mbp | hi |
| 07:31:57 | | zoomber_mbp has left |
| 07:37:31 | | watusimoto has joined |
| 07:37:31 | | ChanServ sets mode +o watusimoto |
| 07:44:17 | | watusimoto Quit (Remote host closed the connection) |
| 07:51:57 | | LordDVG has joined |
| 07:53:19 | | zoomber_mbp has joined |
| 07:58:39 | | zoomber_mbp_ has joined |
| 08:00:42 | | zoomber_mbp_ Quit (Remote host closed the connection) |
| 08:00:56 | | zoomber_mbp_ has joined |
| 08:01:22 | | zoomber_mbp Quit (Ping timeout: 246 seconds) |
| 08:01:22 | | zoomber_mbp_ is now known as zoomber_mbp |
| 08:01:28 | | zoomber_mbp Quit (Remote host closed the connection) |
| 10:12:02 | | Watusimoto has joined |
| 10:22:12 | | LordDVG Quit (Remote host closed the connection) |
| 11:22:46 | | Watusimoto Quit (Ping timeout: 244 seconds) |
| 12:41:02 | | kodaws has joined |
| 12:53:09 | | -mrmist- [Global Notice] - Our services upgrade is scheduled for 2PM UTC on Saturday. We expect services to be unavailable for up to an hour, so please plan your channel management accordingly. Thanks for flying freenode! |
| 14:28:27 | | Watusimoto has joined |
| 14:31:45 | kaen | morning |
| 15:19:37 | | Watusimoto_ has joined |
| 15:20:38 | | Watusimoto Quit (Ping timeout: 240 seconds) |
| 15:26:02 | | raptor has joined |
| 15:26:03 | | ChanServ sets mode +o raptor |
| 15:26:11 | raptor | good morning |
| 15:26:22 | kaen | morning |
| 15:26:44 | kaen | I pushed another commit; the cores were still bugging if you loaded a level with one placed |
| 15:26:56 | raptor | oh really? |
| 15:27:05 | kaen | I set the mPanelGeom.isValid to false in the constructor for CoreItem |
| 15:27:07 | kaen | yea |
| 15:27:33 | raptor | how can i dupe? |
| 15:27:56 | kaen | place a core on a level -> save -> quit -> load level in editor -> ta |
| 15:27:58 | kaen | *tab |
| 15:30:59 | raptor | well... i don't see the bug for some reason, but i'll pull anyways |
| 15:31:22 | raptor | did you quit the game completely or just the editor? |
| 15:31:32 | kaen | worked either way for me |
| 15:32:38 | | watusimoto has joined |
| 15:32:38 | | ChanServ sets mode +o watusimoto |
| 15:33:00 | raptor | ok, pull/pushed :) |
| 15:33:02 | raptor | thanks! |
| 15:33:10 | kaen | no sweat |
| 15:33:34 | raptor | are you on openSUSE 12.1 x86_64? |
| 15:33:47 | kaen | yep |
| 15:34:21 | raptor | watusimoto: LazyDaisy sounds great! |
| 15:37:22 | | BFLogBot - Commit f1eefc40dce2 | Author: kaen | Log: set CoreItem panel geometry as invalid when constructed |
| 15:45:47 | | Watusimoto_ Quit (Ping timeout: 252 seconds) |
| 15:50:01 | watusimoto | For a while I toyed with having a random assortment of slightly insulting default names, but now that we do stats tracking, it might make things more confusing. On the other hand, it would be nearly trivial to implement. |
| 15:50:56 | watusimoto | Not nearly trivial... trivial. |
| 15:51:15 | raptor | did you put in a list of bot names somewhere, too... |
| 15:51:53 | watusimoto | I did... drawn from the most popular girls names of 2011 |
| 15:52:06 | raptor | oh yeah, including their hideous spellings... |
| 15:52:17 | watusimoto | Especially the hideous spellings |
| 15:52:22 | kaen | lol |
| 15:53:11 | raptor | coding question: where should I store a pointer to the current teleport being created? on the Ship? ClientInfo? |
| 15:55:39 | raptor | hmm... probably Ship |
| 16:05:48 | watusimoto | probably ship |
| 16:05:56 | watusimoto | pooooosibly client info |
| 16:06:06 | watusimoto | but probably ship |
| 16:06:11 | watusimoto | seems kind of a shippy thing |
| 16:10:43 | raptor | should we allow teleport exits on barriers? |
| 16:14:58 | watusimoto | mmmmm no? |
| 16:15:16 | raptor | i'm thinking no |
| 16:15:24 | watusimoto | ok, then no |
| 16:48:49 | raptor | i know i'm going to get bitten by pointers somehow, somewhere... |
| 16:51:08 | | watusimoto Quit (Ping timeout: 245 seconds) |
| 16:54:01 | | kodaws Quit (Read error: Connection reset by peer) |
| 17:17:56 | | BFLogBot - Commit d35b55f084d9 | Author: buckyballreaction | Log: Teleport exits can now be 'constructed'. Has testing code: exit placement is possible from the engineer helper menu |
| 17:50:50 | | Watusimoto has joined |
| 18:16:17 | raptor | Watusimoto: do we have a method somewhere to fill a Vector of points for a polygon? |
| 18:16:55 | Watusimoto | I'm not sure I understand |
| 18:17:32 | raptor | like specify # of sides and radius, and it returns a vector<point> of the polygon outline |
| 18:17:47 | raptor | i was sure we had that somewhere... |
| 18:17:52 | Watusimoto | we do have some sort of polygon generation function |
| 18:17:57 | Watusimoto | it's how testitems aer made |
| 18:18:06 | raptor | the drawPolygon method |
| 18:18:12 | raptor | butit doesn't return a Vector<Point> |
| 18:18:15 | Watusimoto | look at rendergameobjec::rendertestitem |
| 18:18:19 | Watusimoto | what does it return? |
| 18:18:25 | Watusimoto | or it just draws? |
| 18:18:28 | raptor | yes |
| 18:19:01 | Watusimoto | then we might not; you could refactor that method, and put a point generation method in GeomUtils.cpp |
| 18:20:27 | Watusimoto | that's where I'd expect it to live if we had it, and I don;t see it there. so we probably don't have one |
| 18:20:29 | Watusimoto | though |
| 18:20:44 | raptor | looking through clipperLib... |
| 18:20:47 | Watusimoto | another place we might use one if we had it was in generating the panel geometry for cores |
| 18:21:02 | Watusimoto | I don;t think clipperLib will be helpful... |
| 18:22:16 | Watusimoto | looing in renderPolygon to see how that works |
| 18:22:42 | kaen | fillpanelgeom operates on a panel geom, which has arrays of points afaict |
| 18:24:10 | Watusimoto | don't think we have it |
| 18:24:23 | raptor | ok, i'll write it, then and stick in in GeomUtils... |
| 18:24:36 | raptor | grammar fail x2 |
| 18:27:30 | raptor | this sig look OK?: void createPolygon(const Point ¢er, S32 sideCount, Vector<Point> &outputPoly); |
| 18:27:37 | raptor | oops, forgot radius |
| 18:32:09 | raptor | void createPolygon(const Point ¢er, U32 sideCount, F32 radius, Vector<Point> &outputPoly) |
| 18:48:20 | Watusimoto | sure; I prefer radius to come before sides, but that's just me; it's completely arbitrary |
| 18:48:31 | raptor | easy enough |
| 18:48:49 | Watusimoto | the only other thing to consider is if it be Vecotr<point> createPolygon(...) |
| 18:49:06 | Watusimoto | I think performance is (roughly) equivalent, and that might be easier to understand |
| 18:49:12 | Watusimoto | but I waver on this point |
| 18:49:20 | raptor | it doesn't matter: compiler optimizations will make the way i put it anyways... |
| 18:49:23 | Watusimoto | yes |
| 18:49:28 | raptor | but the code may be easier to read your way |
| 18:50:51 | Watusimoto | as you wish; I am guilty of inconsistency on this point |
| 18:50:56 | raptor | me too |
| 18:51:02 | raptor | what is easier to read in the code? |
| 18:51:14 | raptor | or looks nicer |
| 18:51:36 | raptor | because those nice compiler folks have us covered well enough, me thinks |
| 19:21:24 | Watusimoto | I think the traiditonal retValue = callFunct(p1, p2) is easier than callFunct(p1,p2, retValue) |
| 19:21:35 | Watusimoto | that's the traditional form, after all |
| 19:21:53 | Watusimoto | did I mention that it's traditional? |
| 19:21:59 | raptor | heh |
| 19:23:55 | kaen | I concur, but what about when you already have a retValue handy? |
| 19:24:31 | raptor | retValue1 = callFunct(retValue2, retValue3,...) |
| 19:24:47 | raptor | ok not really |
| 19:24:59 | kaen | there's a free() in there somewhere I'd imagine |
| 19:25:23 | kaen | if you'd potentially pass it by reference in the alternative form |
| 19:25:57 | kaen | perhaps optional third param which creates one if null? idk if that makes code more readable though :/ |
| 19:26:05 | kaen | programming is hard ._. |
| 19:26:36 | raptor | yeah, we should just use APL |
| 19:26:48 | kaen | I like it |
| 19:30:57 | kaen | hey, my server shows up as Ping Timed Out in the server list, but connecting works fine. I've checked my iptables and I'm not filtering ICMP nor UDP |
| 19:31:34 | raptor | in 017b or 018? |
| 19:31:50 | kaen | 017b |
| 19:32:03 | raptor | probably a router somewhere... |
| 19:32:28 | kaen | gah |
| 19:32:34 | kaen | I hate EC2 |
| 19:32:57 | raptor | there's a utility called tnlping in the source code somewhere that let's you tell if UDP is blocked |
| 19:33:32 | kaen | is the game proto over tcp? |
| 19:33:59 | raptor | no |
| 19:34:02 | raptor | UDP |
| 19:34:38 | kaen | well, I just finally arsed myself to actually ping it, and they're being filtered |
| 19:34:47 | kaen | but sam and I were playing on it last night |
| 19:35:01 | raptor | i see it! |
| 19:41:17 | kaen | -.- |
| 19:41:28 | kaen | amazon has it's own firewall in the management console too |
| 19:41:34 | kaen | its* |
| 19:57:34 | Watusimoto | I think it's good pracitce to adapt your fn sigs to match what you have and what you need :-) |
| 19:57:45 | Watusimoto | there is no one right anwer that always works |
| 19:58:00 | raptor | yes, unless you are writing for the c++ stl |
| 19:58:13 | raptor | then make sure they're as complex as possible |
| 19:58:42 | raptor | /sarcasm |
| 19:58:52 | raptor | [Error] sarcasm: Unknown command. |
| 19:59:11 | kaen | lol |
| 20:00:14 | kaen | I just built a local doxygen |
| 20:00:16 | | Watusimoto Quit (Remote host closed the connection) |
| 20:00:16 | kaen | so cash |
| 20:00:56 | | Watusimoto has joined |
| 20:00:58 | Watusimoto | does c++0x have multiple return values for functions? |
| 20:01:08 | raptor | i have no idea |
| 20:01:22 | Watusimoto | well, I can say with some level of certainty that it might |
| 20:01:32 | Watusimoto | and with almost equal certitude that I don't care enough to check |
| 20:01:36 | raptor | hahaha |
| 20:02:07 | Watusimoto | ok, I checked. C++0x might have mutliple return values |
| 20:08:34 | raptor | this teleport thing has prompted lots of engineer clean-up... |
| 20:08:46 | | BFLogBot - Commit 81c95b44f7df | Author: buckyballreaction | Log: Add createPolygon() method |
| 20:08:48 | | BFLogBot - Commit e3eb823c83fc | Author: buckyballreaction | Log: Teleport exits now cannot be placed on walls |
| 20:08:49 | | BFLogBot - Commit 49f14105af52 | Author: buckyballreaction | Log: Render outline for teleport entrances/exits based on whether it can be deployed |
| 20:17:00 | raptor | ok ok... i think i'm about ready to start the protocol response logic with placing the teleport... now.. where to begin |
| 20:29:51 | | sam686 has joined |
| 20:29:51 | | ChanServ sets mode +v sam686 |
| 20:33:07 | raptor | Watusimoto: do you know what |
| 20:33:10 | raptor | oops |
| 20:33:20 | raptor | uh, ignore that |
| 20:33:51 | | koda has joined |
| 20:55:34 | Watusimoto | just finished watching england v sweden |
| 20:55:41 | Watusimoto | two very attack oriented teams |
| 20:55:52 | Watusimoto | two fantastic goals |
| 20:56:54 | raptor | how long is a typical football game, including all the breaks, etc..? |
| 20:57:25 | Watusimoto | 45 * 2 + 10 |
| 20:57:41 | Watusimoto | plus 5 mins or so "stoppage time" |
| 20:57:47 | raptor | ah ok |
| 20:57:55 | raptor | the 10 is half-time? |
| 20:58:00 | Watusimoto | that the ref adds at the end to compensate for time spent tending the injured |
| 20:58:19 | Watusimoto | or, for the Italian team, the time spend tending the pretending-to-be injured :-) |
| 20:58:25 | raptor | haha |
| 20:58:29 | Watusimoto | 10ish is half time |
| 20:59:18 | Watusimoto | and no breaks for ads! |
| 20:59:31 | raptor | hooray! |
| 21:00:03 | Watusimoto | actual footage from one of the training camps |
| 21:00:04 | Watusimoto | http://www.youtube.com/watch?v=2b0GNwuNMDc |
| 21:01:14 | raptor | hahaha |
| 21:01:20 | raptor | seriously? |
| 21:01:48 | raptor | that can't be serious... |
| 21:02:49 | Watusimoto | it's why I prefer rugby |
| 21:03:10 | raptor | we always have people playing rugby in the parks around where i live |
| 21:03:15 | Watusimoto | there if a player is injured, they bring out the medics and keep playing around the doctors |
| 21:03:18 | raptor | mostly samoans and tongans |
| 21:03:32 | Watusimoto | too bad they never win |
| 21:04:29 | raptor | i read an interesting article the other day on why rugby is probably less dangerous than american football... because of the false sense of security of having a helmet |
| 21:04:36 | raptor | with respect to concussions |
| 21:05:22 | Watusimoto | rugby is highly dangerous, but I think you are right about that |
| 21:05:46 | raptor | yeah... i meant only about the concussions part |
| 21:06:17 | Watusimoto | http://www.youtube.com/watch?v=uvhNvbsi53Y |
| 21:06:26 | Watusimoto | just as a poiint of comparison |
| 21:08:38 | raptor | ouch! |
| 21:09:43 | raptor | i bet bruises are gnarly... and ubiquitous |
| 21:19:11 | kaen | hmm. I keep getting odd behavior because make is using stale object files :/ |
| 21:19:53 | kaen | have to make clean a whole bunch |
| 21:20:19 | raptor | any time you do a header change |
| 21:20:37 | raptor | you'll need to do a clean or 'make -B' |
| 21:20:44 | kaen | ah, I see |
| 21:20:47 | raptor | 'make -B debug' |
| 21:21:11 | raptor | is equivalent to 'make clean && make debug' |
| 21:21:51 | raptor | are you using parallel build? my computer has 4 cores, so i do: 'make -B -j4 debug' |
| 21:22:01 | kaen | I use j2, but yeah |
| 21:22:12 | raptor | oh good |
| 21:23:23 | kaen | I also use -s so I can see warnings easier |
| 21:23:53 | raptor | oh neat... haven't used that one before |
| 21:24:26 | kaen | not as useful with an IDe |
| 21:24:28 | kaen | IDE even |
| 21:25:41 | kaen | yea, I found my culprit for that firing bug |
| 21:26:02 | kaen | just need to cogitate on how to resolve it now :/ |
| 21:26:20 | raptor | oh.. |
| 21:26:38 | raptor | i bet it's a large if-else block in Ship.cpp? |
| 21:26:46 | kaen | indeed :) |
| 21:26:55 | kaen | in particular, the assignment of isIdle |
| 21:27:21 | kaen | in even more particular, && !mCurrentMove.fire |
| 21:27:58 | kaen | need some more nuanced logic |
| 21:28:06 | kaen | or maybe to reset that flag after a shot is fired? |
| 21:28:21 | raptor | what line are you looking at exactly? |
| 21:28:31 | kaen | not sure how that will affect repeating weapons :/ |
| 21:28:33 | kaen | 947 |
| 21:29:11 | raptor | oh ugh |
| 21:29:40 | raptor | yeah, that's subtle: the difference between holding down the mouse and actually firing |
| 21:29:50 | kaen | yeah |
| 21:29:58 | kaen | what are your thoughts on resetting the flag? |
| 21:30:06 | raptor | actually... i think i wrote something to that effect... |
| 21:30:06 | kaen | or should I just experiment for a while? |
| 21:30:10 | kaen | oh |
| 21:30:22 | kaen | :l |
| 21:30:29 | raptor | i think resetting the flag may render the flag useless in a lot of logic... |
| 21:30:38 | kaen | that's what I feared ._. |
| 21:31:25 | kaen | well, I'm going to run some errands while think on it |
| 21:31:36 | raptor | ok, laters |
| 21:33:32 | raptor | actually... we may want to reconsider this if it even a bug... |
| 21:33:45 | raptor | Watusimoto: what do you think about #11 on http://bitfighter.org/wiki/index.php/Running_Bug_List ? |
| 21:34:46 | Watusimoto | let me look |
| 21:34:48 | Watusimoto | !bug |
| 21:34:48 | 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 running bug list: http://bitfighter.org/wiki/index.php/Running_Bug_List |
| 21:35:18 | Watusimoto | hm |
| 21:35:31 | Watusimoto | the question obviously is what should happen |
| 21:35:53 | Watusimoto | certainly for mines the rate between laying should be the same whether button down or not |
| 21:35:54 | raptor | yes... i'm leaning towards: not bug |
| 21:36:17 | Watusimoto | for constant fire, though, I think you should get moving recharge rate |
| 21:36:32 | Watusimoto | so I would say we should fix for mines only |
| 21:36:48 | Watusimoto | otoh, compare the two situations |
| 21:36:52 | raptor | hackety hack hack |
| 21:37:00 | Watusimoto | firing and not moving vs. firing and moving |
| 21:37:13 | sam686 | the problem becomes more obvious when on your loadout to recharge even faster (only when not moving, not firing) |
| 21:37:14 | raptor | we could provide a boolean isConstantFiring |
| 21:37:22 | Watusimoto | what happens with modules? |
| 21:37:36 | Watusimoto | if I repair and don't move, do I get high or low recharge rate? |
| 21:37:45 | raptor | normal |
| 21:37:52 | raptor | sorry |
| 21:37:54 | raptor | none |
| 21:38:04 | raptor | wait |
| 21:38:05 | sam686 | repair eats energy, no recharge |
| 21:38:10 | raptor | ^^ yes that |
| 21:38:15 | raptor | no wait |
| 21:38:22 | Watusimoto | replaced one ambiguous answer with another! |
| 21:38:28 | Watusimoto | and then another! |
| 21:38:44 | Watusimoto | sitting still you get recharge A |
| 21:38:49 | Watusimoto | moving you get recharge B |
| 21:38:53 | Watusimoto | A > B |
| 21:38:53 | sam686 | but, out of energy, recharge rate while still holding down repair button? |
| 21:38:59 | raptor | ok |
| 21:39:05 | raptor | energy is given back first |
| 21:39:09 | raptor | before modules take it away |
| 21:39:15 | raptor | so normal rate if idle |
| 21:39:48 | Watusimoto | normal rate is A? |
| 21:40:23 | raptor | bah! |
| 21:40:27 | raptor | ok finished reading now |
| 21:40:33 | sam686 | looks like, ship energy recharges quickly if nothing to repair (and holding down repair button) like if not moving |
| 21:40:43 | raptor | i have energy A |
| 21:40:54 | Watusimoto | I looked at that code today -- if nothing in repair range, repair disables itself |
| 21:41:12 | raptor | I repair, lose energy B; but idle, gain energy C at normal rate... all in the same method |
| 21:41:16 | Watusimoto | repair consumes no energy when no targets |
| 21:41:46 | raptor | so energy loss/gain = -B + C |
| 21:42:03 | Watusimoto | when you move, you get less than "normal" rate, right? |
| 21:42:06 | raptor | right |
| 21:42:11 | raptor | idle = move || shooting |
| 21:42:18 | raptor | == |
| 21:42:21 | Watusimoto | so you can be idel and use modules |
| 21:42:25 | raptor | yes |
| 21:42:39 | Watusimoto | then we could say you can be idle and shoot |
| 21:42:48 | sam686 | pretty much same with all modules, it disables itself with not enough energy, recharging faster if idling (doesn't matter if holding down module button when module does nothing when no energy left) |
| 21:42:56 | Watusimoto | it is the act of flying that causes your energy recharge to lessen |
| 21:43:09 | Watusimoto | firing should take the same energy whether moving or stationary |
| 21:43:21 | Watusimoto | (just laying out logical principles) |
| 21:43:35 | Watusimoto | modules should take same energy when moving or stationary |
| 21:43:59 | Watusimoto | if we agree on those, then shooting should not make you idle |
| 21:44:00 | raptor | so solution is to change: bool isIdle = mCurrentMove.x == 0 && mCurrentMove.y == 0 && !mCurrentMove.fire; |
| 21:44:00 | sam686 | mines is a bit different, it is a weapon... |
| 21:44:05 | raptor | to: bool isIdle = mCurrentMove.x == 0 && mCurrentMove.y == 0 |
| 21:44:08 | raptor | ; |
| 21:44:20 | Watusimoto | that's one solution |
| 21:44:22 | Watusimoto | except |
| 21:44:50 | Watusimoto | I think we wanted to avoid the situation where you camped out in a loadout zone and could shoot (or shield) indefinitely |
| 21:45:18 | sam686 | if you recharge faster firing bouncer, then might not run out of energy at all... |
| 21:45:19 | raptor | wait i lied again |
| 21:45:24 | Watusimoto | originally, I proposed making modules cost more in loadout zones (if you got +10% recharge rate in loadouts, modules should cost 10% more) |
| 21:45:34 | raptor | comment here: |
| 21:45:35 | raptor | // Energy will recharge with special rules |
| 21:45:37 | raptor | // It will not recharge if you have an activated module or spawn shield is up |
| 21:45:38 | raptor | if(!anyActive && mSpawnShield.getCurrent() == 0) |
| 21:46:03 | raptor | so we don't have to handle the module case |
| 21:46:11 | Watusimoto | ok -- let's not worry about what does happen, but agree on what should happen |
| 21:46:26 | kaen | there we go. |
| 21:46:30 | Watusimoto | then we can match that against what does happen and make any changes needed |
| 21:46:44 | raptor | what should happen: firing gives normal recharge except in zone? |
| 21:47:21 | sam686 | same goes with burst, if you keep firing burst, you don't recharge faster, but at the same firing rate, repeatedly pressing fire button on burst gave you more energy when not moving.. |
| 21:47:23 | Watusimoto | I seem to recall proposing my more expensive modules |
| 21:47:33 | Watusimoto | and then proposing more expensive firing to go along with it |
| 21:48:00 | raptor | so modules already don't get a recharge when used |
| 21:48:01 | Watusimoto | and I think that, for whatever reason, we decided that implementing more expensive firing was undesireable |
| 21:48:25 | Watusimoto | so you only recharge when not using modules? |
| 21:48:39 | raptor | yes |
| 21:48:48 | raptor | i have led you all astray on the same topic 4 times now |
| 21:49:15 | Watusimoto | the code might be clearer if we upped the energy cost of modules and you always got recharge |
| 21:49:28 | Watusimoto | such that there was no change in outcome |
| 21:49:35 | Watusimoto | but we could have fewer special cases |
| 21:49:54 | Watusimoto | your misleadings suggest the code is not as clear as it could be :-) |
| 21:49:57 | sam686 | cloak + sensor at the same time don't hardly take any more energy as only cloak or only sensor.. |
| 21:50:17 | Watusimoto | really? They are not simply additive? |
| 21:50:39 | Watusimoto | I'm looking for the code |
| 21:50:41 | kaen | they should be, by the code |
| 21:50:44 | Watusimoto | this is crazy |
| 21:50:44 | raptor | they are additive |
| 21:50:51 | sam686 | it seems to look that way, looking at the difference of recharge rate vs use rate (zero recharge using modules) |
| 21:51:09 | raptor | just tested, goes away faster. i think sam686 is just making a comparison of how little they both still use when added together |
| 21:51:19 | kaen | ah |
| 21:51:51 | sam686 | if recharge rage still get added in addition to using modules, then it won't look so strange about using 1 or both modules rates.. |
| 21:52:26 | Watusimoto | interesting |
| 21:52:50 | Watusimoto | if recharge rate is R, sheeld cost is S, cloak cost is C and energy is E |
| 21:52:58 | Watusimoto | no modules E += R |
| 21:53:07 | Watusimoto | with cloak and shiedl |
| 21:53:07 | raptor | yes |
| 21:53:14 | Watusimoto | E -= S + C |
| 21:53:18 | raptor | correct |
| 21:53:47 | Watusimoto | if we changed the costs as I usggested, so that Snew = S + R and Cnew = C + R |
| 21:53:54 | Watusimoto | then when using both |
| 21:53:59 | sam686 | say the very first Armor module had a bug that stops from recharging energy when using Armor, it still cost you from not recharging Energy.. |
| 21:54:09 | Watusimoto | E -= S+R + C+R |
| 21:54:10 | raptor | yes, then we have to do all sorts of math to compensate |
| 21:54:28 | Watusimoto | so we currently give a tacit bonus to using modules in combination |
| 21:54:36 | Watusimoto | which is fine, just never realized it before |
| 21:54:46 | raptor | no: E += -(S +C) + R |
| 21:55:07 | raptor | no energy bonus in combination |
| 21:55:28 | Watusimoto | before my suggestion E -= S + C |
| 21:55:44 | sam686 | right now, it looks like E += ((S + C) != 0) ? -(S - C) : R |
| 21:55:47 | Watusimoto | after my suggestion E -= (S+R) + (C+R) - R |
| 21:56:11 | Watusimoto | which simplifies to E -= S + C+ R |
| 21:56:24 | raptor | which is bad |
| 21:56:39 | Watusimoto | which I would argue is somehow "right" but different (and I'm not proposing we switch) |
| 21:56:40 | raptor | +R when used with -= means a further penalty |
| 21:56:45 | Watusimoto | yes |
| 21:56:51 | kaen | he means to knock out the recharge rate |
| 21:56:58 | kaen | and the code for disabling it when firing modules |
| 21:56:58 | raptor | ahhh |
| 21:57:03 | kaen | right? |
| 21:57:07 | raptor | my premise was wrong |
| 21:57:14 | Watusimoto | yes, but the math doesn;t work as I had initially thought |
| 21:57:39 | Watusimoto | I thought my proposal would be neutral, but it would in fact make multiple modules more expensive (and, perhaps, more realistic) |
| 21:57:46 | raptor | how about we just test if in a zone, then add the penalty of firing being idle, too |
| 21:58:24 | Watusimoto | what do you mean 'finring beiun g idle' |
| 21:58:28 | Watusimoto | my typing is crap! |
| 21:59:02 | raptor | as in: we change isIdle to be true only if not moving; except if in a zone it is not moving + not firing |
| 21:59:41 | Watusimoto | that leaves the original problem: hold down mine placing key and recharge slower |
| 21:59:41 | raptor | brb... |
| 21:59:57 | raptor | in about 20min., actually.. |
| 22:00:03 | Watusimoto | ok |
| 22:00:10 | kaen | for that particular problem, I'd agree with raptors earlier suggestion |
| 22:00:23 | sam686 | another problem, about hostile loadout zone taking away energy? using cloak actually slows down your energy usage.. |
| 22:00:25 | kaen | a flag that says whether the item suppresses recharging or not |
| 22:00:41 | kaen | sam686, :o |
| 22:01:10 | kaen | but I agree that the whole function needs some love |
| 22:01:35 | Watusimoto | >>>>> I'd agree with raptors earlier suggestion <<<<< which one? he made lots of suggestions earlier :-) |
| 22:02:14 | Watusimoto | we need to go back to first principles |
| 22:02:17 | Watusimoto | I think |
| 22:03:06 | Watusimoto | I think my head is going to explode |
| 22:03:32 | sam686 | energy usage confusion or conplications? |
| 22:03:42 | Watusimoto | everything |
| 22:04:15 | Watusimoto | 1) You get a basic energy recharge rate |
| 22:04:29 | Watusimoto | 2) That rate increases when you are stationary |
| 22:04:46 | Watusimoto | 3) That rate incureases if you are in a friendly loadout zone |
| 22:04:56 | Watusimoto | 4) that rate decreases when you are in a hostile loadout zone |
| 22:05:05 | Watusimoto | all of these increases and decreasess are additive |
| 22:05:22 | Watusimoto | (sorry, that was point 5) |
| 22:05:49 | Watusimoto | 6) Modules cost energy |
| 22:06:09 | Watusimoto | 7) Using 2 moduels costs the cumulative energy of each individually |
| 22:06:26 | sam686 | the non-adding recharge rate while using modules (especially cloak on hostile zone) tends to be confusing.. making recharge rate always additive may fix some confusion.. |
| 22:06:36 | Watusimoto | 8) shooting costs energy |
| 22:06:50 | Watusimoto | 9) laying mines is not the same as shooting continuously |
| 22:07:22 | Watusimoto | (i.e. even if you hold the fire button, it;s more a series of discrete events, unlike finring a stream of bullets) |
| 22:07:30 | kaen | yes. |
| 22:07:53 | Watusimoto | sam -- you are right it would make it ieasier, but it would lead to making combinations of modules more expensive than they are now |
| 22:08:35 | Watusimoto | I think combinations of modules are kind of cool, so I like some sort of incentive for using htem |
| 22:09:19 | sam686 | currently, cloak on hostile loadout take less energy away then no modules on hostile loadout.. |
| 22:09:44 | Watusimoto | Maybe we coudl always add the recharge energy and then explicitly give a bonus for using 2 modules to compensate and make the dual rate the same as it is now |
| 22:10:07 | Watusimoto | 10) it should never cost less energy to use a module than to not use it |
| 22:10:38 | kaen | that logic is easy to follow, in case you were wondering :) |
| 22:10:44 | kaen | I like it. |
| 22:11:02 | Watusimoto | 11) Energy should be logical, but not necessarily strictly reaslistic (energy can incentivize or disincentivize certain behaviors) |
| 22:12:00 | Watusimoto | if we change point 7, we might be able to clean things up without changing current cost of using cloak + shield |
| 22:13:11 | Watusimoto | we could say each module needs to warm up some capacitors, which costs energy, but if using 2 modules, those capacitors are already warm, so use less in total than each individually |
| 22:13:31 | Watusimoto | if we needed to justify violating 7, that is |
| 22:13:52 | Watusimoto | which we don't, according to point 11 |
| 22:14:48 | kaen | :) |
| 22:15:16 | Watusimoto | the thing we don't want to do is to create a situation where someone can shield or cloak indefinitely by camping out on a loadout zone or whatnot |
| 22:15:24 | Watusimoto | so we could add point 12 |
| 22:15:28 | kaen | point 11 is very powerful; it relays the message that energy is ultimately a game mechanic while acknowledging it should be intuitive |
| 22:16:09 | Watusimoto | 12) Modules in loadout zones cost proprotionately more than they do outside loadout zones, in such a way that the effective cost is always the same |
| 22:16:33 | Watusimoto | so if shields consume 10% of your energy every second |
| 22:16:43 | Watusimoto | that rate shoudl continue in or out of a loadout zone |
| 22:17:12 | Watusimoto | though that might violate 10) in a hostile zone |
| 22:26:22 | Watusimoto | maybe we need |
| 22:27:01 | Watusimoto | 13) Modules in hostile zones cost the same as in their normal rate; that is, their energy consumption may be increaed in friendly zones, but never discounted |
| 22:27:59 | raptor | too much to read! |
| 22:28:05 | Watusimoto | ha |
| 22:28:31 | Watusimoto | you can skip point 7 |
| 22:29:32 | kaen | that bug sounded so innocuous at first lol |
| 22:29:36 | raptor | we need a 5-dimensional karnaugh map |
| 22:29:47 | raptor | and we can minimize to point of never understanding it again! |
| 22:31:10 | Watusimoto | I tried to pull some code out of ship::idle() and it was the energy stuff that made it very difficult |
| 22:31:13 | raptor | ok done reading |
| 22:32:03 | Watusimoto | I think we can take these points (eliminating #7) and simplify the code while retaining basic current functinality, and fixing some bugs and inconsistencies at the same time |
| 22:32:56 | raptor | what if we just looked at every dimension as a boolean add put an additive or subtractive energy amount per boolean, then run through each boolean |
| 22:33:08 | Watusimoto | 14) REPLACES #7 >>> Using modules in combination is cool, so there is a energy bonus awarded for doing so that makes a combo cheaper than the cumulative cost of each alone |
| 22:33:14 | raptor | instead of having some depend on others like we do now |
| 22:33:33 | kaen | yes |
| 22:33:37 | kaen | 100% yes, raptor |
| 22:33:42 | kaen | imho |
| 22:33:53 | Watusimoto | I'd be 100% yes if I understood what you were saying! |
| 22:34:03 | kaen | that's what appealed to me about this formalization of the logic |
| 22:34:22 | kaen | a cascade of if { } rather than nested if {} else {} |
| 22:35:31 | kaen | unless I'm misunderstanding, as well |
| 22:36:17 | raptor | so we just do a bunch of boolean tests and add/subtract relative energy amounts: if(inFriendlyZone) add 3000; if(moving) remove 1000; if (firing) add 0 |
| 22:36:23 | Watusimoto | yes |
| 22:36:25 | Watusimoto | ok, yes |
| 22:36:33 | raptor | actually, maybe they should be multipliers? |
| 22:36:43 | kaen | @_@ |
| 22:36:43 | Watusimoto | we even have our rules documented now :-) |
| 22:36:50 | raptor | so if(inZone) recharge*1.1 |
| 22:37:26 | kaen | would make the interactions a little more intricate, I believe |
| 22:37:30 | raptor | multipliers... |
| 22:37:41 | sam686 | i think the energy rules list is kind of growing... http://sam686.maxhushahn.com/wiki/index.php/Energy_Rules (or should I move that to bitfighter.org wiki?) |
| 22:37:56 | kaen | since the amount each boolean would affect the recharge would be different based on what else was affecting it |
| 22:38:12 | raptor | yes, so everything affects everything by default |
| 22:38:14 | kaen | whereas with addition the change is constant (per boolean) regardless of context |
| 22:38:37 | raptor | or maybe a mixture of the two? :) |
| 22:38:48 | kaen | harder to balance perhaps, but I like that added layer of complexity |
| 22:39:01 | raptor | whatever... but i think coming away from this all, we definitely need to simplify it |
| 22:39:18 | kaen | I'm with you. |
| 22:39:25 | raptor | i know i've rewritten this method at least twice (with Watusimoto re-writing my rewrites each time... :) |
| 22:39:30 | Watusimoto | if we implement them we can stick them directly in the code, and also in the wiki |
| 22:40:07 | Watusimoto | so with 14, we can replicate (more or less) the current costs of using shield and cloak together |
| 22:40:46 | Watusimoto | though one of the original questions is still unanswered -- if you are firing, are you idle? |
| 22:40:54 | raptor | heh |
| 22:41:04 | kaen | my vote is yes |
| 22:41:05 | raptor | yes-ish |
| 22:41:06 | Watusimoto | i.e. do you get bonus from point 2 |
| 22:41:20 | kaen | energy should just be deducted when the projectile is created |
| 22:41:23 | Watusimoto | so firing is independent from stationary bonus |
| 22:41:35 | sam686 | mines and birst can be kind of a problem if firing = not idle.. |
| 22:41:45 | kaen | ^ |
| 22:42:11 | kaen | at least it would require a special case, or a flag for that aspect |
| 22:42:24 | raptor | so we could remove the firing penalty all together |
| 22:42:42 | kaen | that's what I'm thinking |
| 22:42:48 | Watusimoto | so if we say firing has no impact on being stationary, then we can get rid of point 9 as being true but irrelevant |
| 22:42:49 | raptor | because water still flows down the river, even when you divert some of it... |
| 22:43:06 | Watusimoto | unless the capacitors are hot |
| 22:43:13 | raptor | oh boy |
| 22:43:15 | kaen | heh |
| 22:43:29 | raptor | then it becomes steam |
| 22:43:32 | Watusimoto | ok, well, I'm in favor of simplifying this |
| 22:44:12 | raptor | the game 'naev' has a heat system |
| 22:44:13 | sam686 | and when there no more liquid water, it overheats and maybe melt down... |
| 22:44:36 | kaen | every played dwarffortress? it's a roguelike with fluid dynamics |
| 22:44:38 | raptor | it doesn't affect energy recharge, but does firing accuracy |
| 22:44:59 | raptor | dwarf fortress is bonkers |
| 22:45:13 | kaen | yeah it is. so is the guy who makes it |
| 22:46:22 | sam686 | also keep in mind, in Bitfighter, bullets don't instantly hit the target, like this animation http://sam686.maxhushahn.com/bitfighter/laser_phaser.gif (laser don't exist on Bitfighter maybe not yet) |
| 22:49:15 | Watusimoto | I also want to add heat to bf, but not until we have heat seekers! |
| 22:49:26 | kaen | :x |
| 22:49:34 | kaen | I was just thinking about that today actually |
| 22:49:37 | Watusimoto | the very first thing I wanted to add to BF, and I never did |
| 22:49:42 | kaen | oh man |
| 22:50:00 | Watusimoto | the more modules you use, the more firing you do, the hotter you are, so the more the heat seekers seek you |
| 22:50:18 | Watusimoto | well, i tried once, but it failed badly |
| 22:50:39 | sam686 | umm if there is no air on space, how does the ship cool down? Can't use fan in space, there is no air to blow.. |
| 22:50:51 | raptor | then for each boolean, we could have an energy factor and a heat factor |
| 22:50:51 | Watusimoto | if heat seekers become powerful, we could add heat sink module to cool your ship and make you less visible to heat seekers |
| 22:51:27 | raptor | sam686: diffusion |
| 22:51:35 | raptor | hot -> cold, always |
| 22:51:42 | Watusimoto | sam686: the heat is evaporated using a tranducive complacer |
| 22:51:45 | raptor | space = really, really cold |
| 22:51:55 | Watusimoto | or really hot |
| 22:52:10 | Watusimoto | if you're not in the shade |
| 22:52:15 | raptor | ha |
| 23:01:16 | raptor | *crickets* |
| 23:01:23 | raptor | sooo.... |
| 23:01:26 | raptor | plan of action? |
| 23:01:46 | kaen | lol |
| 23:01:51 | kaen | well, any volunteers? |
| 23:02:02 | kaen | ... |
| 23:02:05 | raptor | hehe |
| 23:02:06 | kaen | o/ |
| 23:02:12 | raptor | i volunteer kaen |
| 23:02:15 | kaen | me too |
| 23:02:20 | raptor | Watusimoto? |
| 23:02:37 | kaen | I'd happily defer to someone else though. |
| 23:02:44 | Watusimoto | go for it |
| 23:02:51 | kaen | shweet |
| 23:03:00 | raptor | i gotta solve my teleport problems... |
| 23:04:44 | raptor | this proposed simplification will allow us to add a heat factor easierm, as well |
| 23:04:50 | raptor | *easier |
| 23:05:43 | kaen | raptor, any suggestions for integrating hg into my bash PS1? |
| 23:06:38 | kaen | git comes with __git_ps1 or something like that for bash :/ |
| 23:08:39 | Watusimoto | raptor: I'm almost done with my current project, so if you are still having trouble with the teleporters, I can look tomorrow |
| 23:10:09 | raptor | Watusimoto: ok |
| 23:10:18 | raptor | kaen: how do you integrate? |
| 23:11:17 | raptor | do you mean completion? hg already has completion since it's python based |
| 23:12:38 | raptor | ohhh.. maybe you mean what current revision your own in the shell? |
| 23:12:56 | raptor | oh neat |
| 23:12:59 | raptor | that looks cool |
| 23:13:46 | raptor | kaen: I think I'm going to do this: http://mercurial.selenic.com/wiki/PromptExtension |
| 23:18:06 | kaen | raptor, with git ps1 you just put the command in the ps1 |
| 23:18:13 | kaen | much like with the link |
| 23:18:27 | kaen | but I found one that does git, merc, svn, and I think some other (cvs?) |
| 23:18:35 | kaen | it's called vcprompt |
| 23:18:42 | | raptor goes to look |
| 23:19:12 | kaen | it's written in C, so it's pretty fast |
| 23:20:27 | kaen | I did this just now: http://pastie.org/4095155 |
| 23:20:44 | kaen | gives the branch for all VCSs, blue on clean, brown on modified |
| 23:20:51 | raptor | neat! |
| 23:21:07 | raptor | which vcprompt did you use? |
| 23:21:13 | raptor | i found one in python on github |
| 23:21:26 | kaen | http://vc.gerg.ca/hg/vcprompt/ |
| 23:21:43 | raptor | i'll get that one.. |
| 23:21:47 | kaen | no deps, just make && sudo make install |
| 23:21:58 | kaen | beautiful piece of software imo |
| 23:24:26 | | BFLogBot - Commit 77b1249ad080 | Author: sam8641 | Log: Fix Robot "s_bot" and GoalZone on Zone Control |
| 23:25:00 | raptor | kaen: how are you calling that function? I put it in my ~/.bashrc |
| 23:25:36 | kaen | my PS1 line is |
| 23:25:36 | kaen | PS1='\u@\h \W$(__vcprompt_ps1) \$ ' |
| 23:25:55 | kaen | the important part is $(__vcprompt_ps1) |
| 23:27:05 | kaen | the rest is: user@host working-dir [vcprompt] $ |
| 23:27:37 | kaen | s/rest/translation/ |
| 23:28:21 | raptor | i like it |
| 23:28:57 | kaen | do you know how to change color codes? |
| 23:29:09 | raptor | it's been years since i've done it... |
| 23:30:45 | kaen | here's a good cheatsheet if you care: http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x329.html |
| 23:30:55 | kaen | I'm not a huge fan of the light blue I picked |
| 23:31:29 | kaen | hmm, maybe I should program today |
| 23:31:32 | kaen | :P |
| 23:31:35 | raptor | heh |
| 23:32:48 | raptor | ok, i'm heading home... be back later |
| 23:32:56 | kaen | bb |
| 23:33:03 | Watusimoto | bye |
| 23:33:08 | raptor | night |
| 23:33:12 | | raptor Quit () |
| 23:44:31 | | BFLogBot - Commit 442cf7c06ab9 | Author: watusim...@bitfighter.org | Log: Add contains method to Vector |
| 23:44:32 | Watusimoto | falling asleep... good night gentlemen |
| 23:44:33 | | BFLogBot - Commit 2d90cec0761c | Author: watusim...@bitfighter.org | Log: Removed useless assert |
| 23:44:34 | | BFLogBot - Commit f07a38c86b5e | Author: watusim...@bitfighter.org | Log: New isXXType function, formatting, comments |
| 23:44:36 | | BFLogBot - Commit 1c58c7dd04ee | Author: watusim...@bitfighter.org | Log: formatting |
| 23:44:37 | | BFLogBot - Commit a5793630c434 | Author: watusim...@bitfighter.org | Log: Added missing ; |
| 23:44:39 | | BFLogBot - Commit b13091832730 | Author: watusim...@bitfighter.org | Log: Ships now track which zones they are in, as well as printing a message when they enter or leave one (to be upgraded to fire events soon) |
| 23:44:40 | | BFLogBot - Commit f666f9b0f385 | Author: watusim...@bitfighter.org | Log: Merge |
| 23:44:42 | | BFLogBot - Commit c823640be499 | Author: watusim...@bitfighter.org | Log: whitespace |
| 23:44:43 | | BFLogBot - Commit d3198e798886 | Author: watusim...@bitfighter.org | Log: Remove pointless comment |
| 23:44:45 | | BFLogBot - Commit 0516ecfed8a6 | Author: watusim...@bitfighter.org | Log: Created core of new events (onShipEntered/Left Zone) |
| 23:44:46 | | BFLogBot - Commit 768dc4bbbfc7 | Author: watusim...@bitfighter.org | Log: Merge |
