|
Post by compuscribe on Mar 4, 2011 19:15:02 GMT -5
No hurry! I wasn't expecting an immediate resolution, anyway. I'm just picking the brains of the people, here. Even if I did manage to get a working savefile class of some sort, I'd probably wait until I had a chance to look through savingloading.as and straighten that out a bit, then upload the whole package.
By all means, slow down. Take some time for yourself. Do whatever else you need to do. This'll wait! It's mostly theoretical at this point, anyway. Even if I did simply copy & paste the relevant code, it's likely it'd only be used in savingloading.as and charactercreation.as, so it isn't a huge amount of redundancy. There's no sense in killing yourself, simply for the sake of more elegant code.
|
|
|
Post by docclox on Mar 5, 2011 2:39:58 GMT -5
|
|
|
Post by compuscribe on Mar 6, 2011 0:37:41 GMT -5
I don't know about the continuous save problem. As I said, that's most likely a combination of the shared objects still existing after the function exits + objects being passed by reference, rather than value (so when it changes and is flushed again, the new value is written to the file, rather than the old one) + either flushing when loading a save or the automatic flushing that happens when a flash file is closed. By setting the SharedObject to null, it's no longer tied to the file, it can't continuously save. (And by removing the flush() statement from the load function, it read-only function, like it should've been, all along.) Near as I can tell, with those changes in place, the continuous saving problem seems to have gone away.
There have been sporadic cases of other errors when trying to reload a save file, however, that have not been resolved. Evidently, it's looking for some data that either was never stored or was stored incorrectly (or is being accessed incorrectly) ... which isn't surprising, since there are parts of the code where you can almost see where Daisy was getting frustrated and just throwing things out there to see if that would fix the problems. I don't think converting everything to byte arrays would solve that. If the data is being stored in one place, then you attempt to retrieve it from another, it won't work, no matter what format the data is in.
That said, the byte arrays could, conceivably simplify the process of storing some of the more complicated objects, like the girls, themselves, with their countless properties, but for almost anything else, it's a bit like trying to swat a fly with a bazooka. You're replacing a single assignment statement with a 12-line function (some of which contain functions, themselves) ... that returns a value that is stored in the original assignment.
Furthermore, the byte array seems to store and restore the whole object as a single chunk, and you might want to examine the various parts as they're being put back. (For example, I may be misremembering things, but I think girls can both wear the strap-on, like clothing, or have it locked on, like an anti-chastity belt.) Yes, you could search through the various attributes, after they've been put back, and adjust anything needed, but at that point, you're not really saving any work (which is the whole point of having a class with reusable code, in the first place), and you might as well find a way to do the adjustments while putting the data back.
Hopefully that made some kind of sense. Evidently, the brain-to-English thought processes aren't working too well, tonight. (At the very least, the fingers seem to be having trouble typing complete sentences.)
[edit] It's a little late, but lest there be any confusion, the problem was with my brain-to-English thought processes. Trying to convert the ideas in my head to coherent sentences on the screen was proving more challenging than usual, that night (and it's rather hit & miss on the best of occasions).
|
|
|
Post by compuscribe on Mar 17, 2011 18:59:30 GMT -5
Since my whole goal was simply to patch up the save functionality and let everyone else take over, I've already gotten more involved than I ever intended to, so I decided to take the easy way out. I'm just going to copy over the relevant code. (Other than the event handler, there a minimum of shared code, anyway.) If you find a better solution, feel free to sort it out, later. I'm sifting through the save/load logic, now. (If nothing else, hopefully my extra comments will make it easier to maintain, in the future.)
As for the real reason behind this post, I updated the latest revision in the trunk and was updating my charactercreation.as file accordingly (to work with the newly-instanced buttons), when I noticed the assistant I chose was hiding in the upper-left corner, while a randomly generated Neko assistant was occupying the master bedroom (overlaying the player). I thought maybe I'd screwed something up, but after backing up my file and reverting it to the latest revision (prior to tinkering with it, I deleted the whole directory and started with a clean download from the trunk, so I've made a minimum of alterations), I got the same behavior (minus the stored settings I'd implemented). If I alter the settings I get my assistant + the random Neko. If don't, I get a full slate of randomly generated assistants occupying each of the master bedrooms, even if I haven't bought/hired them, yet. (This is with the unaltered charactercreation.as file from the trunk.)
Basically, I suspect someone tweaked something for testing purposes and forgot to change it back before merging their revision with the trunk. Probably worth looking into.
[edit] At least this was true as of revision 128.
|
|
|
Post by compuscribe on Mar 23, 2011 1:03:04 GMT -5
One of these days, it's going to sink in that Doc knows a hell of a lot more than I do!
After messing with things, it seems that setting the SharedObjects to null doesn't do a whole lot, because the problems do stem from everything being passed & stored by reference, rather than by value. (It was just less obvious when there were fewer classes.) Near as I can tell, the byte arrays are absolutely the key to getting around that.
That said, I've only done small scale tests, so far (I'll see how incorporating them into the actual game goes, later), but I think I've managed to pare down the encode/decode functions a bit.
function encode(obj:*):ByteArray { var ba:ByteArray = new ByteArray(); ba.writeObject(obj); return ba; }
function decode(ba:ByteArray):* { ba.position = 0; return ba.readObject(); }
Like I said, I've only done small scale tests (I created a tiny program with a simple Circle class), so far, but it seems to be working and bypassing a lot of the problems the current saves have been having. (Prior to the fixes, it was saving when it shouldn't, and I've even been able to restore the data as a proper class, and not simply a generic object.)
This has taken a whole lot longer than I'd planned on, but I actually seem to be making headway. It might be a little harder for Doc to merge in, when I'm finished, though. (I'm going to have to tinker with a lot more files than I thought I would.)
|
|
|
Post by compuscribe on Mar 25, 2011 20:20:45 GMT -5
I don't know if anyone else is even checking this topic, anymore, but I've cobbled together a SaveFile class that seems to be working at least in my small-scale tests. Before I started gutting the existing save files to incorporate the new class (and possibly making a mess of things), I thought I'd throw what I have up for scrutiny, since it's become increasingly obvious that I don't know nearly as much as I thought I did (though I'm slowly getting better).
package { import flash.utils.ByteArray; import flash.events.NetStatusEvent; import flash.net.SharedObject; import flash.net.SharedObjectFlushStatus; public class SaveFile { protected var so:SharedObject; //SharedObject used to store data for this class /* Public Methods */ /* Constructor * Parameter: fileName:String (optional) - name for the file to be used for the local SharedObject */ public function SaveFile(fileName:String=null) { if(fileName != null) { so = SharedObject.getLocal(fileName); } else so=null; } /* Function: Open(String):void * Purpose: opens a save file if none was provided in the constructor or if you wish to open a different file * Parameter: fileName:String - name for the file to be used for the local SharedObject */ public function Open(fileName:String) { so = SharedObject.getLocal(fileName); } /* Function: Save(String, *):void * Purpose: copies data to SharedObject, in preparation to store it for later use * Parameters: prop:String - property name under which you wish the value to be stored * val:* - actual value you wish to store */ public function Save(prop:String, val:*) { //check if a local file has been opened if(so == null) { trace("Unable to save! No file opened!"); return; } //convert value to byte array and store it under the provided so.data[prop]=encode(val); } /* Function: Load(String):* * Purpose: retrieves data from the provided property of the SharedObject * Parameter: prop:String - property from which you wish to retrieve data * Returns: value being retrieved from the SharedObject */ public function Load(prop:String):* { //check if a file has been opened if(so == null) { trace("Unable to load! No file opened!"); return; } //retrieve data from designated property, convert it back to its original form, and return it. return decode(so.data[prop]); } /* Function: Write() * Purpose: writes the data in the SharedObject to the local file */ public function Write():void { //preparing to write, so append data to indicate existance of file prior to flushing so.data.fileExists = new Boolean(true); var flushStatus:String = null; //stores result of upcoming call to flush() //attempt to flush data to disk try { flushStatus = so.flush(); } catch (error:Error) { trace("Error! Could not write SharedObject to disk!"); } //check flushStatus if (flushStatus != null) { switch (flushStatus) { case SharedObjectFlushStatus.PENDING: trace("Requesting permission to save object..."); so.addEventListener(NetStatusEvent.NET_STATUS, onFlushStatus); break; case SharedObjectFlushStatus.FLUSHED: trace("Value flushed to disk."); break; } } } /* Function: FileExists():Boolean * Purpose: Checks if the currently opened SharedObject corresponds to a previously saved file * Returns: True if it's a pre-existing file, false if not */ public function FileExists():Boolean { return so.data.fileExists; } /* Protected Methods */ /* Function: encode(*):ByteArray * Puprpose: Take and object of any type and converts it to a byte array for storage * Parameter: obj:* - object you wish to be converted to a byte array. * Returns: a byte array containing all of the information from the object */ protected function encode(obj:*):ByteArray { var ba:ByteArray = new ByteArray(); ba.writeObject(obj); return ba; }
/* Function: decode(ByteArray):* * Purpose: Takes a byte array and converts it back its original form * Parameter: ba:ByteArray - byte array containing the data for the object * Returns: the properly restored object */ protected function decode(ba:ByteArray):* { ba.position = 0; return ba.readObject(); } /* Function: onFlushStatus(NetStatusEvent) * Purpose: event handler for dealing with "pending" status on attempted flushes * Parameter: event:NetStatusEvent - event triggered when user closes permission dialog */ protected function onFlushStatus(event:NetStatusEvent):void { trace("User closed permission dialog..."); switch (event.info.code) { case "SharedObject.Flush.Success": trace("User granted permission. Value saved."); break; case "SharedObject.Flush.Failed": trace("User denied permission. Value not saved."); break; } so.removeEventListener(NetStatusEvent.NET_STATUS, onFlushStatus); } } }
So, how's it look? Does it look like something that might work? Any glaring problems?
(Edited to provide commented code. Also, I've tested this class with my modified charactercreation.as and it works, but that's all basic data types, so it's hardly a great test. The SaveFile object still needs to be global -- and unless someone knows a way to keep an object created in a function from being destroyed when that function exits, I don't think there's a way around that -- but it works. You also need to be REALLY careful to spell the property names correctly, since they're just strings, and the compiler won't be able to catch when you try to load something from a place that was spelled differently than the place you saved it until you actually try it. I'm not sure how to make that any better, though.)
BTW, I'm thinking that I should probably change the Save() & Load() methods to Set() & Get() and replace Write() with Save(), to avoid confusion, but anyone have any suggestions beyond that? Tackling savingloading.as (and the files containing any classes that it needs to save) will be a big task and I don't want to start digging through all that until I'm reasonably certain I'm on the right track.
In fact, it might be better to just had off what I've got so far and let someone who is involved in the project take over.
Sorry for the epic post. I know there's a lot here, but I didn't think it was quite large enough to justify making it a download, and this should make any discussions easier. Since there's so much, however, I'm not expecting anyone to drop everything and pour through it all at once, but feedback would be helpful, whenever you find the time.
I also want to thank Doc! His insights have been a huge help in getting this far. I'm sorry I tried to dismiss some of your ideas prematurely! (Where's a shamefully embarrassed emoticon when you need one?)
|
|
|
Post by daisy_strike on Mar 25, 2011 22:46:12 GMT -5
Thats a bit over my programming level...
Daisy
|
|
|
Post by docclox on Mar 26, 2011 23:28:41 GMT -5
I don't know if anyone else is even checking this topic, anymore, but I've cobbled together a SaveFile class that seems to be working at least in my small-scale tests. Before I started gutting the existing save files to incorporate the new class (and possibly making a mess of things), I thought I'd throw what I have up for scrutiny, since it's become increasingly obvious that I don't know nearly as much as I thought I did (though I'm slowly getting better). You look like you're doing OK to me Am I right in thinking the class just saves it's own state? Also, I've tested this class with my modified charactercreation.as and it works, but that's all basic data types, so it's hardly a great test. The SaveFile object still needs to be global -- and unless someone knows a way to keep an object created in a function from being destroyed when that function exits, I don't think there's a way around that -- but it works. You could try a static class member to hold it. In fact, it might be better to just had off what I've got so far and let someone who is involved in the project take over. Like I say, you're doing fine by me. I've got a worklist a mile long, so by all means go for it. Knowing you're looking after this issue frees me up to do other things for the game I also want to thank Doc! His insights have been a huge help in getting this far. I'm sorry I tried to dismiss some of your ideas prematurely! (Where's a shamefully embarrassed emoticon when you need one?) Hey, you did what I would have done. You thought you had a simpler way to do, so you tested it out. That's how we all learn. I was just a little further along with my research than you were is all
|
|
|
Post by compuscribe on Mar 27, 2011 1:12:42 GMT -5
Am I right in thinking the class just saves it's own state? I suppose that depends on exactly what you mean by it's "state." Each SaveFile object defines it's own SharedObject and is responsible for any saving/loading to that SharedObject. Once the SharedObject is flushed, any relevant information should be there, so it should be retrievable, even if the SaveFile object, itself, is destroyed. It opens the file, shoves all the information in, and writes it to the disk. As an example, here's the latest code I have for saving the most recent character creation data: function saveLastCharacter(){ //playerData was declared globally as a SaveFile playerData = new SaveFile("lastCharacter");
playerData.Save("playerName", inputTextField1.text); playerData.Save("assistName", inputTextField2.text); playerData.Save("sex", Player.charSex); playerData.Save("assistant", Player.charAssistant); playerData.Save("past", Player.charPast); playerData.Save("future", Player.charFuture); playerData.Write(); } The only problem with that approach is it means you could only really have one SharedObject open at a time (since that's the part you need to hold onto until the flush is resolved), because it would be tied to the class, rather than to any, individual object. That means you'd need to be absolutely certain you're only trying to write to or read from one file at a time. Granted, this probably wouldn't be an issue, right now, but it could, conceivably, cause problems, depending on where development goes, from here. For example, what happens if someone decides to implement an autosave that saves the game at the start of every turn, including the very first one, while it's still waiting for confirmation to save the character creation data? If the handling of pending flushes has taught me anything, it's that he game will keep running, to the best of it's ability, while it's waiting for confirmation, so you can't count on the game to resolve one save before starting the next. Maybe it's just me, but it seems like the global declaration is the lesser of the two evils, especially if we want the class to be as flexible as possible, to allow for future expansion.
|
|
|
Post by docclox on Mar 27, 2011 1:41:36 GMT -5
Am I right in thinking the class just saves it's own state? I suppose that depends on exactly what you mean by it's "state." Each SaveFile object defines it's own SharedObject and is responsible for any saving/loading to that SharedObject. Once the SharedObject is flushed, any relevant information should be there, so it should be retrievable, even if the SaveFile object, itself, is destroyed. I was thinking it only stored it's own members - but the example cleared that up nicely. function saveLastCharacter(){ //playerData was declared globally as a SaveFile playerData = new SaveFile("lastCharacter");
playerData.Save("playerName", inputTextField1.text); playerData.Save("assistName", inputTextField2.text); playerData.Save("sex", Player.charSex); playerData.Save("assistant", Player.charAssistant); playerData.Save("past", Player.charPast); playerData.Save("future", Player.charFuture); playerData.Write(); } Pity we can't iterate over static members, we'd be able to streamline that a lot. Might be worth keeping an array of "save field names" in the class though. The only problem with that approach is it means you could only really have one SharedObject open at a time (since that's the part you need to hold onto until the flush is resolved), because it would be tied to the class, rather than to any, individual object. That means you'd need to be absolutely certain you're only trying to write to or read from one file at a time. Granted, this probably wouldn't be an issue, right now, but it could, conceivably, cause problems, depending on where development goes, from here. mmm... you could have multiple static members. Or event an object with a arbitrary number of SOs keyed by save name if you wanted. It'd need a master SO with the names of the slots, I guess. Maybe it's just me, but it seems like the global declaration is the lesser of the two evils, especially if we want the class to be as flexible as possible, to allow for future expansion. Six of one and half a dozen of the other, I suppose. Stick your head into the IRC channel sometime - this sort of discussion goes a lot faster in real time [edit] Boy did I mess up those quote tags...
|
|
|
Post by compuscribe on Mar 27, 2011 16:10:06 GMT -5
Pity we can't iterate over static members, we'd be able to streamline that a lot. Perhaps, but that would mean customizing the class for each, specific use. You'd need a separate class, with its own static members, for each new file you wish to save. Besides, in the end, you're not really saving much. Either you do the work in the class definition or in a local, save function, but one way or another, the work's still got to get done, and it'll need to be maintained as circumstances change. You're cutting out a few function calls, but not much else. Or am I missing something? Once it was clear that a class was truly achievable, my goal was to create something that could be as reusable as possible. Knowing the trouble Daisy's had with the saves, thus far, I was hoping to create something that would do all of the hard work, but allow for the easy creation of new types of save files that just work (at least as much as I could manage), should the need arise. Besides, it's already streamlined, quite a bit, over the original, brute-force method, since the byte arrays allow for easy storage of complex objects, including arrays of objects or arrays of arrays of objects. Rather than having to loop through the array and store each item, individually, you can just copy the entire array at once. I could've replaced playerData.Save("sex", Player.charSex); playerData.Save("assistant", Player.charAssistant); playerData.Save("past", Player.charPast); playerData.Save("future", Player.charFuture); with playerData.Save("Player", Player); but: 1) For the character creation, I figured you probably don't need all of the information from the Player class, so why waste time copying information we don't need, let alone storing that needless information? 2) I'd have had to ensure the Player class implemented IExternalizable, so I could registerClassAlias("Player", Player), to ensure the data was restored as a Player and not just a generic object. (Yes, I'll probably have to do that for the main save, but it was too much effort for a quick test, like this.) Note: I haven't tested it with a static class, so it's possible that it won't work without an instanced object. (Of course, even if it doesn't, there are ways around it, even if it means creating a localized instance of a Player object -- one that would be destroyed upon exiting the local, save function -- just to handle the saving, since Player does have a constructor, even if doesn't do anything.)That said, I'm not completely writing off the idea, just yet. Customized classes for each save file might be the only way to properly handle displaying messages to the player, so they get an accurate assessment of whether or not their save worked, since the traces it currently uses won't show up anywhere in the actual game. (I could have the game push "Game Saved" into the storyHopper, after calling Write(), but that assumes the save works, which it won't, if the player denies permission ... which they should know, but I've been proven wrong on such things before.) If I have to go that far, there's certainly no reason not to implement static members. I just don't like the idea of having to design a whole new class for each type of save file. (Of course, I could just create a popup to display the message, instead, but that would probably be more annoying than helpful.) Might be worth keeping an array of "save field names" in the class though. That's certainly doable, though in a lot of ways we already are. The entire data property of the SharedObject is simply an array of save fields. If you enumerated the various save field names, they'd simply become index values for the data property. Other than readability, I'm not entirely sure what we're gaining, here ... and by allowing people to provide property names, readability is already fairly high. (If you have the name you don't need the index. If you have the index, you don't need the name. I'm just having a hard time imagining a scenario where this would be useful, since the name is unimportant; it's just a means of accessing the corresponding data. It's like keeping an array of property names in a class.) Perhaps if I understood what sort of ideas you had in mind for using the array, I'd be better able to grasp the sort of functionality you're looking for. I suppose that could work, but a pre-defined array would once again become something that needs to be modified every time you need to save something new, almost defeating the purpose of making it a class. More to the point, since nothing else is going to be accessing it, anyway, the only real reason to avoid making it global would be to allow the garbage collector to pick it up once you're done with it ... and it's never going to collect a static variable, anyway, so you're not really gaining anything. (It's not like there's any shortage of global variables in the code, as it stands. Actionscript is kind of fussy that way.) I'll think about it. I'm not much of a chat person. Generally speaking, the closest I tend to get to a chat channel is an online, poker table. I tend to spend too much time pondering what I'm going to say and either get lost in the shuffle, or I end up holding things up. (It drives some of my friends crazy.) I'll definitely give it some thought, though. I don't have the time, right now, though. (Yes, it's a long post, but it was typed in fits and spurts. To make use of the chat, I'd need some uninterrupted time, so I'm not walking away in the middle of a conversation. This is the same reason I have the forum hide my online status: half the time I'm logged in, but I'm not actually here, so it'd only be misleading.)
|
|
|
Post by compuscribe on Mar 31, 2011 20:07:22 GMT -5
This is only tangentially related, but it seems like it'd be a quick fix, so I'm throwing it out there, but in girlfunctions.as, we have this:
function maxStatCheck() { var girl:Girl; /* * empty array - nothing to do */ if (GameArray.length != 0) { return; } when I'm pretty sure that should be: if(GameArray.length == 0)
Currently, my attempts to reload are telling me there's a null girl in GameArray[0] and I'm pretty sure that's why it's happening. (I'm trying to save/load at the very start of the game, to see if I can at least get them to finish without crashing, so it should be empty, at this point.) I thought I'd throw that out there so it can either be fixed, or someone can explain why that's actually correct.
[edit] Also, am I correct in assuming that this (taken from cItem's "make" method):
try { cls = getDefinitionByName(class_name) as Class; clip = (new cls() as MovieClip); }
creates each item as an instance of a dynamically created class (using the MovieClip class as a baseline).
And I'm assuming if I was to replace:
//cleans playerItems first temp = itemArray.length; for (var i:Number = 0; i < temp; i++) { itemArray.pop(); }
with
//cleans playerItems first itemArray = new Array();
the garbage collector would take care of the old array. It seems like it'd be a little faster, especially once the player has a lot of items, but I don't want to start creating memory leaks. (I'll admit, my understanding of the internal workings of Flash is far weaker than I'd like.)
(Note: After thinking about it for a bit, I probably will end up creating a more specialized class with static properties, at least for the main game save, but I'm starting with my existing class, just so I can nail down the logic of everything else. Once I've got something that looks like it works, I'll start trying to customize the class as I clean things up.)
|
|
|
Post by docclox on Apr 1, 2011 1:26:21 GMT -5
This is only tangentially related, but it seems like it'd be a quick fix, so I'm throwing it out there, but in girlfunctions.as, we have this: function maxStatCheck() { var girl:Girl; /* * empty array - nothing to do */ if (GameArray.length != 0) { return; } when I'm pretty sure that should be: if(GameArray.length == 0) Umm... yes. Well spotted. [edit] Also, am I correct in assuming that this (taken from cItem's "make" method): try { cls = getDefinitionByName(class_name) as Class; clip = (new cls() as MovieClip); }
creates each item as an instance of a dynamically created class (using the MovieClip class as a baseline). [/quote] I'm not sure if that's right, but it sounds pretty close. What the code does is take a string containing a class name (the linkage name of an image in the library in this case) and uses it to look up the actual class definition. From there, it uses the definition to create an instance of the class in question. All the actionscript-exported symbols in the library seem to use MovieClip as their base class (images anyway) we cast the result to MovieClip. Try/catch code because getDefinitionByName throws an exception if it doesn't find what it's looking for. And I'm assuming if I was to replace: //cleans playerItems first temp = itemArray.length; for (var i:Number = 0; i < temp; i++) { itemArray.pop(); }
with //cleans playerItems first itemArray = new Array();
the garbage collector would take care of the old array. It seems like it'd be a little faster, especially once the player has a lot of items, but I don't want to start creating memory leaks. (I'll admit, my understanding of the internal workings of Flash is far weaker than I'd like.) Only caveat there is if something external to the class is likely yo have a reference to the array. In that case, not only do the old objects not get collected, but anything watching the old array won't see the changes.
|
|
|
Post by compuscribe on Apr 1, 2011 2:44:30 GMT -5
It's worth noting that, based on my tests, I will need to create a local, Player object in order to store the information the class contains, but that does seem to work (at least it did with a simpler, static class), so I shouldn't have to copy over and store all of the values, manually. That's at least one, tiny victory. (It does mean I'll need t make doubly certain the writeExternal and readExternal methods work correctly, but it's no worse than what I need to do with the Girl class, anyway.) Umm... yes. Well spotted. My immediate save/load is probably one of the few situations where it would even matter, so I'm not surprised it escaped detection for as long as it did. I've still got a long way to go to catch up. D'oh! I've spent so much time looking at the code, I was looking for class definitions in the ActionScript, completely forgetting that there are symbols stored in the library of the FLA file. Combining that with what you've said makes a lot more sense. Only caveat there is if something external to the class is likely yo have a reference to the array. In that case, not only do the old objects not get collected, but anything watching the old array won't see the changes. Makes sense! Old version stays! Replacing the array may not cause any problems, but with everything else, why risk it? [Update]Well, I've gotten the new saves working for those entry-level saves. (Actually had that done last night. I just wanted to run a few more tests before declaring victory and moving on to the next step.) It saves the assistant and player data and no matter how many times you reload or how many days pass before reloading (or even if you exit the game after several days, before reloading that earlier state), it always reloads to the exact same point, so we're making progress. The only big thing left is the girls and everything tied to them, but with the new graphics, there's a lot of new information to keep track of, so I kind of need a working build of a more recent release before I can go any further ... and currently (as of revision 243), I'm getting an error telling me that the definition of PictureFrame can't be found. I tried commenting out the line, but that generated a slew of other errors, so clearly the changes are already fairly well integrated ... except for the class definition, itself.
|
|
|
Post by docclox on Apr 16, 2011 4:48:27 GMT -5
How's it going with this? I think I must have missed the edit, but you should be able to build from svn at the moment. (There's enough people using it on chat that if I break it, they bug me about it).
The auction screen is broken though. The new one will be replacing it in a day or so, so I haven't bothered sorting that bit out.
Out of curiosity, does your save & load handle the Player data correctly? I keep meaning to check how static class members work with shared objects, but never quite get to it.
|
|