| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| *** jernejovc has joined #tp | 00:50 | |
| *** mithro has quit IRC | 00:55 | |
| *** nebajoth has quit IRC | 01:04 | |
| *** jernejovc_ has quit IRC | 01:04 | |
| *** alanp has quit IRC | 01:18 | |
| Landon | alanp: I've been up here on campus all summer :P just went back home this weekend for a friends 21st | 01:54 |
|---|---|---|
| *** nebajoth has joined #tp | 01:59 | |
| *** alanp has joined #tp | 02:01 | |
| alanp | llnz: ping | 02:02 |
| llnz | alanp: pong | 02:02 |
| alanp | llnz: i can't find a good way to check the tubes in the ships... | 02:02 |
| alanp | basically when combat happens, i want to create a list of available tubes | 02:03 |
| llnz | why is it hard? | 02:04 |
| llnz | you have a list of design types and quantity of those designs in the fleet | 02:05 |
| alanp | yes | 02:05 |
| alanp | I think I would have to change the tube components to have some sort of specifier | 02:05 |
| alanp | AlphaMissileTube property or something | 02:05 |
| llnz | why not have a property? | 02:05 |
| llnz | snap | 02:05 |
| alanp | i figured i would be okay with just one property | 02:06 |
| alanp | that's a problem :-) | 02:06 |
| alanp | OK, so i will change that | 02:06 |
| alanp | for the lambda function | 02:06 |
| alanp | (lambda (design) (+ 1)) should be ok? | 02:07 |
| alanp | ?? | 02:09 |
| alanp | brb | 02:09 |
| *** alanp has quit IRC | 02:09 | |
| *** alanp has joined #tp | 02:10 | |
| llnz | which function is that? | 02:11 |
| alanp | <AlphaMissileTube><![CDATA[(lambda (design) (+ 1))]]></AlphaMissileTube> | 02:11 |
| llnz | property value on the component? | 02:12 |
| alanp | yes | 02:12 |
| alanp | exactly | 02:12 |
| llnz | just (lambda (design) 1) | 02:12 |
| llnz | don't need the plus | 02:12 |
| llnz | the property value function will sum them | 02:12 |
| alanp | it will sum all of them? | 02:12 |
| alanp | so if I add 10, I get 10? | 02:13 |
| llnz | yes | 02:13 |
| alanp | oh, great | 02:13 |
| alanp | wasn't sure about that one | 02:13 |
| alanp | any better way than a property for each tube? | 02:13 |
| llnz | nope, one property for each tube type | 02:14 |
| alanp | ok | 02:15 |
| alanp | I guess I'll have to make a set in the combat class using the names of the properties, kind of ugly | 02:15 |
| alanp | list.insert(ds->getPropertyByName("x")); for each one | 02:16 |
| llnz | why is that necessary | 02:16 |
| alanp | how else am i going to get a list of all tubes in the combat class? | 02:16 |
| llnz | the number of tube-type component is fixed | 02:17 |
| alanp | yes, i have a huge problem with using numbers like that though | 02:17 |
| alanp | it's only fixed until somebody modifies the source and adds another property not at the end | 02:17 |
| alanp | at least the name isn't going to really change, and if you do change the name you can grep and find it elsewhere | 02:18 |
| alanp | using the numbers just sucks, imo | 02:18 |
| llnz | components | 02:18 |
| alanp | ? | 02:19 |
| llnz | wasn't suggesting to use the numbers directly | 02:20 |
| alanp | the number of tube-type component is fixed, yes | 02:23 |
| alanp | i need to know how many of each tube are in each ship involved in combat | 02:23 |
| alanp | my idea was to iterate through the list of ships, check the design store to see which tubes they had | 02:24 |
| alanp | and then when I do that, it will be easy to use the missile resources that I already have | 02:24 |
| alanp | so i iterate through the ships, I need to look for each kind of tube on each ship | 02:25 |
| alanp | this makes sense, no? | 02:25 |
| alanp | once i have the list of the tubes involved in the battle, i can go through the weaponry available | 02:26 |
| llnz | yes | 02:27 |
| alanp | but to get the list of tubes, I'm going to have to reference them by name (because I don't like to by number) | 02:27 |
| llnz | true | 02:28 |
| llnz | there is a fixed number of names (for those properties) | 02:28 |
| *** DTRemenak has quit IRC | 02:28 | |
| nebajoth | I haz a torpedo tube | 02:28 |
| nebajoth | IN MY PANTS | 02:28 |
| llnz | bbs, dinner | 02:29 |
| * alanp punch-kick nebajoth | 02:29 | |
| *** DTRemenak has joined #tp | 02:29 | |
| nebajoth | PUNCH! KICK! ITS ALL IN THE MIND! | 02:29 |
| nebajoth | If you wanna test me, I'm sure you'll find | 02:30 |
| nebajoth | The things I'll teach ya | 02:30 |
| alanp | bbl | 02:30 |
| nebajoth | is sure to beat ya | 02:30 |
| nebajoth | :( | 02:30 |
| * llnz is back | 03:22 | |
| nebajoth | I think alanp stepped out for a shawarma | 03:24 |
| nebajoth | NOT THAT I AM HIS KEEPER | 03:24 |
| nebajoth | but he mentioned it | 03:24 |
| llnz | nebajoth: tone it down | 03:24 |
| nebajoth | yes sir | 03:25 |
| nebajoth | excuse me, I spend my other irc time in a gaming clan channel | 03:25 |
| nebajoth | with teenagers | 03:25 |
| nebajoth | it affects my patterns | 03:25 |
| nebajoth | kinda drastically at times | 03:25 |
| llnz | ok | 03:25 |
| llnz | so what's your interest in Thousand Parsec? | 03:26 |
| nebajoth | as a potentially interesting open source project that is a game | 03:26 |
| nebajoth | I run a 50+ member clan | 03:26 |
| llnz | ok, cool | 03:26 |
| nebajoth | and we've been dabbling in small clan projects | 03:26 |
| nebajoth | and its been a good way to get all the teenaged kids pointed in the same direction | 03:26 |
| nebajoth | so I've been cruising open source games | 03:26 |
| nebajoth | and I know ezod irl | 03:26 |
| nebajoth | so naturally I've found my way here | 03:27 |
| nebajoth | I'm not 100% sold on TP yet | 03:27 |
| nebajoth | I tried minisec | 03:27 |
| llnz | cool | 03:27 |
| nebajoth | but it didn't make very much sense to me | 03:27 |
| nebajoth | I've talked to alanp a bit about what he's doing | 03:27 |
| nebajoth | and it sounds pretty rad | 03:27 |
| nebajoth | so I'm waiting for that to drop before I make any kind of call on it | 03:27 |
| *** mithro has joined #tp | 03:28 | |
| llnz | minisec is pretty simple | 03:28 |
| nebajoth | I didn't really know what to do | 03:28 |
| nebajoth | I stared at the starchart for a bit | 03:29 |
| nebajoth | picked out my system | 03:29 |
| nebajoth | the end | 03:29 |
| llnz | yeah, we need to make it easier to understand what to do | 03:29 |
| nebajoth | ezod has, well briefly anyway, outlined some of the wicked stuff that's under the hood | 03:30 |
| nebajoth | and I watched a google talk | 03:30 |
| nebajoth | 03:30 | |
| nebajoth | not talk | 03:30 |
| nebajoth | a talk on google video | 03:30 |
| nebajoth | but its not all that much fun as a game yet | 03:30 |
| nebajoth | and that's pretty necessary for me if I'm going to motivate a bunch of teenagers | 03:31 |
| *** reac has joined #tp | 03:31 | |
| llnz | there is the start of a video guide to help show the game play | 03:31 |
| nebajoth | can haz? | 03:32 |
| llnz | just a second | 03:33 |
| alanp | llnz, how can I "lock" a design to prevent it from being modified? | 03:34 |
| *** nebajoth has quit IRC | 03:38 | |
| *** nebajoth has joined #tp | 03:38 | |
| alanp | hmm | 03:41 |
| alanp | testing combat... sucks | 03:43 |
| nebajoth | :/ | 03:43 |
| llnz | nebajoth: http://www.thousandparsec.net/wiki/Video_Tutorials_for_wxPython_Client | 03:45 |
| tpb | <http://ln-s.net/1cN-> (at www.thousandparsec.net) | 03:45 |
| llnz | but can't find the video | 03:45 |
| mithro | nebajoth: a talk on google video? | 03:46 |
| nebajoth | yessss | 03:46 |
| llnz | alanp: there is at least two ways iirc | 03:47 |
| nebajoth | they're called something | 03:47 |
| nebajoth | but I forget what | 03:47 |
| nebajoth | google ______ | 03:47 |
| nebajoth | oh | 03:47 |
| llnz | google techtalk | 03:47 |
| nebajoth | google tech talks | 03:47 |
| nebajoth | yeah | 03:47 |
| nebajoth | that | 03:47 |
| mithro | nebajoth: Gaming for Freedom? | 03:47 |
| nebajoth | yes | 03:47 |
| nebajoth | that | 03:47 |
| mithro | ahh I gave that talk :) | 03:47 |
| nebajoth | good talk :) | 03:48 |
| nebajoth | totally interested me in the project | 03:48 |
| alanp | llnz: what ways are recommended? | 03:48 |
| mithro | there is also | 03:48 |
| nebajoth | Once you have an account on a server and you succesfully connect to that server, the client <dramatic voice>downloads the Universe</dramatic voice>. | 03:49 |
| nebajoth | hahaha | 03:49 |
| nebajoth | </dramatic voice> | 03:49 |
| nebajoth | TO BOLDLY CREATE | 03:49 |
| mithro | http://www.youtube.com/watch?v=H0LI8vFq_Es&feature=PlayList&p=86F8441377450354&index=0&playnext=1 | 03:49 |
| tpb | <http://ln-s.net/3o5P> (at www.youtube.com) | 03:49 |
| nebajoth | pretty | 03:50 |
| llnz | alanp: addUnderConstruction or maybe addComplete | 03:53 |
| alanp | ah | 03:53 |
| nebajoth | needs moar lazors | 03:56 |
| nebajoth | pew pew pew | 03:56 |
| nebajoth | is the UI done with wxpython? | 03:57 |
| alanp | faster speed = easier testing | 04:01 |
| alanp | woop | 04:01 |
| nebajoth | alanp | 04:03 |
| nebajoth | is there the concept of shields in MTSec? | 04:04 |
| alanp | there is a concept of armour | 04:04 |
| nebajoth | I saw that | 04:04 |
| alanp | no shields | 04:04 |
| nebajoth | so no | 04:04 |
| nebajoth | word | 04:04 |
| nebajoth | life support systems? | 04:04 |
| nebajoth | that'd be hella cool | 04:04 |
| nebajoth | I'm sure that's probably a later milepost | 04:06 |
| nebajoth | this IS missiles and torpedoes after all | 04:06 |
| alanp | is connecting 2 clinets on the same computer a known issue? | 04:07 |
| llnz | other than media, it should be ok | 04:10 |
| alanp | seems to break stuff | 04:11 |
| llnz | as long as you log in a two different players | 04:11 |
| alanp | nod | 04:11 |
| alanp | can't see anything moving | 04:11 |
| nebajoth | pew pew pew | 04:14 |
| *** tuna-fish has quit IRC | 04:15 | |
| nebajoth | ok | 04:15 |
| nebajoth | bed | 04:15 |
| *** nebajoth is now known as nebaway | 04:15 | |
| *** alanp_ has joined #tp | 04:24 | |
| alanp | Greywhind: oubg | 04:26 |
| alanp | Greywhind: ping | 04:26 |
| Greywhind | alanp: pong | 04:29 |
| alanp | Greywhind: the move lines don't show up in your client | 04:30 |
| Greywhind | alanp: yeah, i know. i'm going to see if i can fix that | 04:30 |
| mithro | Greywhind: ping? | 04:31 |
| Greywhind | mithro: pong | 04:31 |
| mithro | Greywhind: so - I'm looking at your two patches | 04:31 |
| alanp | ah, cool | 04:31 |
| Greywhind | mithro: yeah | 04:31 |
| mithro | and I don't think it's the right method | 04:32 |
| Greywhind | mithro: i couldn't seem to figure out other methods that would work. what would you recommend? | 04:32 |
| mithro | Greywhind: why not? | 04:32 |
| Greywhind | mithro: probably related to my incomplete knowledge of the network/libtpproto-py side of the system. | 04:33 |
| mithro | Greywhind: I can think of multiple methods | 04:33 |
| mithro | a) fix __deepcopy__ | 04:33 |
| Greywhind | mithro: well, i tried to use __deepcopy__, but it didn't seem to return the type of object that the client wanted | 04:34 |
| mithro | b) use a method which is similar to the order creation | 04:34 |
| Greywhind | mithro: i thought my current method was similar to the order creation? | 04:34 |
| mithro | I think you need to dig a bit deeper | 04:34 |
| mithro | Greywhind: no | 04:34 |
| mithro | Greywhind: as .args is not updated as values change | 04:35 |
| mithro | you can build args easy enough however | 04:35 |
| Greywhind | mithro: what can i build them from? | 04:36 |
| mithro | from the arguments | 04:36 |
| mithro | s/arguments/properties | 04:36 |
| mithro | the pack method does something similar | 04:36 |
| Greywhind | mithro: hm. i see. but i couldn't just use the pack method, i assume? | 04:37 |
| mithro | you can pack do a pack/unpack | 04:37 |
| mithro | you can do a pack/unpack cycle | 04:38 |
| mithro | you could store seralized objects in the copy/paste buffer | 04:39 |
| Greywhind | mithro: what are the values i need to pass to pack? | 04:39 |
| mithro | Greywhind: oh you can use __str__ to serialize | 04:42 |
| Greywhind | mithro: i'm kind of lost here | 04:42 |
| Greywhind | mithro: what do i need to serialize? | 04:42 |
| mithro | the objects | 04:42 |
| mithro | think about logically what you are doing | 04:42 |
| mithro | s/objects/orders/ | 04:42 |
| Greywhind | mithro: aren't we talking about orders? | 04:42 |
| Greywhind | mithro: oh. | 04:43 |
| Greywhind | mithro: well, the theory is this: copy stores the current selected order(s) in a buffer. paste then goes through and takes each order, making a new order that's an exact duplicate of it and placing it in the queue after asking for its creation on the server. | 04:44 |
| mithro | what operations does copy/paste need to occur? | 04:44 |
| Greywhind | mithro: is that right? | 04:44 |
| mithro | Greywhind: not quite | 04:44 |
| alanp | "can't compare datetime.datetime to int" | 04:44 |
| alanp | ugh oh | 04:44 |
| mithro | you need two copies | 04:45 |
| alanp | maybe i should use the same client on both | 04:45 |
| mithro | think about what happens when properties change | 04:47 |
| Greywhind | mithro: well, the panel is updated with the new values, yes? then when the "save" button is pressed, the order is synced with the values? | 04:48 |
| alanp | mithro: http://pastebin.com/m62da999f <-make sense to you? | 04:50 |
| tpb | Title: pastebin - collaborative debugging tool (at pastebin.com) | 04:50 |
| mithro | so what happens to the copied the orders at that time? | 04:50 |
| Greywhind | mithro: well, if an order is modified after it's already been copied, the copy will not be updated. this should be the functionality we want though, yes? | 04:52 |
| mithro | alanp: try removing your ~/.tp/cache file | 04:52 |
| alanp | i did.... | 04:52 |
| alanp | :( | 04:52 |
| mithro | alanp: hrm... | 04:52 |
| Greywhind | mithro: for instance, if you copy a bit of text in a text editor and change the text later, your copied text will not automatically get the new changes | 04:53 |
| mithro | yes | 04:54 |
| mithro | so with your first theory that doesn't occur | 04:56 |
| mithro | Greywhind: and how does that interact with the StateTracker stuff? | 04:58 |
| Greywhind | it does not occur that the copy changes, or it does not occur as we want it to and the copy does change? | 04:58 |
| alanp | whenever I build a fleet from a new design, I get the cannot compare datetime.datetime to int | 04:58 |
| alanp | I didn't get that before :( | 04:59 |
| Greywhind | mithro: well, StateTracker tracks by queue, so if a new order is added to a queue, StateTracker should be fine with that | 05:01 |
| mithro | Greywhind: so we need to do a copy from the queue into buffer | 05:01 |
| * alanp going to work around the datetime error for the time being | 05:02 | |
| mithro | Greywhind: and then we copy from the buffer into queue | 05:02 |
| Greywhind | mithro: is that not what self.clipboard is? | 05:02 |
| mithro | Greywhind: self.clipboard == queue | 05:03 |
| Greywhind | mithro: oh, does the clipboard not already actually copy the order, just refer to it? | 05:04 |
| mithro | Greywhind: I don't know | 05:04 |
| mithro | Greywhind: but it should copy it | 05:04 |
| mithro | it's copy in and copy out | 05:05 |
| Greywhind | mithro: yeah. so if it does, then it should already be a separate entity, which i can then duplicate into a new order, yes? | 05:05 |
| *** alanp_ has quit IRC | 05:05 | |
| mithro | kinda | 05:06 |
| *** alanp_ has joined #tp | 05:07 | |
| Greywhind | mithro: so... is there a way to keep the args updated after the order is created, from inside the order class? | 05:09 |
| mithro | Greywhind: sure - but that seems to be a crappy thing to do as it's going to be hard to get right | 05:09 |
| Greywhind | mithro: but i still don't know how i could re-generate them from outside the order class, without saving the whole panel that created the order and without doing a lot of special code to generate the arguments from the order's properties? | 05:11 |
| Greywhind | does pack/unpack do that for me? | 05:11 |
| mithro | Greywhind: well - what do you think? | 05:11 |
| Greywhind | mithro: i don't really know what pack/unpack do anymore - it's been weeks since i looked at them | 05:11 |
| mithro | Greywhind: well it might be worth re-looking into them | 05:13 |
| Greywhind | mithro: they don't have any explanation :P | 05:13 |
| mithro | Try fromstr and __str__ | 05:14 |
| Greywhind | mithro: hm. ok.. i might see what you're getting at. i'll look into it more tomorrow. | 05:16 |
| mithro | so I think if you serialize into the buffer and then unserialize out | 05:17 |
| Greywhind | mithro: yeah, it might work, if these do what i think they do | 05:18 |
| mithro | want to look at StateTracker stuff too | 05:18 |
| Greywhind | k | 05:19 |
| Greywhind | i need to sleep | 05:19 |
| Greywhind | but i'll try to do this tomorrow | 05:19 |
| alanp | ugh | 05:22 |
| * alanp having terrible problems relating tubes to missiles | 05:22 | |
| alanp | eek | 05:23 |
| alanp | maybe i have it | 05:23 |
| *** Greywhind has quit IRC | 05:29 | |
| alanp | hrm | 06:29 |
| * alanp having unfortunate problem reading a property of a design | 06:29 | |
| alanp | 0x00000000004bbe9c in std::_Rb_tree<unsigned int, std::pair<unsigned int const, PropertyValue>, std::_Select1st<std::pair<unsigned int const, PropertyValue> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, PropertyValue> > >::_M_begin (this=0x68) at /usr/include/c++/4.3/bits/stl_tree.h:459 | 06:29 |
| *** alanp_ has quit IRC | 06:32 | |
| alanp | d'og | 06:34 |
| alanp | d'oh | 06:34 |
| *** alanp_ has joined #tp | 06:35 | |
| alanp | why do properties hate me :( | 06:40 |
| alanp | i get the right property ID, there is a value associated in the design | 06:41 |
| alanp | when i try to read the value, CRASH | 06:41 |
| alanp | hm | 06:43 |
| *** alanp__ has joined #tp | 06:44 | |
| alanp | d'oh | 06:45 |
| alanp | stupid laptop picking up wireless | 06:45 |
| *** jernejovc_ has joined #tp | 06:46 | |
| *** alanp_ has quit IRC | 06:46 | |
| *** alanp_ has joined #tp | 06:49 | |
| CIA-26 | alanp tpserver-cpp-mtsec * r8cd2201facca /modules/games/mtsec/ (5 files): | 06:59 |
| CIA-26 | - Initial Combat, no damage is done but tubes and missiles are adhered to, torpedoes and damage next | 06:59 |
| CIA-26 | - Changed the size of the universe, decreased it by a lot. | 06:59 |
| CIA-26 | - Updated Properties, added new ones for each type of tube to match missiles to tubes mainly | 06:59 |
| *** jernejovc has quit IRC | 06:59 | |
| *** alanp__ has quit IRC | 07:02 | |
| *** jernejovc_ has quit IRC | 07:05 | |
| * llnz wanders off | 07:40 | |
| llnz | later all | 07:40 |
| *** llnz has quit IRC | 07:40 | |
| *** jernejovc has joined #tp | 07:44 | |
| *** peres has joined #tp | 08:11 | |
| *** alanp_ has quit IRC | 08:20 | |
| *** peres has quit IRC | 08:49 | |
| *** tuna-fish has joined #tp | 09:06 | |
| *** jmtan has joined #tp | 09:15 | |
| *** reac has quit IRC | 10:06 | |
| *** jmtan1 has joined #tp | 11:23 | |
| *** jmtan has quit IRC | 11:23 | |
| *** Greywhind has joined #tp | 12:29 | |
| *** verhoevenv has joined #tp | 13:11 | |
| *** verhoevenv has quit IRC | 13:55 | |
| *** nebaway is now known as nebajoth | 14:00 | |
| *** verhoevenv has joined #tp | 14:08 | |
| *** nebajoth is now known as nebaway | 14:24 | |
| *** nebaway is now known as nebajoth | 14:28 | |
| *** nebajoth is now known as nebaway | 14:31 | |
| CIA-26 | epyon tpserver-cpp-refactor * r24cedab59b63 /tpserver/objectbehaviour.h: Typedef for ObjectBehaviour shared_ptr (need to rethink it thou...) | 16:14 |
| CIA-26 | epyon tpserver-cpp-refactor * rcb7fb1a069ee /tpserver/objectbehaviour.h: Include fix | 16:14 |
| CIA-26 | epyon tpserver-cpp-refactor * rf46c2043fb55 / (7 files in 4 dirs): FrameException updated to a more useful format | 16:14 |
| epyon | Geesh, when I started this project I never imagined how much work was before me -_- | 16:14 |
| *** llnz has joined #tp | 16:15 | |
| llnz | morning all | 16:22 |
| alanp | morning | 16:22 |
| llnz | hi alanp | 16:22 |
| alanp | hey | 16:22 |
| *** jnengland77 has joined #tp | 16:25 | |
| CIA-26 | epyon tpserver-cpp-refactor * r439df57fa574 /tpserver/tcpconnection.cpp: TcpConnection now catches FrameExceptions as a last resort | 16:43 |
| CIA-26 | epyon tpserver-cpp-refactor * rf6dfd5f924f9 /tpserver/playerconnection.cpp: PlayerConnection now catches FrameExceptions and sends them as fail | 16:43 |
| CIA-26 | epyon tpserver-cpp-refactor * rd304c12e4d0e /tpserver/playerconnection.cpp: Include fix | 16:43 |
| CIA-26 | epyon tpserver-cpp-refactor * r3948d00883da /tpserver/ (adminconnection.cpp playerconnection.cpp): AdminConnection now catches frane exceptions also | 16:43 |
| llnz | epyon: i noted you removed objectrelationships yesterday (or the day before) | 16:44 |
| *** reac has joined #tp | 16:46 | |
| epyon | llnz: yes | 16:46 |
| epyon | interface of object was doubling the interface of objectrelationship | 16:47 |
| epyon | and objectrelationship was only used internally by object | 16:47 |
| llnz | isn't that going to limit how rulesets can provide alternative views to players of an object | 16:47 |
| llnz | ? | 16:47 |
| epyon | How can they, if objectrelationship was private? | 16:48 |
| epyon | Aaah, you mean the functionality | 16:48 |
| epyon | the functionality as it was is untouched | 16:48 |
| epyon | the children IdSet was moved into object | 16:48 |
| CIA-26 | epyon tpserver-cpp-refactor * r46fe8f313e7f /tpserver/adminconnection.cpp: Second instance of admin connection read also packed in try..catch for FrameExceptions | 17:00 |
| CIA-26 | epyon tpserver-cpp-refactor * r915de8e6664c /tpserver/adminconnection.cpp: AdminConnection now uses FrameException throws instead of multiple sendFail's | 17:00 |
| CIA-26 | epyon tpserver-cpp-refactor * rc4ed13950404 /tpserver/playerconnection.cpp: Second instance of player connection read also packed in try..catch for FrameExceptions | 17:00 |
| CIA-26 | epyon tpserver-cpp-refactor * r08090f7466bb /tpserver/playerconnection.cpp: PlayerConnection now uses FrameException throws instead of multiple sendFail's | 17:00 |
| alanp | wow | 17:08 |
| alanp | llnz: hey | 17:09 |
| llnz | alanp: hi | 17:09 |
| alanp | llnz: for the scheme, how can i make it so that no matter how many components of X you add, the value is 3? | 17:09 |
| alanp | IE: I add 14 component Y, I want property to be 3 | 17:09 |
| llnz | epyon: FrameException constructor needs to take a list of generic references (refsys references) | 17:09 |
| alanp | it should always be "3" | 17:09 |
| * alanp very close | 17:09 | |
| llnz | alanp: umm... | 17:10 |
| alanp | my scheme, is terrible | 17:10 |
| llnz | something like this in the property calc func: | 17:10 |
| alanp | ohhhh | 17:10 |
| alanp | I could have probably figured this out, but I'm guessing it would have taken a while | 17:11 |
| llnz | lamdba ((design list) ( cons 3 'Type of value three')) | 17:12 |
| alanp | well, I don't actually want it to be "3", just the value assigned to it | 17:12 |
| alanp | which happens to be 3 | 17:12 |
| alanp | <tpclDisplayFunction><![CDATA[(lambda (design bits) (let ((n (apply + bits))) (cons n (number->string n))))]]></tpclDisplayFunction> | 17:12 |
| alanp | ? | 17:12 |
| alanp | no, that will add it | 17:12 |
| alanp | er no? | 17:12 |
| alanp | hm | 17:12 |
| llnz | hold on, what are you trying to do? | 17:13 |
| alanp | I have a component that has a property "X" with a property that has a value "Y", When I add components I don't want to add to Y, I want to keep Y | 17:14 |
| alanp | alpha missile tube has missilesize 3 | 17:14 |
| alanp | i don't want missilesize to increase to 6 when I add 2 tubes | 17:14 |
| alanp | I want it to be 3 always | 17:14 |
| llnz | but what happens if you have a component that has a different missilesize? | 17:14 |
| alanp | yeah, i was just going to say that | 17:15 |
| alanp | I guess I'll just use the properties for each one | 17:15 |
| llnz | the 'bits' list could end up as [3 3 3 4] | 17:15 |
| llnz | for three alpha tubes and a beta tube | 17:15 |
| alanp | yeah exactly | 17:15 |
| alanp | i guess what i could do then is have a property AlphaMissileSize and a property NumAlphaMissiles? | 17:16 |
| alanp | luckily, this wont be hard for me to change | 17:16 |
| llnz | NumAlphaTubes? | 17:17 |
| alanp | i will need some way to keep track of how many tubes are in a design | 17:17 |
| alanp | I need to keep track of 1) number of each tube 2) size of each tube | 17:19 |
| alanp | this should be done in the properties, no? | 17:19 |
| llnz | it could be | 17:30 |
| llnz | the size of each tube type is fixed, correct? | 17:30 |
| alanp | yes, it is | 17:33 |
| alanp | but we can have multiple of each tubes | 17:33 |
| alanp | 4 alpha, 10 gamma or something | 17:33 |
| alanp | Wouldn't I need a property to track the number of each one? | 17:33 |
| llnz | yes, but i don't think you need the size of each tube type | 17:36 |
| alanp | well I was going to do this | 17:37 |
| alanp | I have a property name for each property, that was set to 1 | 17:37 |
| alanp | i just set it to the size of the weapon | 17:37 |
| alanp | I need that one, and it was only checking for >0.0 before, so it should be fine that way | 17:37 |
| CIA-26 | epyon tpserver-cpp-refactor * r10a75d556e5c /tpserver/ (playeragent.cpp playeragent.h): PlayerAgent checks now throw instead of returning false | 17:51 |
| CIA-26 | epyon tpserver-cpp-refactor * re1d5f48746ed /tpserver/playeragent.cpp: PlayerAgent throws FrameExceptions instead of doing sendFail's | 17:51 |
| *** Vadtec has quit IRC | 18:17 | |
| *** Vadtec_ has quit IRC | 18:17 | |
| *** edison has quit IRC | 18:17 | |
| *** edison has joined #tp | 18:18 | |
| *** Vadtec_ has joined #tp | 18:18 | |
| *** Vadtec has joined #tp | 18:18 | |
| *** Vadtec_ has quit IRC | 18:38 | |
| *** Vadtec_ has joined #tp | 18:39 | |
| *** Vadtec_ has quit IRC | 18:45 | |
| *** Vadtec_ has joined #tp | 18:46 | |
| *** Vadtec_ has quit IRC | 18:50 | |
| *** Vadtec_ has joined #tp | 18:53 | |
| *** alanp has quit IRC | 19:08 | |
| *** alanp has joined #tp | 19:09 | |
| CIA-26 | alanp tpserver-cpp-mtsec * r5452ee479d05 /modules/games/mtsec/ (avacombat.cpp tpserver-cpp-mtsec-gamedata.xml): | 19:33 |
| CIA-26 | - This version finds the tubes available better | 19:33 |
| CIA-26 | - Added a couple properties | 19:33 |
| *** nash has joined #tp | 19:34 | |
| alanp | womp womp | 19:37 |
| *** shenki has quit IRC | 19:50 | |
| *** shenki_ has joined #tp | 19:50 | |
| *** shenki has joined #tp | 19:59 | |
| *** shenki_ has quit IRC | 19:59 | |
| *** nebaway is now known as nebajoth | 20:10 | |
| *** mithro has quit IRC | 20:13 | |
| tansell | morning people | 20:16 |
| *** nebajoth is now known as nebaway | 21:08 | |
| *** shenki has quit IRC | 21:17 | |
| *** mithro has joined #tp | 21:36 | |
| *** verhoevenv has quit IRC | 22:11 | |
| *** shenki has joined #tp | 22:43 | |
| *** cherez has quit IRC | 23:44 | |
| *** cherez has joined #tp | 23:56 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!