Work log on the next beta
 

Well, as I mentioned in another thread, I've managed to decrypt the entire quest database... unfortunately it increases memory usage by 5M in it's new form.

For those with good computers it's nothing, not much more then any of the other questing addons/trackers but I want the option to turn parts of it off, if your 90 doing panda quests, do you really need the quests from teldrasil in memory? no... no you don't :P so the first part i'm working on is the change over to ace libraries and moving all the options / configuration to the blizzard addon window.

At the same time i'm experimenting with the future of it as modular, disabling entire scripts like favorites or guide and watching how it reacts (so far... it reacts badly :P but i'm learning why and where)

tonight's main change to the code was the complete removal of all the leftovers from when it was a paid addon, Nxsec.lua is no more, and all the licensing functions, duplicate functions for paid or free etc has been removed.

This sounds so awesome... can't wait till everything is modular!!

Thanks so much for everything you do!!!

Personally, I'll miss Carbonite having its' own options window. For me at least that works nicer. While it's nice to just go to one spot for all of your addon options, I really like those addons that have their own options windows.

I'd go for it if you can somehow make the Carbonite options tab in the Blizzard options look/act pretty much like it currently does, except, of course, using the Blizzard options window. Y'know, things like no drop down menus........

reorganized the entire carbonite directory, data files are now in data subdirectory, locale is now in locale subdirectory, libraries in lib.

finished first part of ace conversion... Nxtimer is gone, everything converted to AceTimer.

Not that I expect you to need help, Rythal, but if you do want some, I'm sure the people on wowace.com would be able and willing to answer any questions.

I'd be willing to help where I can, but between my mediocre skills and time constraints, I don't know how valuable my help would be. But I do know one thing I'd like to see in Carbonite eventually: the Warehouse supporting the guild bank, and that, I do know in a very powerful way. I could even write a Carbonite module if I knew Carb's API; Ace is the easy part.

right now, the main thing i'm trying to figure out is how to take current saved variables, and convert it to acedb for easier profile support... not sure there is a way I can do it without everyone losing there current settings :(

IMO scrap the old way, its not hard to redo settings anyway (sry that was kinda blunt :p)

yeah that's probably the way i'll go... lord knows for some reason just the little things I've done already has somehow killed all my settings :P the only part i'm really concerned about is notes... there will be a lot of very upset people if there old notes vanish.

Not knowing the internals of Carbonite, nor Ace, I will still comment. When I have changed the format of saved variables, or added new ones, I made the addon check the version of the addona against the version of the saved variables and make adjustments as needed. This allows someone who has not used a modern version to be updated automatically when they do. No one needs lose anything. Whether this type of thing works with Carbonite will be up to you. :-)

TBH I lost my notes long ago while testing out a beta that was put out. (I think it had something to do with map coords? not sure though)
Maybe doing something along the lines of what Nimhfree suggested would be helpful, like checking the version numbers on load and transferring the old notes/settings to a "temp file" for conversion. Would only have to be done on major revisions I would think.

Question: is it the fact it's a major revision that tells you this needs to be done, or is it the fact this needs to be done that tells you it's a major revision?;)

Coders prerogative i would think :cool:. Anything that majorly changes how something is saved either needs to be 1) able to convert old settings to new or 2) needs to do away with the old settings and start from scratch.

the more I look at it, the more i'm thinking of just doing away... my memory usage for carbonite went from 11M down to 7 after my savedvariables got cleared...

I can't say about user notes as I've never used them, but other than that I'd say it's no big deal to redo the options from scratch. Lord knows that in the past I've already done that a bunch of times due to one thing or another anyway.

So, as far as I'm concerned, just have everybody start over.

I can't comment about conversion, but what I can tell you is how AceDB-3.0 works.

1. Create your Defaults table, local, in the main chunk
2. Set up saved variables in OnInitialize() using profile, character, global, etc, either individually or combination
3. Log into the game, change some settings, log out

You will then notice that the saved variables file only contains the changes you made to the settings, and not the entire batch of settings. This is very important to note, because it means AceDB has an extremely low footprint, keeping only the changes.

If you changed nothing, and left all the settings as default, then AceDB-3.0 would write nothing, and your saved variables file would be blank, or very close to blank.

By comparison, your saved variables file will contain everything, defaults and user altered settings, should you write using basic Blizzard code. That's great for addons with only a couple of settings, but for something like Carbonite, Pitbull4, all boss mods, or any addon of a complex nature, it becomes a beast.

Just wait. The memory usage will grow over time (unless you've found a way to hide newly found nodes, questing information, profiles and set up information, etc., etc., etc.).

IIrc, that's around the amount of memory that Carbonite uses on a fresh (totally new) clean install. It goes up with every new thing that gets added to Carbonites SavedVariables (but, of course, you knew that :o).

One question..... will this mean every module I split off will need it's own DB, or can I modify the main default.

Already got the functions working for modules to push themselves into the options frame, but haven't looked to much into the db portion yet.

Tired... thought i'd post another update

- AceDB is in, every option is converted to the new.
- Map icons all now scale from 0.1 to 10 instead of 0.1 to 3, I found 3 to small.
- all the lua's are updated to use _G instead of getvalue
- Moved some options from per character to per account, like map locations/sizes with the inclusion of
profile support it just made more sense.

I broke NPCScan overlay support :/ since it called carbonites GOpts which no longer exists, debating between letting them update to use the new Nx.db, or adding GOpts back containing whatever variables they want just to keep it working.
Edit: thinking more, leave it broken since a) NPCScan should be updated to not display in carbonites microdungeons and b) they are calling the old saved variable array NxData.GOpts.

Next up, the new options window since right now after the aceDB conversion I can't change 90% of the options lol.

go Rythal go! i tihnk even Heracles would pat you on the back

You can go either way. If you need a module to have its own saved variables, you can do that; you could also just add to the main file saved variables. Both methods work, and use whichever suits the modules the best.

Don't forget that Ace3 does have built in module design support in its API.