| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| nash | http://xkcd.com/c256.html | 00:04 |
|---|---|---|
| tpb | Title: xkcd - A webcomic of romance, sarcasm, math, and language - By Randall Munroe (at xkcd.com) | 00:04 |
| mithro | nash: your ctrl-z problem should be fixed it you pull tpserver-py and libtpproto-py | 00:16 |
| nash | mithro: I saw, cool | 00:17 |
| mithro | nash: but there are probably a bunch of other problems | 00:17 |
| nash | And I still think having to catch an exception to deal with a select failure is pretty damn lame | 00:17 |
| mithro | nash: i'm not quite sure what you mean? | 00:19 |
| nash | exceptions were designed for heavy weight errors, things that checking on the spot made no sense for. | 00:20 |
| nash | For select - it is par for the course | 00:20 |
| nash | eg Out of memory makes sense for an exception | 00:23 |
| mithro | nash: it's a bit werid, i had never seen that before today | 00:41 |
| * nash wonders if he should start sending random signals to random python programs to see what happens | 00:51 | |
| mithro | nash: give it a try and see what happens :P | 02:46 |
| mithro | i think it may have to do with me importing the signal module | 02:46 |
| nash | mithro: At work currently - maybe tomorrow | 02:49 |
| mithro | I think i'm going to remove the signal stuff and just check for a message in the db | 02:50 |
| *** llnz has joined #tp | 03:14 | |
| mithro | hey llnz | 03:25 |
| llnz | hi mithro | 03:25 |
| mithro | your around a bit earlier today? | 03:25 |
| llnz | nothing else on this evening | 03:26 |
| llnz | and it's cold and wet outside | 03:26 |
| nash | Anywya... I'm about to bail | 03:27 |
| nash | talk to you all later - probably | 03:27 |
| llnz | mithro: are you finished on llnz? | 03:27 |
| llnz | for now | 03:27 |
| mithro | llnz: ahh yea | 03:27 |
| llnz | cool | 03:28 |
| mithro | it took a while to figure out what you where saying then :P | 03:28 |
| mithro | llnz: i didn't get a chance to figure out the cache bug | 03:28 |
| llnz | ok | 03:28 |
| CIA-30 | llnz tpserver-cpp * ra8e5f3ac6b28 /tpserver/object.cpp: | 03:33 |
| CIA-30 | Use direct methods of getting data for tp03 and eariler where available | 03:33 |
| CIA-30 | in IGObject allowing cleanup of ObjectData interface. | 03:33 |
| *** tpb has joined #tp | 03:38 | |
| *** ChanServ sets mode: +o tpb | 03:38 | |
| CIA-30 | llnz tpserver-cpp * rf44d990526d5 /tpserver/playeragent.cpp: Use the OrderQueue directly for probing orders in PlayerAgent | 03:44 |
| CIA-30 | llnz tpserver-cpp * r5da0c6467d80 / (10 files in 3 dirs): | 04:19 |
| CIA-30 | Remove unused code in ObjectData and from Fleet and Planet subclasses | 04:19 |
| CIA-30 | because the OrderQueue handles it all. | 04:19 |
| mithro | ~seen xdotx | 04:23 |
| tpb | mithro: xdotx was last seen in #tp 2 weeks, 6 days, 0 hours, 23 minutes, and 42 seconds ago: <xdotx> I'm glad that ruleset Dev Env got accepted, it looks/sounds cool | 04:23 |
| mithro | no xdotx yet? :/ | 04:23 |
| llnz | apparently not | 04:23 |
| mithro | llnz: might want to fire of an email? | 04:32 |
| llnz | i think i'll give him to friday | 04:37 |
| * llnz notes it's only Wednesday morning where he is | 04:37 | |
| CIA-30 | llnz tpserver-cpp * r118a055dd2ff /tpserver/ (orderqueue.cpp orderqueue.h): | 04:49 |
| CIA-30 | Added active and repeating fields to OrderQueue for future use | 04:49 |
| CIA-30 | for inactive queues (defaults to active) and repeating queues (defaults to | 04:49 |
| CIA-30 | not repeating). Easier to add it now before persistence is fixed. | 04:49 |
| *** nash has joined #tp | 05:05 | |
| mithro | wb nash | 05:10 |
| llnz | hi nash | 05:12 |
| nash | heyo | 05:24 |
| nash | sorry - trying to set up vmware | 05:24 |
| mithro | nash: why are you sorry about that? :P | 05:31 |
| CIA-30 | llnz tpserver-cpp * r94ca4794a71d /modules/games/ (4 files in 2 dirs): | 05:31 |
| CIA-30 | Made the position and velocity of the fleet object available in Fleet | 05:31 |
| CIA-30 | both in Minisec and MTSec. This will clean more code out of IGObject. | 05:31 |
| mithro | not that bad :) | 05:32 |
| nash | yes it is... | 05:32 |
| * mithro uses the free vmware-server at home | 05:32 | |
| nash | I'm installing it to run windows on a perfectly fine amd64 linux box | 05:32 |
| mithro | mainly use it to do electronic tax and such | 05:32 |
| mithro | oh, and for testing Thousand Parsec under Windows | 05:33 |
| * llnz ponders | 06:52 | |
| * llnz worries | 06:58 | |
| mithro | llnz: ? | 06:59 |
| llnz | i seem to be about one quarter of the way in to a near complete rewrite of minisec.... | 06:59 |
| mithro | arg, I'm so close to getting the required results | 07:00 |
| mithro | llnz: why is the worrying? | 07:00 |
| llnz | it's a very big change | 07:00 |
| llnz | and i don't really know what the result will be or if it will even run | 07:01 |
| nash | llnz: So will it help mtsec? | 07:07 |
| llnz | nash: yes | 07:07 |
| nash | SO do it then ;-) | 07:07 |
| llnz | i will have to redo the current mtsec so I can do the cleanup i was refactoring to do | 07:08 |
| llnz | it will also close at least one bug | 07:08 |
| mithro | llnz: what change are you working on? | 07:10 |
| llnz | trying to strip as much as possible out of IGObject and ObjectData | 07:11 |
| llnz | oh, ffs | 07:17 |
| Epyon | mithro, pong! | 07:18 |
| mithro | Epyon: hey, havn't seen much wiki improvement :P | 07:19 |
| mithro | llnz: what now? | 07:19 |
| llnz | currently rewriting EOT for minisec | 07:19 |
| mithro | finding lots of bugs? | 07:20 |
| llnz | thinking of moving all the actual order processing (like the moving of objects and colonising planets) in the Turn Process instead of in the various orders | 07:20 |
| llnz | this just isn't very modular | 07:21 |
| mithro | you doing something similar to how tpserver-py works? | 07:31 |
| llnz | i am moving it to the end of turn you have suggested | 07:40 |
| llnz | (ie, move orders first, then combat, then the other orders) | 07:40 |
| mithro | so it does all orders of type x, then action y, then all orders of type y, then all orders of type z? | 07:43 |
| llnz | pretty much | 07:43 |
| llnz | MinisecTurn is more or less complete, and a bit simpler | 07:57 |
| llnz | now to fix up the various orders and object types | 07:57 |
| mithro | llnz: cool | 08:02 |
| mithro | llnz: can you log a feature request against metaserver-lite about the ip-address stuff you wanted | 08:09 |
| llnz | sure | 08:09 |
| mithro | that way niphree will now about them | 08:10 |
| llnz | done | 08:23 |
| llnz | oh, i thought of yet another metaserver bug | 08:23 |
| nash | I just want to be able to have my client to browse a list of games | 08:40 |
| nash | from the metaserver ;-) | 08:41 |
| mithro | nash: what do you mean? | 08:47 |
| mithro | llnz: can you assign them to niphree rather then me? | 08:47 |
| llnz | they were auto assigned to you, i will change them now | 08:48 |
| nash | So the client can connect to the metasever, get a list of games, and the user can just click on one to connect | 08:48 |
| nash | Anyway - I'm off to bed | 08:49 |
| mithro | “I’m sine-squared, you’re cosine-squared, let’s get together and be 1″ | 08:50 |
| *** Epyon|S has joined #tp | 09:36 | |
| * Epyon|S eyes Epyon | 09:36 | |
| *** Epyon has quit IRC | 09:40 | |
| CIA-30 | llnz tpserver-cpp * r56a125109da4 /tpserver/ (objectdata.cpp objectdata.h): Make the type name available in ObjectData. | 09:49 |
| CIA-30 | llnz tpserver-cpp * r622a2a198479 /tpserver/ (objectdatamanager.cpp objectdatamanager.h): | 09:49 |
| CIA-30 | Save the Object Type names and give type number by name, and general cleanup | 09:49 |
| CIA-30 | in some of the oldest code in the server, ObjectDataManager. | 09:49 |
| CIA-30 | llnz tpserver-cpp * rbbe603008d30 /tpserver/ (game.cpp game.h): In Game, make the TurnProcess available generally, useful for Orders. | 09:49 |
| CIA-30 | llnz tpserver-cpp * re12b4e91cbe2 /tpserver/objectdatamanager.cpp: Fixed wrong dereference type in ObjectDataManager | 09:57 |
| CIA-30 | llnz tpserver-cpp * r2d239e49b235 /tpserver/ (objectdata.cpp objectdata.h): | 10:27 |
| CIA-30 | No longer have to implement tp03 packExtraData in ObjectData subclasses. | 10:27 |
| CIA-30 | Surpassed by TP04 ObjectParameters. Only use for tp03 compatible games. | 10:27 |
| CIA-30 | llnz tpserver-cpp * rb7a83d30fcb6 /modules/games/mtsec/ (avacombat.cpp fleet.cpp mtsec.cpp): Minimal fixes until I rewrite MTSec. | 10:28 |
| CIA-30 | llnz tpserver-cpp * r7e247134dd6c /modules/games/minisec/ (16 files): | 10:31 |
| CIA-30 | Rewrote parts of Minisec, now version 0.3. | 10:31 |
| CIA-30 | Uses ObjectData subclasses to access data not in the common IGObject now. | 10:31 |
| CIA-30 | Rewrote turn processing to do the right thing, colonisation no longer moves | 10:31 |
| CIA-30 | the fleet and takes no parameters. Move, then combat, then the other orders | 10:31 |
| CIA-30 | is the arrangement of processing in MinisecTurn. | 10:31 |
| mithro | llnz: all done? | 10:33 |
| llnz | for minisec yet | 10:34 |
| llnz | yes | 10:34 |
| * mithro goes to look at the new code | 10:34 | |
| llnz | will do mtsec sometime, and then clean up IGObject | 10:34 |
| llnz | and others | 10:34 |
| mithro | llnz: maybe you should have done a branch before this? | 10:34 |
| mithro | llnz: where is the turn processing code kept? | 10:36 |
| llnz | modules/games/minisec/minisecturn.cpp | 10:37 |
| mithro | thanks | 10:37 |
| llnz | why should I have branched? | 10:37 |
| mithro | llnz: so we still have a working server while you fix this? | 10:38 |
| llnz | it is working | 10:38 |
| llnz | i only commit when it's working (although it was broken for a short while there) | 10:39 |
| mithro | llnz: hrm - I still don't think you are doing this the right way - what happens if you have a Move then Colonise, if the move arrives in the same turn - why shouldn't colonise occur? | 10:39 |
| llnz | because that was the way i wanted to | 10:39 |
| mithro | why not do a "collect all move orders at pos 1 -> set velocities", "preform move", "do combat", "find all colonise orders at pos 1 -> do colonise"? | 10:40 |
| mithro | you are also not collecting all combattants at a location before performing combat | 10:41 |
| llnz | because i don't want to have to iterate through all the objects just to find them, would rather do it just once | 10:41 |
| mithro | llnz: correctness is better then efficent :P | 10:42 |
| llnz | it's still correct | 10:42 |
| llnz | just a different correct | 10:42 |
| mithro | llnz: well not really, if I have a Move to the same location I'm at, then a Colonise, the colonise should occur | 10:42 |
| CIA-30 | llnz tpserver-cpp * rfaea2ce2a516 /modules/games/minisec/ (build.cpp fleet.cpp mergefleet.cpp planet.cpp splitfleet.cpp): | 10:43 |
| CIA-30 | Fixed the Order names so they are consistent, with spaces. | 10:43 |
| CIA-30 | Closes bug: 1668117 | 10:43 |
| llnz | it will occur, the next turn | 10:43 |
| mithro | llnz: why should it take 2 turns to do something which clearly should take 1? | 10:43 |
| mithro | llnz: what about the combat issue? | 10:44 |
| llnz | it doesn't take two turns, it takes n turns to move somewhere, then one turn to colonise | 10:44 |
| llnz | what combat issue? | 10:44 |
| mithro | but you don't have a n turns to move somewhere, where n==0 | 10:44 |
| mithro | ---> you are also not collecting all combattants at a location before performing combat | 10:44 |
| mithro | two small fleets at the same location differ from 1 large fleet | 10:45 |
| llnz | ah, that combat issue | 10:45 |
| llnz | i know, will fix that later | 10:45 |
| mithro | the correct way I think is to loop over all objects putting them into a location list | 10:46 |
| mithro | then loop over the location list, combat occurs where number of objects at a location is more then 1 | 10:46 |
| llnz | that doesn't work too well | 10:47 |
| mithro | why? | 10:47 |
| llnz | what happens when they aren't exactly at the same spot, but are overlapping (diameters) | 10:47 |
| mithro | hrm.... | 10:48 |
| mithro | well I guess you could loop over all objects, checking the current location against all other locations already binned, an put it in the correct bin that way | 10:49 |
| mithro | thats n^2 however :/ | 10:49 |
| mithro | x*n where x == constant is much nicer | 10:50 |
| llnz | octtree or kd-tree | 10:50 |
| mithro | and I think you'll find that n >>> x most of the time | 10:50 |
| mithro | so even if you have 100 order types - and you have to search through all objects to find the orders for each order, thats still only 100*n | 10:51 |
| mithro | and n is likely to be 10,000 or 100,000 | 10:51 |
| llnz | for minisec i don't really care | 10:52 |
| llnz | it works, it's playable | 10:52 |
| llnz | MTSec is slightly different | 10:52 |
| llnz | anyway, it's nearly 3am | 10:52 |
| * llnz wanders off | 10:53 | |
| llnz | later all | 10:53 |
| *** llnz has quit IRC | 10:53 | |
| *** Epyon|S is now known as Epyon | 11:21 | |
| Epyon | nash, ping! | 11:21 |
| *** daxxar has quit IRC | 11:28 | |
| *** daxxar has joined #tp | 11:28 | |
| *** CIA-30 has quit IRC | 14:41 | |
| *** CIA-3 has joined #tp | 15:04 | |
| nash | Epyon: ? | 16:54 |
| nash | Well I'll be back on line in about 2 hours | 17:07 |
| *** nash has quit IRC | 17:07 | |
| *** cherez has quit IRC | 17:42 | |
| *** cherez has joined #tp | 17:43 | |
| *** TBBle has joined #tp | 17:44 | |
| *** TBBle_ has quit IRC | 17:47 | |
| *** mithro has quit IRC | 18:54 | |
| *** nash has joined #tp | 18:55 | |
| * nash waves Epyon | 18:58 | |
| Epyon | nash, I was working on the material images... | 18:58 |
| nash | Cool | 18:58 |
| nash | A problem? | 18:59 |
| Epyon | And have no clue how the antimatter and antiparticle icons should look like... ? | 18:59 |
| nash | I was thnking some sort of containment field | 18:59 |
| nash | Sort of a movie-style biohazrad container - glowing green | 18:59 |
| nash | And then a more super high tech version for the antiparticle one | 19:00 |
| Epyon | Hmmm, a reference image would help :P | 19:00 |
| jotham | did you see the vials i 3D rendered a couple of weeks ago? | 19:00 |
| jotham | might be some inspiration in look-and-feel (not actual model shape) | 19:00 |
| Epyon | No I didn't see it... | 19:01 |
| jotham | http://the.fieldsofnoise.org/Archive/temp/Vial%20E.png http://the.fieldsofnoise.org/Archive/temp/Vial%20D.png http://the.fieldsofnoise.org/Archive/temp/Vial%20C.png http://the.fieldsofnoise.org/Archive/temp/Vial%20B.png | 19:01 |
| jotham | theres a few | 19:01 |
| tpb | <http://ln-s.net/Tld> (at the.fieldsofnoise.org) | 19:01 |
| jotham | was for someone elses game project | 19:01 |
| Epyon | Hmm, I have an idea. | 19:02 |
| cherez | an idea? | 19:03 |
| tpb | disconnected from worldforge: Ping sent at 2007-05-02T19:05:41 not replied to. | 19:08 |
| *** tpb has joined #tp | 19:36 | |
| *** ChanServ sets mode: +o tpb | 19:36 | |
| *** llnz has joined #tp | 19:44 | |
| nash | heyo llnz | 19:45 |
| llnz | hi nash | 19:45 |
| nash | llnz: I see a lot of changes to tpserver - question - are you pushing them individually? Or waiting until to you have a non-trivial amount? | 19:52 |
| llnz | generally individually | 19:52 |
| nash | Any particular reason? Or you just like to keep tpb busy? | 19:53 |
| llnz | because that's the way i have always done it | 19:54 |
| nash | Fair enough | 19:55 |
| Epyon | nash, you're here? | 20:03 |
| nash | Yes | 20:04 |
| Epyon | http://chaosforge.org/files/tp_mtsec_resources_1.png | 20:05 |
| tpb | <http://ln-s.net/TmM> (at chaosforge.org) | 20:05 |
| nash | Only comment so gar - is it possible to make the 4 different bars look a little more distinct | 20:06 |
| nash | Maybe use a less processed look for one or two | 20:06 |
| nash | The yellowcake, and two containment fields look cool though ;-) | 20:07 |
| Epyon | Maybe use a "disc" shape for the uranium? | 20:07 |
| Epyon | (like on the wikipedia) | 20:07 |
| nash | Yep - that would work | 20:07 |
| nash | The important thing is some sort of visual distinctiveness | 20:07 |
| Epyon | a brick for thorium? | 20:09 |
| nash | Yep | 20:09 |
| nash | Maybe use some unprocessed ore for one of them? | 20:09 |
| nash | A pile of rocks? | 20:09 |
| Epyon | Massivium? | 20:11 |
| Epyon | Nah, better rock fot thorium, and brick for massivium | 20:11 |
| nash | If you really want to try something cool - gravitational distortion around the massivium | 20:13 |
| llnz | cool | 20:14 |
| jotham | looks good Epyon | 20:14 |
| llnz | bbl (hopefully) | 20:14 |
| jotham | but that lens flair is serious business | 20:14 |
| *** llnz has quit IRC | 20:14 | |
| Epyon | jotham: ? | 20:16 |
| Epyon | http://chaosforge.org/files/tp_mtsec_resources_2.png | 20:26 |
| tpb | <http://ln-s.net/Tm_> (at chaosforge.org) | 20:26 |
| nash | Epyon: Awesome | 20:26 |
| Epyon | Any more comments? Or should I render those at 64x64? | 20:26 |
| Epyon | BTW, facing left, or facing right? | 20:26 |
| nash | Only thing I'm worried about is that hte colours aren't strong enough on the first 4. But I'm ot sure how to fix that | 20:28 |
| nash | And as long as they all face the same way - which ever looks best | 20:28 |
| nash | Probably left | 20:29 |
| nash | Ships should probably generally face right | 20:29 |
| Epyon | This image is facing LEFT, yes? : http://chaosforge.org/files/tp_frigate_04.png | 20:32 |
| nash | Yes. | 20:33 |
| nash | Epyon: Left is retrograde motion - so agressive ships/obejcts should face right | 20:34 |
| nash | So war ships are best facing forward, to give a cowardly look, face right - great for transports | 20:34 |
| nash | Scouts should also face right | 20:34 |
| Epyon | Ok :) | 20:35 |
| Epyon | png 24 bit, no alpha channel? | 20:40 |
| nash | Please... have an alpha channel | 20:41 |
| nash | RGBA 8888 is my preferred format | 20:41 |
| Epyon | Then there will be no reflection on floor... | 20:41 |
| Epyon | I mean RGBA8888 but no alpha data :P | 20:41 |
| nash | You can still do the reflection | 20:42 |
| Epyon | Or do you want a transparent background? | 20:42 |
| nash | Transparent background | 20:42 |
| nash | Always ;-) | 20:42 |
| Epyon | Ok | 20:42 |
| nash | I hate square boxes... | 20:42 |
| Epyon | I'll remove the floor then | 20:42 |
| nash | Can you reflect of a transparent floor? | 20:42 |
| Epyon | Hmm | 20:42 |
| Epyon | Probably yes... | 20:42 |
| * nash likes to make it hard | 20:43 | |
| Epyon | Sorry, can't find it :( | 20:48 |
| nash | d'oh | 20:49 |
| Epyon | I guess I'll skip the reflections. They will be not visible on 64x64 much anyway | 20:50 |
| nash | okay | 20:53 |
| Epyon | nash, http://chaosforge.org/files/tp_mtsec_resources.zip | 21:08 |
| tpb | <http://ln-s.net/Tn9> (at chaosforge.org) | 21:09 |
| nash | Epyon: Cool | 21:10 |
| nash | Look good... | 21:10 |
| * nash notes we need an implementation of mtsec before they can really be tested... | 21:10 | |
| nash | Can you link the individual images to the wiki? | 21:10 |
| Epyon | I think I can | 21:11 |
| Epyon | Will try it later | 21:11 |
| nash | And then we'll make sure they are in the media archive when mtsec goes gold... or whatever ;-) | 21:11 |
| Epyon | BTW, I'm working on ships for my own game now, I guess I'll be able to provide you the ships for mtsec using the designs I make for you. | 21:12 |
| Epyon | http://chaosforge.org/files/sd_turrets_1.png | 21:12 |
| Epyon | http://chaosforge.org/files/sd_engines_1.png | 21:12 |
| nash | Cool | 21:14 |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!
