*** tpb has joined #tp | 00:00 | |
*** ChanServ sets mode: +o tpb | 00:00 | |
mithro | heyo peoples | 00:07 |
---|---|---|
mithro | cherez: I think your missing some status reports | 00:08 |
llnz | hi mithro | 00:08 |
Greywhind | mithro: http://codereview.mithis.com/6001/show | 00:21 |
tpb | Title: Issue 6001: Removed panelPicture, as it is now redundant with panelInfo. - Code Review (at codereview.mithis.com) | 00:21 |
mithro | Greywhind: got a screenshot? | 00:22 |
Greywhind | mithro: http://img145.imageshack.us/img145/727/screenshottpthousandpar.png | 00:24 |
tpb | <http://ln-s.net/3P5n> (at img145.imageshack.us) | 00:24 |
mithro | Greywhind: hrm, I'm not sure that is the correct place for it to be located | 00:24 |
mithro | it looks kinda squashed? | 00:24 |
Greywhind | mithro: it would be more squashed anywhere else, i think... where would you put it? | 00:25 |
mithro | what about keeping it where it was and just expanding it more left? | 00:25 |
Greywhind | mithro: it'll still be very short, heightwise | 00:26 |
mithro | I don't like how there is horizontal scrollbars? | 00:26 |
Greywhind | mithro: well, i can either move it back down to the bottom and make the bottom panel taller | 00:27 |
Greywhind | mithro: or i can keep it there and make the side panel a little wider | 00:27 |
Greywhind | which would you prefer? | 00:27 |
mithro | the other thing is that the message panel looks strange now | 00:27 |
mithro | maybe we should put them all on the left and make it wider? | 00:27 |
Greywhind | mithro: as in, move everything to the left of the starmap? | 00:28 |
mithro | well except the system tree? | 00:28 |
Greywhind | in two columns? | 00:28 |
Greywhind | well, if we're having two columns left of the starmap anyway, might as well put the system tree there too | 00:29 |
mithro | No as in one column on the left stacked | 00:31 |
mithro | so it goes information, order, messages | 00:31 |
Greywhind | ah | 00:31 |
cherez | Alright, what /is/ the difference between a description frame and a use frame? | 00:34 |
mithro | cherez: did you look into the Describale.py and OrderDesc/Order stuff in libtpproto-py? | 00:34 |
Landon | heh, I have ships moving | 00:34 |
mithro | Landon: yay! | 00:34 |
Landon | entertaining to watch a planet slowly travelling towards a cluster of ships | 00:35 |
Landon | at a collosally slow speed | 00:35 |
mithro | Landon: got some screenshots/movies? | 00:35 |
Landon | well I should get a movie of this, what's a good recorder on linux though? | 00:35 |
Greywhind | mithro: taking some screenshots of the options | 00:35 |
mithro | Greywhind: okay cool | 00:35 |
mithro | in theory people can arrange them how they want | 00:36 |
mithro | if we got around to saving/restoring their positions properly | 00:36 |
Greywhind | true | 00:36 |
Greywhind | ok... here's the list: | 00:36 |
Greywhind | 1. http://img145.imageshack.us/img145/727/screenshottpthousandpar.png | 00:36 |
tpb | <http://ln-s.net/3P5n> (at img145.imageshack.us) | 00:36 |
Greywhind | 2. http://img32.imageshack.us/img32/3161/tpoption2.png | 00:36 |
tpb | <http://ln-s.net/3P5r> (at img32.imageshack.us) | 00:36 |
Greywhind | 3. http://img32.imageshack.us/img32/3161/tpoption2.png | 00:36 |
Greywhind | oops | 00:37 |
Greywhind | 3. http://img14.imageshack.us/img14/1296/tpoption3.png | 00:37 |
tpb | <http://ln-s.net/3P5t> (at img14.imageshack.us) | 00:37 |
Greywhind | 4. http://img514.imageshack.us/img514/605/tpoption4.png | 00:37 |
tpb | <http://ln-s.net/3P5u> (at img514.imageshack.us) | 00:37 |
Greywhind | 5. http://img32.imageshack.us/img32/2131/tpoption5.png | 00:37 |
tpb | <http://ln-s.net/3P5w> (at img32.imageshack.us) | 00:37 |
Greywhind | tell me which you like best | 00:37 |
Landon | mithro: aha found one, vid coming up soon | 00:41 |
cherez | mithro: So the description frame is the part of a packet that says what the packet is and what parameters it has? | 00:42 |
mithro | so Thousand Parsec has a concept of "description" and "describable" frames | 00:43 |
mithro | describable frames have a bunch of data on the end which can be decoded by looking at the description frame | 00:43 |
mithro | so for example | 00:44 |
mithro | the Order frame | 00:44 |
mithro | is described by the OrderDesc frames | 00:44 |
mithro | which is how we have NOp, Move, etc "order types" while only having one type of frame | 00:44 |
mithro | cherez: got that all down? | 00:45 |
cherez | Yeah. | 00:45 |
mithro | so the protocol.xml stuff needs to be able to describe both cases right | 00:46 |
mithro | it needs to be able to describe "this part of the packet is describable" and "this part of the packet contains the description" | 00:46 |
mithro | right? | 00:47 |
cherez | Right. | 00:47 |
mithro | now to make it slightly more complicated | 00:48 |
mithro | there are two types of things which you want to describe | 00:49 |
mithro | things which are common to all types, and things which are unique to each type | 00:49 |
mithro | IE the difference between class variables and instance variables | 00:49 |
mithro | Greywhind: I also though up another thing you could do | 00:50 |
Landon | ah hm, I don't think the screen recorders like recording 3d apps | 00:50 |
mithro | Landon: try fraps | 00:50 |
Greywhind | mithro: what's that? | 00:50 |
Greywhind | the thing i can do, taht is | 00:51 |
Greywhind | *that | 00:51 |
mithro | Greywhind: I think if the order queue has a limit of only one order, we should hide the whole ordering stuff | 00:51 |
Greywhind | mithro: order queues can be limited to one order at a time? | 00:51 |
mithro | yes | 00:51 |
Greywhind | mithro: and what do we hide exactly? | 00:52 |
Landon | mithro: that isn't for linux though, is it? | 00:52 |
mithro | Landon: oh - no it's not | 00:52 |
mithro | let me look up the linux equivalent | 00:53 |
Landon | let me see if transcoding the file helps any | 00:53 |
mithro | Landon: what tool are you using to record | 00:57 |
Greywhind | Landon: try this: http://nullkey.ath.cx/projects/glc/ | 00:57 |
tpb | Title: glc (at nullkey.ath.cx) | 00:57 |
Landon | mithro: istanbul | 00:57 |
mithro | Greywhind: the list of orders in the queue | 00:57 |
Greywhind | mithro: so just automatically show the single order's details, and no list? | 00:58 |
mithro | Greywhind: yeah | 00:58 |
Greywhind | mithro: i don't know if i'd prefer that as a player, actually | 00:58 |
Greywhind | i can try to do it if you want though | 00:58 |
Landon | Greywhind: cool, thanks | 00:59 |
mithro | Greywhind: well - why would you prefer to see the list of orders if only one order can be given? | 01:01 |
mithro | Landon: maybe try recordmydesktop too? | 01:01 |
Greywhind | mithro: well, there could be different types, for one | 01:01 |
mithro | Greywhind: that is why you still have the drop down box | 01:01 |
Greywhind | mithro: it would just be kind of strange to suddenly just see the options for the order rather than the queue-style | 01:01 |
Greywhind | i can try it thoughj | 01:01 |
Greywhind | *though | 01:02 |
mithro | so I'm thinking that you could use an order-queue for say "current attack stance" | 01:02 |
mithro | Landon: http://recordmydesktop.sourceforge.net/faq.php#Some_windows_are_not_recorded! | 01:02 |
tpb | <http://ln-s.net/3P6E> (at recordmydesktop.sourceforge.net) | 01:02 |
mithro | Landon: and I disagree with llnz about the move stuff | 01:02 |
Greywhind | mithro: yeah, i see what you're saying | 01:02 |
Greywhind | mithro: i'll put it on my list | 01:03 |
Landon | mithro: oh? | 01:03 |
mithro | when I originally wrote the battlexml stuff, the move stuff was more like movements on a chess board | 01:03 |
mithro | cherez: did you get what I said last? | 01:03 |
Greywhind | mithro: so... any thoughts on which layout you like best? | 01:03 |
Landon | so I would need to handle collisions in the battleviewer then? | 01:03 |
mithro | I kinda like http://img514.imageshack.us/img514/605/tpoption4.png | 01:04 |
tpb | <http://ln-s.net/3P5u> (at img514.imageshack.us) | 01:04 |
mithro | Landon: well not so much collisions, but ship collision avoidence | 01:04 |
Landon | right | 01:04 |
mithro | Landon: so if you imagine you where displaying a game of chess in a pretty way it might help | 01:04 |
Landon | hm | 01:04 |
mithro | or http://img32.imageshack.us/img32/3161/tpoption2.png | 01:05 |
tpb | <http://ln-s.net/3P5r> (at img32.imageshack.us) | 01:05 |
Greywhind | mithro: which do you think is better? | 01:05 |
mithro | Greywhind: there is also something wrong with the title in the message bar | 01:05 |
Landon | mithro: I don't see how the chess analogy works though :P they move the pieces in the 3rd dimension to avoid colliding | 01:05 |
Landon | does that give me free reign to open up the 4th dimension and teleport? heh | 01:06 |
mithro | Landon: so you move the pieces around the other ones | 01:06 |
mithro | even though the move was | 01:06 |
mithro | move knight from a,b to d,e | 01:07 |
Greywhind | Landon: since you're in 3D already, it's pretty unlikely that there will be no way to move around something | 01:07 |
mithro | that might require moving around a bunch of other pieces | 01:07 |
Landon | well what I'm wondering is , hypothetically Ic ould have a cube of enemies | 01:07 |
Landon | spaced far enough that I can't move between | 01:07 |
Landon | but for some reason the ruleset wants me inside | 01:07 |
mithro | Landon: then you make the other peices for while you place the one in the center and then they move back | 01:08 |
Landon | ah, ok | 01:08 |
mithro | Landon: the easist way would be to just require a minimum distance between pieces | 01:08 |
Landon | yeah, I think I can grab a bounding sphere and get the radius of that | 01:08 |
*** tote has quit IRC | 01:08 | |
*** Demitar has quit IRC | 01:08 | |
mithro | and attach the objects to a position on a spring | 01:09 |
Landon | starting to sound like I might need a physics library | 01:10 |
mithro | as well, multiple objects may be at the same location | 01:10 |
mithro | IE you might have 12 scouts all at position x,y | 01:10 |
*** tote has joined #tp | 01:11 | |
Landon | ok | 01:11 |
mithro | so you'll have to arrange them in some way at that position | 01:11 |
mithro | Landon: I'm not sure you actually need a physics library and for now I would ignore the problem and put a big "TODO: fix this shit" | 01:12 |
Landon | yeah | 01:13 |
Greywhind | mithro: http://codereview.mithis.com/6001 | 01:14 |
tpb | Title: Issue 6001: Removed panelPicture, as it is now redundant with panelInfo. - Code Review (at codereview.mithis.com) | 01:14 |
Landon | I kind of do want to see what would happen with a dozen scouts at the same position though if I do get around to that | 01:14 |
Landon | sounds entertaining | 01:14 |
mithro | Landon: well hopefully alanp will have you some interesting battles before GSoC is through | 01:15 |
mithro | Landon: did you get my email with the in-game graphics from homeworld and eve? | 01:15 |
Landon | would be hell for firing at though | 01:15 |
Landon | yeah | 01:15 |
mithro | Landon: so you now have laser fire and move and death working? | 01:16 |
Greywhind | mithro: here's the screenshot of the newest layout: http://img43.imageshack.us/img43/727/screenshottpthousandpar.png | 01:16 |
Landon | still working on move | 01:16 |
tpb | <http://ln-s.net/3P6S> (at img43.imageshack.us) | 01:16 |
Landon | I need to add a few more things | 01:16 |
Landon | right now I can tell a ship to go somewhere once | 01:16 |
Landon | but only once, so I need a way to update the movelist | 01:17 |
mithro | I would make the messages on the right take up less space | 01:17 |
Landon | haha, speakingof eve I just got an email telling me I was a millionaire and I should come back during their free trial | 01:18 |
mithro | Sins of a Solar Empire would be another good one to check out | 01:18 |
*** Demitar has joined #tp | 01:22 | |
Greywhind | mithro: http://codereview.mithis.com/6002 | 01:27 |
tpb | Title: Issue 6002: Fixed winIdleFinder to work with tp04. - Code Review (at codereview.mithis.com) | 01:27 |
Greywhind | i'll be back in a few minutes | 01:27 |
mithro | cherez: poke? | 01:27 |
cherez | mithro: Present! | 01:28 |
cherez | Left off at describing class and instance variables? | 01:28 |
mithro | yes | 01:29 |
mithro | did you understand what I was talking about there? | 01:29 |
cherez | I believe so. | 01:29 |
mithro | so usedesc == instance variables | 01:30 |
mithro | opps | 01:30 |
mithro | I mean | 01:30 |
cherez | usestruct? | 01:30 |
mithro | usestruct == instance variables | 01:30 |
mithro | descstruct == class variables | 01:30 |
cherez | So when is the descstruct transmitted? | 01:32 |
mithro | they are transmitted in the OrderDesc | 01:32 |
mithro | or ObjectDesc | 01:32 |
cherez | But the descstruct values are universal to packets of that type? | 01:33 |
mithro | no | 01:33 |
mithro | the descstruct values are universal to orders/objects of the given type | 01:33 |
cherez | Isn't transmitting them with every object/order superfluous then? | 01:35 |
mithro | cherez: they are only transmitted with the OrderDesc/ObjectDesc | 01:35 |
mithro | (hence the name descstruct) | 01:35 |
cherez | So the description frame is only sent once? | 01:36 |
mithro | well, it's sent as many times as you want | 01:41 |
cherez | Is it sent separately from the Order/Object packet? | 01:41 |
mithro | but it makes sense to only request the frame once per object type | 01:43 |
mithro | yes | 01:44 |
cherez | Oh, that makes things simpler. | 01:44 |
mithro | there is a chance you could get an object type/order type before you know how to unpack it | 01:45 |
mithro | (because you are yet to get the OrderDesc/ObjectDesc for that type) | 01:45 |
cherez | Will those transmit anything not in protocol.xml? | 01:46 |
mithro | no | 01:46 |
mithro | well | 01:47 |
mithro | they will have an unknown list of parameters | 01:47 |
mithro | cherez: I think your best bet to to checkout the tp04 branch of libtpproto-py and play with that a bit | 01:48 |
cherez | Are those parameters separate from the parameterset parameters? | 01:48 |
mithro | no - those parameters are described by the parameterset descstruct stuff | 01:49 |
mithro | struct="I SS T [ISS[x]]" | 01:50 |
cherez | Okay, so all that gets me the that one integer in the protocol that's specified as descstruct. | 01:50 |
mithro | that is the struct string for ObjectDesc | 01:51 |
mithro | so that last list is the important part | 01:53 |
mithro | it's basically | 01:53 |
mithro | ['parameter type', 'parameter name', 'parameter desc', 'descstruct data'] | 01:53 |
*** Greywhind has quit IRC | 02:08 | |
CIA-23 | landon tpclient-pyogre * r376bd7f2b568 /src/battleviewer.py: Added several todo items as well as basic moving framework | 02:33 |
mithro | Landon: any luck with the screenshots/movies? | 02:34 |
*** jnengland77 has quit IRC | 02:50 | |
Landon | on my laptop now, but I didnt have any luck getting glcapture to work | 02:52 |
Landon | I'll try recordmydesktop after I get back upstairs though | 02:52 |
Landon | I think I might try to get a screenshot taker in the battleviewer if its simple enough | 02:53 |
mithro | Landon: I'm pretty sure a screenshot taker is simple enough, a video recorder is more complicated | 03:08 |
Landon | yeah, I've already found code for a screenshot taker | 03:12 |
Landon | ah looks like jmtan already has screenshot code in there, sweet | 03:17 |
Landon | it should transfer to the battleviewer | 03:17 |
*** reac has joined #tp | 03:59 | |
llnz | hi reac | 04:00 |
CIA-23 | ric daneel-ai * r514cd9f9841c /daneel_ai.py: | 04:01 |
CIA-23 | daneel_ai.py: Fixed a bug in the end of turn wait loop in gameLoop() | 04:01 |
CIA-23 | that prevented the client from realising the turn had completed when | 04:01 |
CIA-23 | all clients had requested an end of turn prior to the actual end of turn. | 04:01 |
CIA-23 | ric daneel-ai * rfc9bcf179819 /daneel/basic.py: | 04:01 |
CIA-23 | daneel/basic.py: | 04:01 |
CIA-23 | Added getLastTurnTime() function that returns the time of the object | 04:01 |
CIA-23 | that was updated last. | 04:01 |
CIA-23 | Modified startTurn() so that if the delta parameter is set to one, only | 04:01 |
CIA-23 | add object constraints if the object's modified time >= last_time | 04:01 |
reac | hi llnz | 04:01 |
reac | llnz, not sure if the channel gets bug tracker updates too but I just submitted some bugs in tpserver-cpp with their fixes onto it | 04:06 |
llnz | no, the channel dosn't, i'll have a look | 04:07 |
reac | just small problems with thresholdturntimer.cpp that were irritating me | 04:08 |
llnz | which tracker? | 04:08 |
llnz | sf? | 04:08 |
reac | google one | 04:08 |
llnz | ah, found it | 04:10 |
CIA-23 | landon tpclient-pyogre * re0d261478c6f /src/battleviewer.py: Moved move related stuff to the Participant object which is attached to each Entity | 04:11 |
CIA-23 | landon tpclient-pyogre * r6281e17ab110 /src/battleviewer.py: Filled out the Move event | 04:37 |
llnz | reac: the thresholdturntimer is a bit messed | 04:39 |
reac | llnz, well with that my fix it seems to work as described | 04:53 |
llnz | reac: everything except the problem with updateTimer is right, applying now | 05:12 |
Landon | hrm | 05:39 |
Landon | battleviewer is segfaulting | 05:39 |
*** jmtan has joined #tp | 06:15 | |
*** verhoevenv has joined #tp | 06:22 | |
*** jmtan has quit IRC | 06:41 | |
CIA-23 | llnz tpserver-cpp * r0418629d1078 /tpserver/ (thresholdturntimer.cpp thresholdturntimer.h): (log message trimmed) | 07:00 |
CIA-23 | Straighten out ThresholdTurnTimer. Reported by reac. | 07:00 |
CIA-23 | Renamed updateTimer to updateTimerNowOverThreshold to make it clear | 07:00 |
CIA-23 | what it does. Fixed bug, calling wrong alert, now calls | 07:00 |
CIA-23 | thresholdFinishedNewTimer instead of timerExpiredStartEOT. | 07:00 |
CIA-23 | Fixed noted checking for negatives on unsigned values (made them | 07:00 |
CIA-23 | signed and then copy to unsigned once they are definitely positive). | 07:00 |
*** alanp has quit IRC | 07:18 | |
* llnz notes he is into his third rewrite of RSPCombat in minisec | 07:23 | |
* llnz wanders off | 07:46 | |
llnz | later all | 07:46 |
*** llnz has quit IRC | 07:46 | |
mithro | Landon: I have not been seeing the daily updates to your blog? | 08:07 |
*** reac has quit IRC | 08:19 | |
*** jmtan has joined #tp | 09:01 | |
*** greenlion has joined #tp | 10:24 | |
Landon | mithro: oh, whoopsi'll get them up | 10:37 |
Landon | hey jmtan | 10:44 |
Landon | did you ever have any problems with ogre segfaulting when you add frame listeners? | 10:45 |
jmtan | hey Landon | 10:47 |
jmtan | nope, but python-ogre does segfault on occasion, particularly with cegui commands | 10:48 |
jmtan | usually the problem was with utf8 strings or memory leaks (for my cegui probs) | 10:49 |
Landon | hm | 10:49 |
Landon | well my problem is a little weirder than that | 10:50 |
Landon | in my code I set a UserDefinedObject for each Entity | 10:50 |
Landon | I check the types when I make them, after I set it, after I make the frame listener for the entity | 10:50 |
Landon | all are the correct class, Participant | 10:51 |
Landon | but when I use the ingame console and check the userObject turns into a FrameListener object | 10:51 |
Landon | (obviously, that's if the framelisteners aren't registered, or it would be segfaulting before | 10:51 |
Landon | I get far enough to pop open a console) | 10:51 |
jmtan | i'm not too sure how ogre uses UserDefinedObjects, you're saying that when you setUserObject and call getUserObject it returns differently? | 11:03 |
Landon | yeah | 11:04 |
jmtan | if you don't keep a reference in your own application, those objects you pass in may actually get garbage colleced | 11:04 |
jmtan | maybe you could try storing them in a list and see if it still changes? | 11:05 |
Landon | ok | 11:05 |
Landon | jmtan: nope, segfaulting | 11:26 |
Landon | but the user object is correct now | 11:27 |
jmtan | oh, so the problem is that 1) user object returns wrongly and 2) segfaults after adding the framelistener? | 11:27 |
Landon | I guess so | 11:28 |
Landon | I figured they were related | 11:28 |
Landon | but it appears not | 11:28 |
jmtan | is it possible to step through using pdb from a point just before registering the framelistener? | 11:30 |
Landon | I've done that | 11:30 |
Landon | and it segfaults at the startRendering call | 11:30 |
Landon | odd though, because I did get them to work before | 11:32 |
Landon | maybe I'm using framelisteners wrong? | 11:34 |
Landon | I'm creating a new instance of my MoveFrameListener class for each entity | 11:34 |
Landon | and registering each of those | 11:34 |
jmtan | i'm not sure, do you know what's changed since the time they were working? | 11:36 |
Landon | thats the only change I've pinpointed it down to | 11:37 |
Landon | commented out all my userobject stuff | 11:37 |
Landon | so it's just left creating the framelistener and registering it | 11:38 |
jmtan | that part is uncommitted at the moment? | 11:39 |
Landon | it's committed but broken | 11:39 |
jmtan | hm i can't find where you created the MoveFrameListener, could you give me the lineno? | 11:40 |
CIA-23 | landon tpclient-pyogre * rd4af00b7d71d /src/battleviewer.py: Fixed up battleviewer code, but it still segfaults | 11:42 |
Landon | you'll need to pull | 11:43 |
Landon | it'll be lines 157,158 | 11:43 |
jmtan | i think it might be the same problem, you're creating them as locals so they may be getting garbage collected, just a guess | 11:47 |
Landon | oh whoops | 11:48 |
Landon | I reverted the code before I pushed the fixes | 11:48 |
Landon | just before that though I set user objects in a self.userobjects dict | 11:48 |
Landon | I've been talking to the people in #ogre3d, I think I'll try reorganizing how I use the framelistener | 11:49 |
Landon | apparently it's not in good practice to initialize more than one or a handful of them | 11:49 |
jmtan | what about the listeners? did u put the "mfl" objects in a list too? | 11:49 |
Landon | no | 11:50 |
Landon | hm | 11:51 |
jmtan | i'd second the advice about framelisteners as well, since you can't predict the order they are called | 11:51 |
Landon | well, adding the listeners to a list seems to have fixedd it | 11:52 |
Landon | heh | 11:57 |
Landon | it works now | 11:57 |
Landon | this is too entertaining | 11:57 |
Landon | "Watch out for that planet, it's coming straight at you!" | 11:58 |
jmtan | heh, move events on a planet? | 11:58 |
Landon | it's the only entity name I remember, therefore the easiest to get out of the dictionary | 11:59 |
Landon | :P | 11:59 |
CIA-23 | landon tpclient-pyogre * rd772f80755f2 /src/battleviewer.py: Fixed FrameListener segfaulting problems due to garbage collection, move events work properly now | 12:05 |
*** jmtan has quit IRC | 13:44 | |
*** alanp has joined #tp | 14:06 | |
*** tuna-fish has joined #tp | 14:14 | |
*** epyon has joined #tp | 14:59 | |
epyon | mithro, tansell, ping! | 15:00 |
epyon | I have a git problem :/ | 15:00 |
epyon | To git+ssh://git.thousandparsec.net/git/tpserver-cpp.git ! [rejected] refactor -> refactor (non-fast forward) | 15:00 |
epyon | error: failed to push some refs to 'git+ssh://git.thousandparsec.net/git/tpserver-cpp.git' | 15:00 |
*** Greywhind has joined #tp | 15:22 | |
ezod | epyon: you need to do a git pull first, looks like llnz made a commit to your branch | 15:31 |
*** tuna-fish has quit IRC | 15:33 | |
*** mhilmi2 has joined #tp | 15:59 | |
*** llnz has joined #tp | 16:09 | |
*** mhilmi has quit IRC | 16:10 | |
llnz | morning all | 16:23 |
* llnz grumbles about work | 16:23 | |
*** mithro has quit IRC | 16:58 | |
*** mithro has joined #tp | 16:59 | |
*** mhilmi has joined #tp | 17:44 | |
*** mhilmi2 has quit IRC | 17:53 | |
*** mhilmi2 has joined #tp | 17:56 | |
*** mhilmi has quit IRC | 18:05 | |
*** greenlion has quit IRC | 18:33 | |
*** nash has joined #tp | 19:02 | |
*** mhilmi2 is now known as mhilmi | 19:11 | |
epyon | tried git pull, still failure :/ | 19:19 |
llnz | ? | 19:22 |
llnz | what is the problem? | 19:22 |
mithro | Landon: please report those problems as bugs | 19:29 |
mithro | python-ogre should be keeping references to those objects for you | 19:29 |
llnz | epyon: ? | 19:29 |
epyon | To git+ssh://git.thousandparsec.net/git/tpserver-cpp.git ! [rejected] refactor -> refactor (non-fast forward) | 19:30 |
epyon | error: failed to push some refs to 'git+ssh://git.thousandparsec.net/git/tpserver-cpp.git' | 19:30 |
llnz | epyon: you need to pull the changes from your refactor branch first | 19:33 |
epyon | "git pull"? | 19:33 |
llnz | their might be conflicit too, so also check git status | 19:33 |
llnz | yes, git pull | 19:33 |
epyon | "already up to date" | 19:33 |
llnz | ok, check git status | 19:34 |
epyon | no problems | 19:34 |
epyon | git commit succeeded, I get the error on push | 19:34 |
llnz | odd | 19:35 |
epyon | maybe I should do git pull origin? | 19:36 |
llnz | git log, what are the latest few commits? | 19:36 |
llnz | maybe | 19:36 |
epyon | PlayerVier refactiring part 1 | 19:37 |
epyon | View* | 19:37 |
*** Greywhind has quit IRC | 19:38 | |
llnz | post the names back to "Player agent TCP Connection goodies" | 19:39 |
llnz | pastebin might be a good idea | 19:39 |
epyon | http://pastebin.com/d7fc3d031 | 19:40 |
tpb | Title: pastebin - collaborative debugging tool (at pastebin.com) | 19:40 |
llnz | ok, you are missing a commit (or two) | 19:41 |
epyon | D: | 19:41 |
epyon | how do I get them? | 19:41 |
llnz | git pull should have fetched one, and a second one will be created for the merge | 19:41 |
epyon | git pull tells me that I'm up to date | 19:42 |
llnz | try "git merge origin/refactor" | 19:45 |
llnz | though i'm not sure | 19:45 |
llnz | mithro: any ideas about this git issue? | 19:52 |
CIA-23 | epyon tpserver-cpp-refactor * rfff1caccc638 /tpserver/ (playerview.cpp playerview.h): | 19:54 |
CIA-23 | PlayerView refactoring part 1 | 19:54 |
CIA-23 | * created a templated private class for holding groups of | 19:54 |
CIA-23 | data for objects, components and designs in player view | 19:54 |
CIA-23 | epyon tpserver-cpp-refactor * r5954ba3bf6f6 / (3 files in 2 dirs): Merge commit 'origin/refactor' into refactor | 19:54 |
CIA-23 | epyon tpserver-cpp-refactor * r3eb0b091f783 /tpserver/ (playerview.cpp playerview.h): | 19:54 |
CIA-23 | PlayeView refactoring part 2 | 19:54 |
epyon | :D | 19:54 |
CIA-23 | * extrated common code from list sending into a templated | 19:54 |
CIA-23 | EntityList method | 19:54 |
*** mithro has quit IRC | 19:57 | |
llnz | ah, good | 19:58 |
llnz | cool | 20:00 |
Landon | tansell: got it fixed this morning, but will do in the future | 20:02 |
tansell | Landon, so did you end up creating a video? | 20:08 |
llnz | epyon: all sorted now? | 20:08 |
Landon | ah no, I still havent checked out recordmydesktop, I'l try that tonight | 20:09 |
*** mithro has joined #tp | 20:17 | |
llnz | epyon: i've always been a little shy of templates | 20:26 |
epyon | they'll be replaced with inheritance later -- but this can't be done without breaking the interfaces. | 20:27 |
epyon | I'm preparing ground for that however | 20:27 |
llnz | ok, cool | 20:27 |
epyon | however, in my humble opinion templates are what makes C++ so powerful :) | 20:28 |
tansell | I like templates | 20:28 |
epyon | at least templates are the reason I switched from FreePascal to C++ ;) | 20:28 |
tansell | but I remeber libatlas-c++ breaking C++ compilers with it's templates usage :) | 20:29 |
llnz | tansell: me too, though the compiles got better over time | 20:29 |
llnz | s/compiles/compliers/ | 20:30 |
* epyon is going to run an advanced class in "Advanced C++ Programing : Templates, Metaprogramming and C++0x" at the university next year :D | 20:30 | |
* llnz gives up trying to fix that | 20:30 | |
llnz | cool | 20:30 |
tansell | yes - they where not even doing anything all that complicated and it was like 10 years ago | 20:31 |
epyon | Anyway, my main line of defence is that Open Source code should be foremost readable and understandable, compiling speed can be sacrificed | 20:31 |
tansell | epyon, compile speed has never been a problem for tpserver-cpp | 20:36 |
CIA-23 | epyon tpserver-cpp-refactor * re1263a8b8180 /tpserver/ (playerview.cpp playerview.h): | 20:41 |
CIA-23 | PlayerView refactoring part 3 | 20:41 |
CIA-23 | * minor fixes | 20:41 |
CIA-23 | * general cleanup | 20:41 |
CIA-23 | * more repeating code removal | 20:41 |
epyon | Ok, further PlayerView refactoring will have to wait untill I will be able to break the interfaces :/ | 20:44 |
tansell | epyon, out of interest which coding style guide did you end up using? | 20:49 |
epyon | none, basically I'm following what is already there, just adding a few things agreed upon with llnz | 20:49 |
tansell | http://sourceforge.net/projects/cpplint/ or http://code.google.com/p/google-styleguide/source/browse/trunk/cpplint | 20:51 |
tpb | <http://ln-s.net/3PRQ> (at code.google.com) | 20:51 |
tansell | might be a good idea to setup a config file which supports the current coding convention | 20:51 |
epyon | I'll think about it | 20:51 |
llnz | epyon: btw, currently i'm using 4 space indents | 20:51 |
epyon | lol | 20:51 |
epyon | llnz: I'm reformating everything to 2 spaces :P | 20:52 |
llnz | epyon: that's ok | 20:52 |
epyon | this is how most of the code was anyway | 20:52 |
llnz | as long as it's consistent with a file | 20:52 |
llnz | i know | 20:52 |
epyon | <ESC>, V, PgDn, PgDn, ... = | 20:53 |
epyon | :) | 20:53 |
* epyon , if he wouldn't be a windows person, would use vim for everything <3 | 20:53 | |
tansell | cherez, http://darcs.idyll.org/~t/projects/figleaf/doc/ | 21:25 |
tpb | Title: figleaf -- Python code coverage analysis (at darcs.idyll.org) | 21:25 |
cherez | tansell: Thanks, I'll give that a try. | 21:26 |
tansell | nfi if it works | 21:27 |
cherez | tansell: It works, although the output is a bit ugly. | 21:36 |
*** verhoevenv has quit IRC | 21:47 | |
alanp | hrmph | 22:06 |
alanp | fuck | 22:28 |
epyon | swearing D: | 22:28 |
* epyon runs in fucking panic! | 22:28 | |
alanp | hehe oops | 22:28 |
CIA-23 | epyon tpserver-cpp-refactor * rf1287fb7b3a1 /tpserver/ (7 files): Minor preliminary Design classes cleanup | 22:28 |
*** zzorn has quit IRC | 22:54 | |
CIA-23 | epyon tpserver-cpp-refactor * r0aeb3cff5035 / (8 files in 3 dirs): Minor cleanups here and there | 23:12 |
CIA-23 | epyon tpserver-cpp-refactor * r8d464ca97ce0 /tpserver/propertyvalue.cpp: Compile fix | 23:12 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!