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.

I agree...this is an equivalent task to cleaning out the Augean Stables...though YOUR day is more on the cosmic level, having no river to divert other than your own energies. :cool:

Half the options menu's are converted and working in blizzard options, trying to actually write decent descriptions of what everything changes at the same time

Got bored of doing the same thing over and over and took some time to fix that black box showing across half of wandering isle, and at the same time got the satellite map for wandering isle to display

Modules are, depending on how you implement them, AddOns in their own right (though only useful if you have the main AddOn loaded) so they would, of course, have their own set of SavedVariables. You can (of course) inject those settings into the main AddOn, but at that point there would be no default values (from the perspective of the main AddOn).

EDIT: I was responding to what Myrrodin was saying on the subject. No damn clue how I got so far behind. Yay.

that's what I thought... probably best to stick to separate saved variables per module otherwise when one gets disabled and logs, all the settings for it would be reset.

As part of my rebuild I've actually sorted all the options into subcategories, what are the chances I can remove say ... Nx.db.profile.quest from my current savedvariables, then link it in from the module

ie Nx.db.profile.Quest = CarbQuest.db.profile .... wait no, that wouldn't work still leaves me with no defaults and the info would end up saved twice probably. .... just trying to work out the best way to do this without redoing all the changes I just made going from the old NxData.Gopt to Nx.db.profile

*Whistles a little dittie and accidentally drops a beta screenshot on the floor*

AWW hell yea!! when do we get to test it out :D

soon... I was working on updating the options window when I decided to take a break from it and start modularizing the entire addon .... 4 days later after much cursing and swearing... and a few nights of being so entranced in the work I forgot to sleep... it was finally done so now I can go back to adding the options.

Debating on calling it Carbonite2 or Carbonite.Maps since it does kill all your savedvariables, so there is no going back and forth between it and the live version unless you backup the savedvariables first

If you decide to rename it, I would think Carbonite2 is the better of these two choices or perhaps a play on words like CarbonLite since hopefully it is a little lighter than the previous incarnation.

A carbon light is a pretty bright thing.:banana:

I second Carbonite2 or even Carbonite v2.0

I think Carbonite2 or Carbonite v.2 would be the best names for the new version so people can find the new version much better. Keep up the great work Rythal!

I say Carboniter 2: Rise of the Maps

Or you can just call it Carbonite. Yes, it is a total rewrite, but it keeps things consistent. You won't get bajillions of people asking "should I download Carbonite or Carbonite 2/lite?" "What is the difference?" The point being, most people who use the addon do not read the forums, and would get lost immediately.

but on the same note, most people who use the addon and don't read the forums will be OMG MY NOTES ARE GONE?? especially since by the time i'm done my beta for v2, notes will be entirely redone to better support dungeon levels and 3rd party modules injecting into them.

If you're really worried about notes, you could write a migration just for those...

Releasing as Carbonite 2 as a different addon and informing people on the download pages of the changes both here and on curse should alleviate most of the confusion. I know it would be a little bit of extra work but even making sure that the current version of carbonite works through at least the 5.2 patch along side of the 2.0 version with a nag message that notes should be written down and that support for the original will end with the next major patch in favor of Carbonite 2 would be ideal in my opinion.

This would give people who do have a lot of notes the opportunity to write the most important ones down and be ready to transfer them or the die hard users to have a little bit of time to test the waters on the next version.

Can't wait to see the changes in store though.

So.. been a while since I updated this.. the last beta is almost working except a few minor things so I started pushing forward towards the next one... Quest system rewrite

So far in my developer build, i'm now standing in northshire with the new quest database layout... quest start and end track properly, now i'm trying to get the blobs to show up.

Still a long way to having it working, but closer then I was. I've also noticed some smaller issue's which isn't totally carbonite's fault, like the northshire quests are all off by +15,-10 ... but so is wowhead so obviously blizzard moved the zone coords when they redid the zone.

Check WoWDB - the coords may be a better fit.

I know you were leaning towards "Caronite 2" but I think something like "Carbonite Suite" may be more fitting since parts of the setup are not required. You could even produce a "Carbonite Lite" which is basically something like the maps and quests only. I know that people can turn on and off different parts of the addon but there are some people who are not skilled enough to do that and would prefer the simple one click and go vs. install, turn off different parts and then go. It would also be much lighter weight for those people with lower end computers even though I know you are working to reducing everything down.

Just to chime in on the quest database issue.

If you haven't already decided, it might not be horrible to go the same route that DBM did... let Carbonite users load each expansion's quest data as they need it. Rather than making them fully seperate addons though, I'd probably make it a per-character setting and a default, since those of us with lots of RAM will just load them all so we can do loremaster or faction grinds, and those wanting to trim the fat probably want pandaria for their 90's and core/bc on their alts, as they level.

Also, while I'd prefer just sticking with Carbonite, I can see wanting a new name to mark that it's a major change and that old data may/will get lost. I guess I'd go with Carbonite 2, since it then becomes obvious which one is newer.

Yet another chime on the quest database issue. Trying to separate quests into groups can be difficult. Mentioned here was quests by expansion, but of course there are also quests by zone, and others. However, the lines blur when you have to consider where quests start and where the end for zones, or whether a quest from an earlier expansion is involved in a later one (as a prerequisite for example). These types of separation can prove difficult depending on what you are trying to provide for the user. From my experience, a full quest database is large, but using up 20 meg of RAM is nothing compared to the FPS suck that can happen with other things. As long as the FPS that Carbonite uses are kept to a minimum, having a large quest database should not be a problem, so keeping all the data together would be easier to maintain and complicate interaction with the data less. With lower maintenance, it is more likely the author will be able to do more things. :-)

Fine by me. :)

More and more people are using 64-bit machines these days, and if they are, WoW runs as a 64-bit executable... meaning it no longer has the 2G limitation on process space.

Looking at my own right now, even with all addons loaded, the entire process takes up only 1.2G. My web browser actually takes more (curse you tabbed interface!).

I'm doing it by level range... 0, 1-10, 11-20, 21-30 etc etc .... if your level 70 working away in wrath, you dont' need 85-90 yet, nor do you still need the starter zones.

But it's entirely optional, i'm not doing auto loading and leaving it to the user which they want or don't.