Dev Meeting Log 20120429

Below is the log of our developer IRC chat on Saturday night/Sunday morning.

Summary

• Facet status / restructure / key principles of the design
• Future of PCG creation/parsing (Tom)

Actions

• Schedule new meeting Tom/James)

Transcript

(8:03:04 AM) [Arch_SB]thpr: ok
(8:03:36 AM) [Arch_SB]thpr: I think the last meeting covered the new UI items pretty well, so we'll go on to some other things this time
(8:04:28 AM) [Arch_SB]thpr: The two that were left over from the last meeting were:
(8:04:34 AM) [Arch_SB]thpr: - Facet status / restructure / key principles of the design
(8:04:39 AM) [Arch_SB]thpr: - Future of PCG creation/parsing (Tom)

Facet status / restructure / key principles of the design

(8:05:33 AM) [Arch_SB]thpr: The first one of those had an email on list a while back... can't quickly find a link for it
(8:06:08 AM) [Arch_SB]thpr: Here we go: http://tech.groups.yahoo.com/group/pcgen_developers/message/2190
(8:06:31 AM) [Arch_SB]thpr: Actually, this is the clarified one: http://tech.groups.yahoo.com/group/pcgen_developers/message/2218
(8:07:47 AM) [Arch_SB]thpr: The main goal is to break out the facets into groups so we can organize them better, keep them doing one thing, and even if possible share some testing or code
(8:08:44 AM) [Arch_SB]thpr: It will also provide a framework for a few facets that do multiple things and therefore should be broken up
(8:09:12 AM) [Arch_SB]thpr: did folks read that thread, so I don't need to dig into detail, or should I run through it a bit to describe it?
(8:09:53 AM) cpmeister____: the link refreshes my memory
(8:10:57 AM) [Arch_SB]thpr: ok, perhaps we will go with that thread for now unless there are any questions?
(8:11:04 AM) [Arch_SB]thpr: and to note, I haven't had a chance to make the changes yet, so things are still in the old (flat) structure at this point...
(8:11:19 AM) James[Code_SB]: Just one quesion from me
(8:11:41 AM) James[Code_SB]: Is the aim to allow other parts of the code to interact with the facets, particularly to listen for events?
(8:12:28 AM) [Arch_SB]thpr: Yes and no :)
(8:12:37 AM) [Arch_SB]thpr: I think that some facets should definitely not be exposed
(8:13:10 AM) [Arch_SB]thpr: Since they are performing pure core functions. Things like the link or filters that are taking out things the PC isn't qualified for, etc.
(8:13:22 AM) James[Code_SB]: yep
(8:13:43 AM) [Arch_SB]thpr: But specifically to the Display Facets, since those would have, for example, a sorted list of Languages, I don't see why we wouldn't declare that the public interface of the core
(8:14:18 AM) [Arch_SB]thpr: The two things in that category are probably DisplayFacets and FactFacets
(8:14:49 AM) [Arch_SB]thpr: ...and obviously the input facets are the "write" portion of the interface of the core
(8:15:45 AM) [Arch_SB]thpr: Now having said that, I am open to whether these are actually things people can directly call, or whether there is a class somewhere that consolidates this stuff into one place to keep it clean and to insulate the actual underlying facets (even if the class is just doing delegation under the covers)
(8:16:23 AM) [Arch_SB]thpr: The latter continues to give us something like "Player Character" today - which has the risk of being large, but also the benefit of being one thing
(8:16:46 AM) [Arch_SB]thpr: I want to get the core to the place where it recognizes the PlayerCharacter as only a CharID, but if
(8:16:57 AM) [Arch_SB]thpr: ...but if other things need the unified class, that's ok too
(8:17:37 AM) [Arch_SB]thpr: A future concern will exist with the unified class (restricting flexibility) if/when we get outside D20-like systems, but that's a much longer term discussion
(8:17:49 AM) [Arch_SB]thpr: Shouldn't impact things right now
(8:17:57 AM) [Arch_SB]thpr: make sense
(8:17:59 AM) [Arch_SB]thpr: ?
(8:18:14 AM) [Arch_SB]thpr: (and any thoughts on whether we want to keep a consolidation point?)
(8:18:28 AM) James[Code_SB]: afk sorry
(8:19:37 AM) cpmeister____: I believe that we discussed a having the facade implementations filed down to using the facets directly
(8:19:43 AM) ThunderChicken: You're basically talking about a Facade pattern, yes?
(8:20:00 AM) [Arch_SB]thpr: Yes, a facade is one option
(8:20:14 AM) [Arch_SB]thpr: (the consolidated point I'm describing)
(8:20:31 AM) [Arch_SB]thpr: Connor, there are tradeoffs here that I'm not sure we went through... so to put them on the table...
(8:21:07 AM) [Arch_SB]thpr: Option A would be the exsiting Facades reach directly to the facets, which gives a direct link and avoids lots of intermediate stuff
(8:21:44 AM) [Arch_SB]thpr: Hmm, need to modify that
(8:22:03 AM) [Arch_SB]thpr: ...or not. hmm
(8:22:21 AM) [Arch_SB]thpr: Let me at least spell some things out, may have to redo after I get done
(8:22:47 AM) [Arch_SB]thpr: Option B is that the existing Facades reach to a single consolidation point (like they do with PlayerCharacter today).
(8:23:13 AM) [Arch_SB]thpr: The reasoning behind Option B would be that the two facades actually perform different functions
(8:23:41 AM) [Arch_SB]thpr: The current facades in the UI are abstracting away the underlying classes, so you no longer know you are dealing with a Language (since you use LanguageFacade, etc)
(8:24:17 AM) [Arch_SB]thpr: The PlayerCharacter consolidation is a facade acting as a consolidation point to hide that the thing someone may be listening to is a facet and specifically what facet
(8:24:48 AM) [Arch_SB]thpr: but it would still deal purely with Language, Race, etc., not the Facade objects of the UI
(8:25:44 AM) James[Code_SB]: back now
(8:26:24 AM) [Arch_SB]thpr: There are some variations of Option A that would be possible to make the UI more or less aware of the underlying classes, and/or the core more or less aware of the Facades (e.g. right now some of the base classes implement BlahFacade, and that could be changed)
(8:26:42 AM) [Arch_SB]thpr: that make sense Connor?
(8:26:48 AM) [Arch_SB]thpr: (of the two different options?)
(8:26:49 AM) cpmeister____: makes sense
(8:27:26 AM) cpmeister____: the idea behind option A was to unify the facet and facade event systems
(8:27:38 AM) [Arch_SB]thpr: Right now we're much closer to Option B (since that is effectively PlayerCharacter.java) so that really is the starting point, but it can be changed over time
(8:27:52 AM) [Arch_SB]thpr: Agree that's a good idea
(8:28:05 AM) [Arch_SB]thpr: I guess my ideal would be something like this:
(8:28:28 AM) [Arch_SB]thpr: Core Facets can be redesigned without external systems knowing the internal event structure or flow, that's not a public API
(8:28:51 AM) [Arch_SB]thpr: There are a set of informational facets (FactFacets and DisplayFacets) that form an external API
(8:29:03 AM) [Arch_SB]thpr: The UI facade leverages the external API of the core to share events
(8:29:45 AM) [Arch_SB]thpr: The UI facade also has a consistent method of converting from internal structure to external (right now there are a few casts and a few lookups, and I think we should try to get consistent over time - probably not possible right now due to some of the cloning)
(8:30:26 AM) [Arch_SB]thpr: Basically on this last item, I'd prefer we don't cast (e.g. don't do Language l = (Language) langFacade;)
(8:30:53 AM) [Arch_SB]thpr: ( I think that encourages bad behavior in the long term if folks think they can just cast and have the core object)
(8:31:35 AM) [Arch_SB]thpr: Actually.... let's talk about how we get information for display for a moment
(8:31:40 AM) cpmeister____: I agree that casting is bad :), but I don't think it poses much of a problem when the only instances of LanguageFacade SHOULD be Language
(8:32:17 AM) [Arch_SB]thpr: So this is going to hark back to a way old Code team discussion we had on redoing the output system
(8:32:48 AM) [Arch_SB]thpr: because while it may be a bit "out there" it may also provide another way of thinking about getting information from the core that we can consider and/or use for ideas
(8:33:14 AM) [Arch_SB]thpr: I'm sorry I don't have that discussion at my fingertips, perhaps Drew - can you see if you can find the link for it?
(8:33:32 AM) AndrewAAM: Is this in an old dev mailing list?
(8:33:48 AM) [Arch_SB]thpr: no, it will be on _Dev on yahoo, but will be maybe a year old
(8:33:53 AM) AndrewAAM: ok
(8:34:51 AM) [Arch_SB]thpr: So let's use Languages for a moment
(8:35:09 AM) [Arch_SB]thpr: Assume the core has produced the list of languages that a PC has (knows, not available in this case)
(8:35:36 AM) [Arch_SB]thpr: It's possible we have another facet which is sorting that list so it can be displayed in the appropriate order
(8:35:57 AM) [Arch_SB]thpr: Theoretically, the output token LANGUAGE.X.NAME would want to draw upon that same list (in the same order)
(8:37:11 AM) [Arch_SB]thpr: Now with that proposal, the "LANGUAGE" would be a list, the X (which is really a number typically replaced by a FOR loop in the output sheets) is a filter [if I remember my terms] and NAME is a ... reducer (I'll have to correct these later if I'm mixing terms)
(8:38:42 AM) [Arch_SB]thpr: One other comment... in the core, we've been pretty good about separating the ability to store information from any specific structure. So the real work is done in the input tokens, and it's pretty flexible (we don't have setHands(x) we have setInteger(IntegerKey.HANDS, x))
(8:38:55 AM) [Arch_SB]thpr: That gives us - theoretically - the ability to add information without changing the core
(8:39:39 AM) [Arch_SB]thpr: So I'd assert we want the same for output tokens. So there may be an opportunity here for shared behavior between the output tokens and the UI
(8:39:57 AM) [Arch_SB]thpr: There are multiple ways to implement - let me toss out one way (honestly not sure this is best, but bear with me)
(8:40:55 AM) [Arch_SB]thpr: For the output sheet, the "LANGUAGE" would be passed to an API, with a method call of something like getList("LANGUAGE")
(8:41:12 AM) [Arch_SB]thpr: There is no reason why that same API couldn't be used by the UI to say subscribeToList("LANGUAGE")
(8:41:19 AM) [Arch_SB]thpr: (give or take we may not use strings, etc. etc.)
(8:41:40 AM) [Arch_SB]thpr: ...or taking that a bit further....
(8:42:04 AM) [Arch_SB]thpr: The displayfacet that does the sorting actually is part of the output system (Since core really shouldn't care about sorting).
(8:42:22 AM) [Arch_SB]thpr: So the UI actually would be able to subscribe to the output system and leverage what would be the LANGUAGE output token
(8:42:43 AM) [Arch_SB]thpr: In that way the UI would always be guaranteed to be consistent with the output tokens
(8:43:33 AM) [Arch_SB]thpr: Why does this matter for this discussion? Because the API I referred to a few lines ago might be that consolidation point from Option B
(8:44:09 AM) [Arch_SB]thpr: Hmm. not sure that's good enough of a description - do people get the idea?
(8:45:35 AM) cpmeister____: sounds reasonable to me
(8:45:36 AM) [Arch_SB]thpr: And by the way, here is the output token conversation: http://tech.groups.yahoo.com/group/pcgen_developers/message/484 (from Nov 13, 2009)
(8:46:17 AM) [Arch_SB]thpr: It might not make a lot of sense right now because it's a bit of "we have to chagne N things to get there", but it's at least a good thing to consider
(8:46:17 AM) James[Code_SB]: Yes that sounds good to me also - my main concern is to get the UI facade layer more event driven
(8:46:30 AM) James[Code_SB]: and less scan after update than it is currently
(8:46:44 AM) [Arch_SB]thpr: Yea, this will be a process to get there, so we may want to attach it to the core for now and can undo that later
(8:47:11 AM) [Arch_SB]thpr: (Since I don't think we'll be doign much in the output tokens soon)
(8:47:25 AM) James[Code_SB]: I suspect it will be a post 6.0 thing at this stage, even for the UI
(8:47:37 AM) [Arch_SB]thpr: Just wanted to put that out there since I think it's relevant to what subsystem owns what code longer term
(8:48:11 AM) James[Code_SB]: For sure
(8:48:12 AM) [Arch_SB]thpr: ok... I think we spent more time on that than I expected :)
(8:48:20 AM) [Arch_SB]thpr: Any other questions or comments?
(8:48:27 AM) cpmeister____: none here
(8:48:36 AM) James[Code_SB]: It's an important step though so it is good to have it out there
(8:49:43 AM) [Arch_SB]thpr: Not sure if we intend to do 1 hr or 2, but I at least want to introduce the other topic, and that is how we persist the Player Character
(8:49:53 AM) James[Code_SB]: sure
(8:50:03 AM) cpmeister____: I can stay for 2 hr

Future of PCG creation/parsing

(8:50:25 AM) [Arch_SB]thpr: Right now the focus is a bit less on literal structure (it's tokens right now, may do something else someday) and more on where it is in the code
(8:50:46 AM) [Arch_SB]thpr: The current system uses one monolithic class for reading, and one for writing
(8:51:09 AM) [Arch_SB]thpr: Other than not being a fan of monolithinc systems, this causes another issue
(8:51:24 AM) [Arch_SB]thpr: it somtimes forces the facets to expose information they would otherwise want to keep private
(8:51:52 AM) [Arch_SB]thpr: So they effectively end up being beans (somewhat counter to the keep things private philosophy of OO programming)
(8:52:14 AM) [Arch_SB]thpr: So let me throw out a few different structures we might use going forward to get some initial feedback
(8:52:35 AM) [Arch_SB]thpr: Let's call Option 1 what we have now, which is single file to write, single file to read the PCG file
(8:53:12 AM) [Arch_SB]thpr: Option 2 would be to transfer ownership of persistence to the facets themselves (in this case it would be the facets that actually store information, so the model facets and fact facets)
(8:53:54 AM) [Arch_SB]thpr: For option 2, that means the facet would read/write whatever information it had about the PC using some method. A form of serialization if you will, though we wouldn't literally use Java's binary serialization because we want to keep the format human readable
(8:54:40 AM) [Arch_SB]thpr: Option 3 would be to have separate classes, one for each "thingy" (either facet, or consolidated to "all ability information", etc - scope to be defined) and have those separate classes responsible for I/O.
(8:55:19 AM) [Arch_SB]thpr: This doesn't solve the private information issue, but this is commonly used in many systems. It also is accused in some cases of causing class sprawl :)
(8:56:14 AM) James[Code_SB]: Presumably you;d split that so the facet is respionsible for encoding/decoding the persistence info but theere would be an IO class which controlled the persistence and marchalled the data
(8:56:59 AM) [Arch_SB]thpr: Yes, something would have to do a loop through all the facets to query them for example, and that presumably would have created the OutputStream, etc.
(8:57:37 AM) James[Code_SB]: Should we keep the output stream away from the facets - have them handle strings maybe?
(8:58:22 AM) [Arch_SB]thpr: If it were plain text, yes, I'd prefer to hand in/out Strings.
(8:58:38 AM) [Arch_SB]thpr: But if we go to something like XML, we'd probably want to hand in/out Elements
(8:59:18 AM) cpmeister____: so if we want flexibility in our IO the IO would be a separate system from the facets
(8:59:25 AM) James[Code_SB]: true, my main concern would be to keep the messiness of IO out of the facets
(8:59:45 AM) [Arch_SB]thpr: yes, there are tradeoffs here. One of them is purity probably says the facets shouldn't do IO
(9:00:05 AM) [Arch_SB]thpr: The counter to that is that we have produced a LOT of bugs over the years because we've added a core capability without forcing it into the PCG file
(9:00:32 AM) [Arch_SB]thpr: So by having those as methods on the facets, when you created a facet that stored cache information, we could check that you also know how to read/write that info
(9:01:24 AM) [Arch_SB]thpr: @James, agree, the facets should be as separated as possible and not having to deal with IO exceptions, et al
(9:01:33 AM) cpmeister____: agreed
(9:01:54 AM) James[Code_SB]: I think haveing the persistence closely linked to facets makes sense
(9:02:03 AM) cpmeister____: I don't see why an IO system would need to have access to the facets in order to work though
(9:02:04 AM) [Arch_SB]thpr: And ensure that the system is reusable - an OutputStream makes assumptions that you're serializing it for output, when you may be serializing it to send it over the Internet to your GM running GMGen (future type thinking)
(9:02:33 AM) cpmeister____: the facets are already linked through a single object
(9:02:41 AM) [Arch_SB]thpr: The facets are the information store of the PlayerCharacter (things aren't stored in PlayerCharacter.java)
(9:03:02 AM) [Arch_SB]thpr: BUT... Option A from teh first discussion would destroy that consolidation point
(9:03:02 AM) cpmeister____: the PlayerCharacter is still the hub of information access
(9:03:16 AM) [Arch_SB]thpr: What if there was no PlayerCharacter?
(9:03:55 AM) [Arch_SB]thpr: One logical conclusion of having the core facets have a fixed API for input and display is that PlayerCharacter is ... redundant... and removable
(9:04:22 AM) [Arch_SB]thpr: (Again, not the only way, just pushing on it to make folks think about it)
(9:04:44 AM) James[Code_SB]: An option is a system which loops through facets asking them for their persistence info, and then storing that. You add a new facet and it should be added into the persistence structure without hand coding of the IO
(9:05:03 AM) cpmeister____: so we want to make the facets and IO closely linked in order to remain flexible between option A and B?
(9:05:28 AM) [Arch_SB]thpr: @Connor not necessarily, I'm just ensuring we think through all the tradeoffs
(9:06:17 AM) [Arch_SB]thpr: @James: Yea, the trick is in how to do that. The unit test system today has some ability to iterate across all facets that persist information in order to check PlayerCharacterA =?= PlayerCharacterB
(9:06:50 AM) [Arch_SB]thpr: The trick with persistence is that the information in the data store is not always simple. Sometimes it's just a number or String, but sometimes it's a customized data structure (private class) to the facet
(9:07:30 AM) [Arch_SB]thpr: So that facet would have to do something in the way of "serialization" and "deserialization" since you can't go to the cache and assume you can write what you find
(9:08:47 AM) [Arch_SB]thpr: hmm, that brings up an interesting point
(9:09:07 AM) [Arch_SB]thpr: One option would be that anything stored in the cache has to implement a "I can be written" interface
(9:09:51 AM) cpmeister____: we are dealing with two related issues in persistence.
(9:10:00 AM) cpmeister____: 1. what needs to be written
(9:10:01 AM) [Arch_SB]thpr: ...but then we have to know which facet wrote it, so we have to avoid writing the facet names... have to think through that
(9:10:11 AM) cpmeister____: 2. how it should be written
(9:10:39 AM) [Arch_SB]thpr: 3. Who wrote it and/or how to restore it
(9:11:17 AM) [Arch_SB]thpr: and I'd expand (1) to be "what needs to be written and ensuring everything gets written"
(9:12:05 AM) James[Code_SB]: Just a side suggestion - could the cache be made to persist itself, rather than having the code in the facets?
(9:12:27 AM) cpmeister____: ah, thats an interesting thought
(9:12:30 AM) [Arch_SB]thpr: @James, that's where I was just headed in the "anything stored in the cache has to implement a "I can be written" interface"
(9:13:32 AM) James[Code_SB]: Well, if you had two sides to the cache - persistable and transient, and then the facet could specify which to use
(9:14:07 AM) [Arch_SB]thpr: @James exactly on the two sides
(9:14:17 AM) [Arch_SB]thpr: The persistent side would have to be readable/writeable
(9:14:34 AM) [Arch_SB]thpr: and the transient side would have to have a method to say "rebuild my transient stuff now that the PC is fully loaded"
(9:14:41 AM) James[Code_SB]: Yeah
(9:14:48 AM) James[Code_SB]: That may be an interesting one
(9:15:02 AM) [Arch_SB]thpr: the trick is how to do this across potential facet name changes
(9:15:15 AM) James[Code_SB]: We would trade persistence complexity for rebuild complexity
(9:15:35 AM) James[Code_SB]: oh yes, that's an interesting issue - loading up a character from 4 years ago
(9:15:54 AM) [Arch_SB]thpr: We already have the rebuild complexity in the existing PCG load, we just don't admit to it :)
(9:16:00 AM) James[Code_SB]: :)
(9:16:24 AM) [Arch_SB]thpr: I'm beginning to like that idea. Need to think through if there are any holes
(9:16:31 AM) cpmeister____: alas, that could have been avoided long ago if we put in versioning tags in everything :)
(9:17:54 AM) [Arch_SB]thpr: One option is like what we do for deprecated tokens - have an interface that can read and load another token's location in the core. Facets could have the same deprecation methodology
(9:18:12 AM) [Arch_SB]thpr: Would prohibit wholesale renaming in the core, but for small changes...
(9:18:48 AM) [Arch_SB]thpr: Could also store a name, e.g. "LANGUAGE" that would allow each facet to register what "part" it owns
(9:18:58 AM) [Arch_SB]thpr: and just ensure we dont' load two facets with matching names
(9:19:05 AM) [Arch_SB]thpr: that's more flexibit
(9:19:07 AM) [Arch_SB]thpr: *flexible
(9:21:09 AM) [Arch_SB]thpr: The rebuilding the transient stuff is something that's been bothering me for other reasons too... we may need to visit that to see if we can think of a better way
(9:21:23 AM) [Arch_SB]thpr: Also related to the output token thing if you can believe it
(9:22:10 AM) [Arch_SB]thpr: ...but for now, any other thoughts on persistence? I like the two caches and having things in the persistent one know how to read/write themselves
(9:22:50 AM) cpmeister____: I have a question
(9:23:26 AM) cpmeister____: how will we store dependent information such as user selections made at specific levels
(9:24:01 AM) [Arch_SB]thpr: Right now they are stored in a LevelInfo (If I recall correctly) object, we'd continue to do that
(9:25:30 AM) [Arch_SB]thpr: (and to be honest, some level dependent information today is destroyed and we want to start persisting it)
(9:25:44 AM) cpmeister____: well, I'll just leave the issue for now so we can move on
(9:26:16 AM) [Arch_SB]thpr: Is there a specific concern with it? We can do that now
(9:27:13 AM) cpmeister____: not really, I don't have the forsight to see any real potential problems
(9:27:19 AM) [Arch_SB]thpr: ok
(9:28:08 AM) [Arch_SB]thpr: So I think for the persistence, it's probably down to getting a full list of implications (what types of classes need to exist, interfaces, steps to read/write) and that's probably homework to go onto the _dev list
(9:28:26 AM) [Arch_SB]thpr: Not sure we can do much more here ... but open to additional questions/comments if anyone has them
(9:30:09 AM) cpmeister____: none here
(9:31:06 AM) [Arch_SB]thpr: James?
(9:31:28 AM) James[Code_SB]: Sorry just catching up again but I thikn I'm all good
(9:31:52 AM) [Arch_SB]thpr: I think my two items are done, anything you want to hit James, or are we at open floor time?
(9:32:12 AM) James[Code_SB]: I think we are at open floor time
(9:32:44 AM) James[Code_SB]: Thanks for the thorough round up of those two too Tom

Other Items

(9:33:17 AM) James[Code_SB]: Connor would you be happy with a new pcgen release next weekend?
(9:33:33 AM) James[Code_SB]: I think we are pretty close to ready on the companions tab
(9:37:20 AM) [Arch_SB]thpr: While you wait for an answer, Any open floor items or any topics for future meetings?
(9:38:19 AM) James[Code_SB]: Anyone else feel free to jump in, but I had one pretty low level concern to raise
(9:38:58 AM) James[Code_SB]: With the move of data from being directly stored in the Playerharacter to being stored in the facet cahce by an id, it is very hard to dsee the character state when debugging
(9:39:48 AM) James[Code_SB]: Eclipse will happily show filds and heir values, but not things that are calculated by the code etc
(9:40:49 AM) James[Code_SB]: One possible solution is to have a debug object held by the pLayerCharacter with a private field linking to the cache for a character
(9:41:21 AM) James[Code_SB]: Architecturally it is ugly, but I think we do need a method for debuggin the character data while stopping misuse of that data by code
(9:41:32 AM) [Arch_SB]thpr: uhh, except the cache is a map for ALL Player Characters
(9:41:37 AM) James[Code_SB]: yeah
(9:42:07 AM) James[Code_SB]: It might be better as a question on notice for next time or a later discussion
(9:43:25 AM) cpmeister____: back
(9:43:43 AM) cpmeister____: I wouldn't mind a new release
(9:43:49 AM) James[Code_SB]: Cool
(9:44:40 AM) [Arch_SB]thpr: So on the debug info, let me ask a few questions
(9:45:05 AM) [Arch_SB]thpr: If a field is some arbitrary value, Eclipse is identifying that value and then doing a toString to display it to the user?
(9:45:19 AM) James[Code_SB]: Yep
(9:45:24 AM) [Arch_SB]thpr: (so you get ArrayList and [blah, blah])
(9:45:32 AM) James[Code_SB]: Yeah
(9:45:52 AM) [Arch_SB]thpr: So when CACHE is something that uses Object.toString(), you're out of luck
(9:46:07 AM) [Arch_SB]thpr: So first step could be to make DoubleKeyMap implement a nice toString()
(9:46:10 AM) James[Code_SB]: Even worse
(9:46:37 AM) [Arch_SB]thpr: and the CharID has to have something that also identifies the PlayerCharacter (since it ALSO uses Object.toString())
(9:46:49 AM) James[Code_SB]: Curently you can't get access to the cache, let alone those parts of the chace relevant to a character
(9:47:06 AM) [Arch_SB]thpr: Why can't you get access to the cache?
(9:47:20 AM) [Arch_SB]thpr: The debugger should be able to see it... right?
(9:47:35 AM) James[Code_SB]: If it can see a field that is linked
(9:48:04 AM) [Arch_SB]thpr: So it can't see private stuff?
(9:48:18 AM) [Arch_SB]thpr: or am I not getting the issue here...
(9:48:26 AM) James[Code_SB]: That part may be me just missing it, but unless I am stopped in a facet the cache is generaly not in a field I can see
(9:48:58 AM) James[Code_SB]: private is fine btw - the debugger will show you those
(9:51:47 AM) [Arch_SB]thpr: I'll have to experiment
(9:53:03 AM) [Arch_SB]thpr: So we should revisit this next time
(9:53:26 AM) James[Code_SB]: For sure - thakns
(9:54:07 AM) [Arch_SB]thpr: Any other topics?
(9:54:52 AM) cpmeister____: none here
(9:54:58 AM) James[Code_SB]: I'm good
(9:55:06 AM) [Arch_SB]thpr: ok, I think we'll call that a meeting then. You have the log James?