#bitfighter IRC Log

IRC Log for 2012-06-19

Timestamps are in GMT/BST.
00:06:25 raptor hmmm...  join polygons...
00:09:18 sam686 what polygons?
00:09:45 raptor watusimoto just pushed an 'experimental' feature to the editor... i'm trying to get it to work, but no success yet
00:10:27 raptor oh hey, it works for polywalls
00:11:23 raptor haha, doesn't seem to work always - sometimes producing more complex shapes
03:12:51 raptor sam686: do you get a crash when trying to restart a level (since watusimoto's sort changes)
03:12:52 raptor ?
03:14:08 sam686 yes a crash... null pointer in geometricSort
03:15:47 sam686 I have just got rid of multiple "extern void glColor(Color)" and moved it to OpenglUtils  (it was on UI.h, and several .cpp files)
03:15:55 raptor oh good!
03:16:59 BFLogBot - Commit 492b12d23b3e | Author: sam8641 | Log: Get rid of multiple "extern void glColor" and moved glColor(Color) to OpenglUtils
03:18:11 sam686 Barriers have null mGeometry trying to sort ( mGeometry.getGeometry()->getGeomType();)
03:19:12 sam686 GridDatabase::addToDatabase.. really trying to sort after every objects being added?
03:20:10 raptor looks like it...   watusimoto did say he wasn't sure how it'd affect normal gameplay
03:23:38 sam686 the editor help says "Split wall at selected vertex with [/]"  well guess what the button / does instead in editor?
03:24:08 raptor crash?
03:24:25 sam686 no,  it opens up the console instead of splitting barriers...
03:24:56 raptor oh fun
03:24:59 raptor that's my problem...
03:25:02 raptor i'll fix that one
03:27:22 sam686 join polygons with polywalls doesn't work right when one of the polygon is going counter clockwise and the other is clockwise
03:31:10 sam686 join polygons also won't work if that will combine 2 polygons into one with hole in the middle...
03:40:51 raptor also, undo doesn't undo the join, it undos the join+last action
03:42:02 raptor oh sam686, the split wall at vertex uses the other slash:  [\]
03:42:08 raptor so it works ok
03:43:22 sam686 has left
03:43:30 sam686 has joined
03:43:30 ChanServ sets mode +v sam686
03:43:45 sam686 well oops, i guess i read it wrong  [/] [\]
03:43:56 sam686 what else would i call it? slash?
03:48:04 raptor backslash
03:48:30 raptor i always say that the \  = backslash   and / = slash or forward slash
03:49:05 sam686 ok...  what about left slash?
03:49:16 sam686 or a side slash?
03:49:43 sam686 i was kind of joking about that...
03:49:51 raptor ha
03:57:06 BFLogBot - Commit 2268ff33ac37 | Author: buckyballreaction | Log: Add ability to disable ship weapons and modules.  Disable when placing teleport exit
03:59:15 raptor ok, what is left to make teleport working ok?
03:59:19 raptor give it mor health?
03:59:27 raptor oh - bursts don't damage it for some reason...
03:59:48 sam686 maybe make your teleport exit follow your ship till you use it..
04:03:13 raptor you mean allow other players to see that you're placing one?
04:03:54 sam686 well if you get destroyed after placing teleport enterence, but not teleport exit, the teleporter is useless...
04:04:07 sam686 i would like that teleport exit to be where you die..
04:04:40 raptor interesting idea
04:05:02 raptor i know watusimoto wants the teleport to be destroyed...  but your idea is neat, too
04:05:41 raptor the idea is to make it more difficult to place a teleport exit because engineered teleports might be too powerful...
04:06:08 sam686 but then one problem, you might die in a place the teleporter exit isn't allowed to be (in the walls)
04:07:09 BFLogBot - Commit 097d2e05214e | Author: sam8641 | Log: sortObjects(mAllObjects); on Barriers doesn't work (null mGeometry), Disable "Bad level line" assert.
04:17:14 BFLogBot - Commit 056e40e9d943 | Author: buckyballreaction | Log: Fix bursts not harming engineered teleport
04:17:37 raptor well sam686, i'm heading to bed early
04:17:41 raptor have a good night
04:17:43 sam686 ok
04:18:02 raptor Quit ()
04:32:30 kaen has joined
04:42:24 zoomber_mbp has joined
05:17:24 BFLogBot - Commit 786e714de6fa | Author: sam8641 | Log: Fix ZAP_DEDICATED, moved include "dirent.h" to outside the Zap namespace
06:41:29 zoomber_mbp aragh
06:41:29 zoomber_mbp has left
07:42:50 watusimoto has joined
07:42:50 ChanServ sets mode +o watusimoto
08:50:00 watusimoto1 has joined
08:50:31 watusimoto Quit (Ping timeout: 264 seconds)
08:52:05 watusimoto has joined
08:52:05 ChanServ sets mode +o watusimoto
08:55:40 watusimoto1 Quit (Ping timeout: 276 seconds)
09:03:24 BFLogBot - Commit 25586b409987 | Author: sam8641 | Log: Fixed addbot crash on doesn't exist robot file name.
09:03:54 sam686 Quit (Ping timeout: 245 seconds)
11:09:23 LordDVG has joined
12:26:34 Watusimoto_ has joined
12:58:11 LordDVG Quit (Ping timeout: 252 seconds)
13:16:35 Little_Apple has joined
13:16:40 Little_Apple helloo
13:35:02 Watusimoto_ Quit (Ping timeout: 246 seconds)
13:37:07 Little_Apple BYEEE
13:37:09 Little_Apple Quit (Quit: Page closed)
15:41:18 raptor has joined
15:41:19 ChanServ sets mode +o raptor
15:41:36 raptor guten
15:59:56 watusimoto hi
16:00:00 raptor hello
16:00:36 raptor so you now cannot shoot or use modules when placing a teleport exit
16:00:58 raptor should I still pass a bit to alert other players that you're placing it?
16:03:00 watusimoto I would say not -- though playtesting may suggest we should
16:03:11 raptor ok
16:03:13 watusimoto sounds like you are making great progress
16:03:31 watusimoto just htinking that another text message might not be what we need
16:03:32 raptor well, i fixed a couple other things - it looks like it's ready for play testing...
16:03:40 raptor text message?
16:03:47 watusimoto I do think the ship should be marked somehow though, so people can see what they're up to
16:04:00 raptor ^^ that's the bit i was talking about
16:04:03 watusimoto I meant more messages on the screen
16:04:10 watusimoto oh
16:04:14 watusimoto then I misunderstood
16:04:19 raptor send a bit in packUpdate
16:04:23 watusimoto then... why, yes!
16:04:26 watusimoto yes
16:04:29 raptor ok
16:04:39 watusimoto either extra bit or s2c message(s)
16:04:45 watusimoto we send those updates a lot
16:04:45 raptor not both?
16:04:54 watusimoto both?
16:05:13 raptor already an s2c message is sent:  player built a teleport entrance
16:05:13 watusimoto I think one method would suffice, would it not?
16:05:32 watusimoto and clients can identify the ship from that msg, right?
16:05:40 raptor ha
16:05:46 raptor not really
16:06:04 watusimoto oh, you send a message using the normal channels
16:06:13 raptor if by 'identify' you mean they match the player name from the message to the ship
16:06:25 watusimoto some methods have special s2c for sending messages related to a special event
16:07:46 raptor and this is now where i say:  "let's start over and then you can tell me your idea without misinterpretation"
16:07:59 raptor wipes his mind clean
16:08:14 watusimoto I was thinking the same thing
16:08:27 watusimoto how do you send the message?  (i.e. what method?)
16:08:37 raptor looking...
16:08:53 raptor it's the same mechanism that tells everyone:  raptor has engineered a turret
16:09:54 watusimoto ok, via s2cEngineerResponseEvent
16:10:24 raptor no
16:10:40 raptor ClientInfo::sEngineerDeployObject
16:10:53 raptor uses  s2cEngineerResponseEvent
16:10:56 raptor but also does:  gameType->broadcastMessage
16:11:02 watusimoto ah, I see
16:11:30 watusimoto totally generic message
16:12:12 raptor yes
16:12:43 watusimoto I think engineering a ff is a rare event
16:12:53 watusimoto so adding 1 bit to every ship update is excessive
16:12:55 raptor and I *thought* your idea was to have some sort of visual feed back on a players ship to show what they are up to
16:13:00 watusimoto yes
16:13:03 watusimoto it was
16:13:04 watusimoto it is
16:13:07 raptor ok
16:13:26 raptor then my idea was to add a bit (I unfortunately already added one for disabling the weapons/modules)
16:13:49 watusimoto so maybe we should broadcast an s2cPlayerEngineeringTeleport(status) where status is entryPlaced or completed
16:14:02 raptor i checked stream size after adding that bit, and it was still the same (since stream are sent in multiples of 32, i think?
16:14:10 watusimoto and clients can use that to render the ship
16:14:21 watusimoto Probably multiples of 8
16:14:24 watusimoto but not sure
16:15:41 watusimoto but if we did a sc2, we wouldn't need to send the message; the client could generate the message
16:15:42 raptor so i guess i'm not sure how to properly mark the ship without adding a bit on the Ship object...
16:16:00 raptor because Ship goes in and out of scope a lot...
16:16:04 watusimoto we have 2 basic mechanisms for marking ship status:
16:16:09 raptor enlighten me!
16:16:11 watusimoto 1) bit on the update
16:16:26 watusimoto 2 ) s2c to each client informing them of something
16:16:44 raptor if #2 is used, how is that data kept persistent?
16:16:54 watusimoto client would need to track it
16:17:06 watusimoto probably on client's clientInfo for remote player
16:17:10 raptor ah ha!
16:17:16 raptor that was my next question...  where
16:17:31 watusimoto clientInfo doesn't go out of scope
16:18:03 raptor so ClientInfo is used as a cache for anything really?
16:18:14 watusimoto yes
16:18:21 watusimoto it has all the info a client has about other players
16:18:38 watusimoto looking at ship's update method
16:18:45 watusimoto we send bits for other rare events
16:18:47 raptor it's bonkers
16:18:52 watusimoto such as team changing
16:18:54 raptor it really needs to be reduced
16:18:57 raptor yes ^^
16:19:38 watusimoto yes, though I don't think the game is overly data heavy given a modern network
16:20:08 watusimoto hell, if you want to be absolutist, update should only have moves and other "streaming" info
16:21:24 watusimoto It just feels that engineering something is really more a singular event than something that is related to ship status
16:21:32 watusimoto but it is a gray area, a continuum
16:21:54 watusimoto and it is only 1 bit
16:23:45 watusimoto But I would suggest broadcasting a s2c to alert clients that a player is engineering something
16:24:06 watusimoto that's my judgement, though I'm not adamant about it
16:25:08 raptor i am more absolutist, i think...
16:25:46 raptor i would love to reduce network consumption any where I can...
16:26:08 raptor oh - team changing for robots might need to stay..
16:26:18 raptor because they don't have a client info
16:26:23 watusimoto ah
16:26:26 watusimoto they don't
16:26:27 watusimoto ?
16:26:39 raptor i think you made them taht way
16:26:45 watusimoto probably so
16:26:56 raptor when you did the whole ClientRef -> nothing...  oops -> ClientInfo
16:27:03 raptor :)
16:27:13 watusimoto :-)
16:28:20 watusimoto I think the s2c would use more bandwidth when it's being used, but less overall
16:28:45 watusimoto though if the update packets don't actually change in size, the bit is (for the moment, anyway) free
16:28:53 raptor yes, but it's only sent once instead of multiple times a second
16:29:47 watusimoto well, you'll be able to remove the message broadcast, so that will somewhat (maybe totally?) compenesate
16:30:03 raptor so now i wonder - does this mean i need to move the teleport pointer from Ship ->  ClientInfo
16:30:05 watusimoto if you're being absolutist
16:30:31 watusimoto that's a good question
16:30:41 watusimoto though you're not storing the pointer there on the client, only a flag
16:30:45 watusimoto so maybe not
16:30:56 raptor it is the pointer
16:31:04 watusimoto not on the cleint side thought
16:31:08 raptor no
16:31:22 watusimoto so on the client, you'll need a bool isEngineeringTeleport
16:31:29 watusimoto on the server you need a pointer
16:31:32 raptor yes
16:31:38 watusimoto do they need to be in the same place?
16:31:38 raptor looks a ClientInfo
16:31:43 watusimoto maaybe
16:32:01 watusimoto though you could have a isEngrTleport() method on clientInfo
16:32:13 watusimoto on RemoteClientInfo, it just returns a local bool
16:32:41 watusimoto on server, it could check if the pointer is NULL (and that pointer could be anywhere the clientInfo can see)
16:33:14 raptor ClientInfo points to Ship already
16:33:17 raptor so that is good
16:33:26 watusimoto so you could store the teleport pointer on ship
16:33:34 raptor ok, i'm a little confused at how ClientInfo and RemoteClientInfo interact
16:34:02 watusimoto they don't
16:34:04 watusimoto :-)
16:34:13 raptor i see how RCI is initialized...
16:34:26 raptor in GameType::s2cAddClient
16:34:37 watusimoto ok
16:34:42 watusimoto clientInfo is base class
16:34:51 watusimoto from that we get FullClientInfo and RemoteClientInfo
16:35:10 watusimoto RCI is simply for clients to track info about other remote clients
16:35:19 watusimoto FCI is for cleints to track info about themselves
16:35:27 watusimoto and for the server to track info about all clients
16:35:34 raptor ah, and both are children of CI
16:35:35 watusimoto if you have an RCI, you know less
16:35:45 raptor wait what?
16:35:47 watusimoto CI isn't used anywhere directly
16:35:50 raptor FCI is server
16:36:02 raptor ahh - interesting
16:36:04 watusimoto you know less about remote players than you do about yourself, or than the server knows about everyone
16:36:41 watusimoto // RemoteClientInfo is used on the client side to track information about other players; these other players do not have a connection
16:36:42 watusimoto // to us -- all the information we know about them is located on this RemoteClientInfo object.
16:37:05 raptor ok
16:37:10 raptor so for an exercise
16:37:20 raptor if i wanted to add a bool mIsEngineeringTeleport
16:37:37 raptor would I add that to CI and put a setter/getter there?
16:37:45 watusimoto yes
16:37:51 raptor then use an s2c to update all the RCIs?
16:38:03 watusimoto though the setter on FCI will never be used
16:38:08 watusimoto yes
16:38:20 watusimoto and the getters will have different implemenation on FCI and RCI
16:38:30 raptor how so?
16:38:45 watusimoto LCI will just be return mIsEngineeringTeleport
16:38:59 watusimoto RCI will be return ship->engineeredTeleport != NULL
16:39:00 watusimoto or whatever
16:39:38 watusimoto you don't actually need the boolean on LCI -- should probably be private var on RCI
16:39:39 raptor LCI = FCI?
16:39:43 watusimoto sorry, yes
16:39:46 watusimoto old thinking
16:39:56 watusimoto used to be LocalCI
16:40:05 raptor ah
16:40:15 watusimoto but that name was way too confusing
16:40:40 raptor then how can RCI check for the teleport pointer on the Ship object when it is not on the server?
16:41:45 watusimoto I screwed up
16:41:52 watusimoto FCI will be return ship->engineeredTeleport != NULL
16:42:07 raptor ok, yay - that makes more sense
16:42:29 watusimoto RCI will just be return mIsEngineeringTeleport
16:42:45 watusimoto yeah, that was all jumbled
16:43:04 watusimoto I've had a long day
16:43:08 raptor sorry  :/
16:43:42 watusimoto so is that all clear?
16:43:52 raptor yes-ish
16:44:06 raptor i'll have to do some refactoring and get used to the architecture a bit
16:44:13 raptor but i think i can start now...  :)
16:44:18 watusimoto I'm heading home then
16:44:35 watusimoto back later... I want to get that poly merge working completely
16:44:39 raptor oh
16:44:46 watusimoto I think we have some winding direction issues with clipper
16:44:46 raptor did you read about the bugs we found with it?
16:44:55 watusimoto no, but I know there are plenty
16:44:57 raptor ok
16:45:00 watusimoto I think all related to winding direction
16:45:03 raptor i'll let you go, then
16:45:04 raptor yes
16:45:11 watusimoto merging seems to work with polys would same direction
16:45:18 watusimoto and not with different direction
16:45:21 watusimoto so easy enough to fix
16:45:28 watusimoto if that's really the core issue
16:45:40 watusimoto I'm confident it's striaghtforward
16:45:47 watusimoto so later!
16:45:50 raptor later!
16:50:09 watusimoto Quit (Ping timeout: 245 seconds)
17:02:39 Watusimoto has joined
17:17:22 IAmBeard has joined
17:17:30 IAmBeard Quit (Client Quit)
17:22:07 raptor Watusimoto: i recommend updating and doing a full recompile - sam686 touched a lot of headers last night with a clean-up/refactor of his
17:22:16 Watusimoto ok
17:25:16 kaen I'm getting segfaults the second time I 'test level' in the level editor
17:25:22 kaen after full clean/recompile
17:25:33 kaen also, the 13 fix is in my clone
17:25:34 raptor kaen: what rev are you at?
17:25:38 raptor really?
17:25:42 raptor sweet!
17:25:49 kaen 4835
17:26:09 raptor uh...  i mean the other one (those numbers appear differently for each of us..)
17:26:45 kaen 25586b409987
17:27:50 kaen I didn't realize how smart the turret firing logic is
17:28:39 raptor heh, yeah - i try to avoid it so i don't have to refigure it out...
17:28:50 raptor oh, can you do one thing for me?
17:28:54 kaen sure
17:29:28 raptor small optimization:  change len() to lenSquared() or whatever it's called:  if comparing it'll avoid the (relatively) expensive sqrt function
17:29:46 raptor does that make sense?
17:29:49 kaen yep
17:33:01 kaen suddenly, pages of linker errors...
17:33:02 kaen wtf.
17:38:35 kaen ok, pushed
17:39:00 kaen also, that segfault is gone. I pinky promise that I make clean'd before, though...
17:39:26 raptor haha
17:41:40 raptor ok, pushed
17:41:47 raptor thanks!
17:41:51 kaen you bet
17:42:59 sam686 has joined
17:42:59 ChanServ sets mode +v sam686
17:43:32 kaen question: what's the advantage of using that wiki page over the google code tracker?
17:43:50 raptor umm
17:44:05 raptor less official - mostly used for bugs we've introduced
17:44:31 raptor ok i don't know...
17:44:41 BFLogBot - Commit bffd1d1efe25 | Author: kaen  | Log: Check that friendly units are actually in the way before suppressing turret firing
17:44:43 BFLogBot - Commit 823d805ebf27 | Author: kaen  | Log: Use lenSquared instead of len for distance comparison
17:45:04 raptor i guess we've been using the google code issues tracker more for official features or changes we don't want to get to right away...  :)
17:50:39 raptor so kaen, are you a college student looking for a project to work on during the summer?  :)
17:50:57 zoomber_mbp has joined
17:51:05 raptor (speaking of contributing to bitfighter..)
17:52:19 Watusimoto Quit (Ping timeout: 250 seconds)
17:52:21 kaen raptor, guilty on both counts
17:52:35 raptor excellent
17:52:53 raptor what are you studying (if you don't mind my asking)?
17:55:57 raptor because i'm actually heading back to school myself...  today in fact..   :-D
18:12:20 kaen pre-reqs for now. I'm going to transfer to a 4-year after I get my AS. Trying to get a comp sci degree
18:12:42 kaen gratz, by the way :)
18:12:42 raptor cool
18:13:01 raptor heh - i'm going back for computer or electrical engineering
18:13:14 zoomber_mbp java sucks
18:13:16 raptor but it'll be super slow
18:13:22 raptor oh hi zoomber_mbp
18:13:23 kaen I was thinking about EE. I might try to double major
18:15:10 raptor is there plenty of crossover with the two at your school?
18:25:05 kaen at the 4 year I'm looking at there is
18:58:12 Watusimoto has joined
18:59:18 raptor Watusimoto: is the proper way to update *all* clients to call the s2c protocol for each one using mServerGame->getClientCount() in a for loop?
18:59:41 raptor (it looks like that's the common way to do it...)
18:59:47 Watusimoto then yes :-)
19:01:25 raptor also i was wrong before:  robots do have ClientInfo - it's GameConnection they dont' have anymore
19:04:26 Watusimoto right, that makes more sense
19:04:46 Watusimoto the only thing on GameConnection should be connection related stuff
19:04:54 raptor heh
19:04:57 raptor yeah, about that class
19:05:07 Watusimoto before there was a lot of other stuff on it, that caused problems when we disconnected bots
19:05:14 raptor it's one of my headache classes
19:05:22 Watusimoto well, bots had the connection, though it was not actually connected to anything
19:05:30 Watusimoto it served as a defacto extension to clientInfo
19:05:43 Watusimoto which was bad
19:06:30 raptor soo...  does that mean the s2c stuff related to engineer should go in clientInfo?
19:06:43 raptor there other stuff lying around, too...
19:07:33 raptor seems like we need a class for s2c/c2s methods that just does clientInfo-related things
19:10:09 LordDVG has joined
19:36:55 Watusimoto sorry -- off somewhere
19:37:19 Watusimoto but probably yes
19:43:06 raptor right now, everything clientinfo-related seems routed through gametype or gameconnection (much less so)
19:46:53 raptor so...  you agree to a new RPC class that handles ClientInfo-specific changes?
19:47:44 raptor or maybe put the RPCs in the ClientInfo class?
20:24:10 raptor well, i have to go - i'll check chat logs a bit later (i've got class!)
20:24:41 raptor Quit ()
20:37:18 zoomber_mbp Quit (Quit: zoomber_mbp)
20:41:55 koda has joined
20:49:51 LordDVG Quit (Remote host closed the connection)
22:20:25 BFLogBot - Commit e0595ef49753 | Author: watusim...@bitfighter.org | Log: Merging polygons works pretty well now in editor.  Basically finished.
22:20:27 BFLogBot - Commit e37a95645deb | Author: watusim...@bitfighter.org | Log: Merge
22:40:02 kaen Quit (Read error: Operation timed out)
22:54:59 kaen has joined
Index Search ←Prev date Next date→
These logs were automatically created by BFLogBot on irc.freenode.net.