This project is read-only.

Handling the DNN 4.x.x to DNN 5.x.x transition.

Jan 12, 2009 at 5:52 AM
If you're a gamer like myself, taking care of your DNN installation can sure be a hassle. For this reason, despite the release of DNN 5.0.0, I'm planning to support DNN 4.x.x development for the near future.

Not surprising, compatibility issues complicate things, especially if you want to check out the source and build on the work that's already been done. When I started this project, I tried to keep the workspace as vanilla as possible, but with the transition, the setup is going to have a to change a bit.

So here is how the setup is changing... keep these things in mind if you try to mimic my setup.

First, unzip any version of DotNetNuke 5.0.0. to C:\DotNetNuke. I say any version, but really I prefer to use the install version so I don't accidentally do something to mess up code that's outside the scope of the module.

Second, unzip the source code for the module to C:\DotNetNuke\DesktopModules\DotNetNuke.tss_DKP.

You can now open the solution file in the PA and everything should work. This is the setup that I've since publishing the project.

Now, if you want to maintain compatibility, then grab a 4.x.x version of DotNetNuke and install that to C:\DotNetNuke.4.x.x.

Unzip the 4.x.x. version to this folder. Currently I check for compatibility against 4.9.1.

When you have opened your solution, to check for compatibility, all you have to do is remap the DotNetNuke and Microsoft.Application.Blocks references and attempt to build. If building under both References works, then your module is compatible.

At the moment, I do not see anything that will actually result in a code base that varies between the two revisions. There will be some changes to support module packaging in version 5.0.0. As a result, some of the packaging related files with be branching to maintain DNN 4.x.x compliant packaging. Unless otherwise identifies, a file in the repository will be 5.0.0 compatible. Files specifically necessary to maintain 4.x.x compliance will be named as such.

Jan 12, 2009 at 8:35 AM
You got any eta. of when we can expect a new release of DotNetNuke DKP? Cause i'm planning a clean install of my current DNN cause i'm having some bugs with it and i was thinking about upgrading to 5.0.0 but if you aren't throwing out any release in the near future then i think i'll have to wait a bit ;)

Btw i din't have any problems installing it to 4.9.1 worked like a charm.
Jan 12, 2009 at 3:28 PM
There's presently no ETA, but I'd like to have something within the week?

Progress on the XML serice is going smoothly. It's really straight forward.

The service will respond to the following inquiries:

GetSupportedModuleVersion() - Used to detect the lowest module version supported by the XML service. If you're lower than this number, you have to upgrade the module.
GetCurrentDatabaseRevision() - Used to quickly tell if your database is current.
GetNewInstances(intLocalRevision) - Given your current database revision, what Instances need to be added/removed/editted.
GetNewMobs(intLocalRevision) - Same as above but for Mobs.
GetNewItems(intLocalRevision) - Same as above but for Items.

It's possible I'll run into a snag somehwere, but at the moment, things are going well.
Jan 12, 2009 at 3:58 PM
Also, on the WotLK support side of things, here's some thoughts about handling raids.

My intention is to define Instances as Blizzard defines instances, not as Wowhead defines instances. I think it's really unfortunate that Wowhead did not follow this policy, but hey, they can do what they want.

So what does this mean? Well, it means that when you pop open the LFG tool in WoW, if there's 6 raid instances listed, those will be the same 6 instances we create in this module's database, and you will want to name them accordingly.

For example, instead of making one instance "Naxxramus", you will want to make two instances "Naxxramus" and "Naxxramus (Heroic)".

When setting up mobs for these instances, you'll want to make two versions of the mob as well.

The loot tables will be separate as well, but you do not need to make heroic versions of a drop that drops in both instances. We've had this kind of stuff covered for a while.

Now, how does this complicate things? It's possible that any updaters in the future might balk on heroic forms of bosses if it can't tell what version of the instance you're in. Hopefully, we can get around this when the time comes.

I'm preparing the demo site to show how this will work. Currently Gluth and Naxx are on display.
Jan 12, 2009 at 4:16 PM
Sounds great!
i'm rly lokking forward to all this :)

I've been wondering a thing... what does that Random calculator do?? :P
Jan 12, 2009 at 5:13 PM
The Random calculator is a tool demo'ing how we can do things with the DKP data.

This particular tool will generate a prorated range of numbers based on the saved DKP of the people who are checked. So like if you had 4 people interested in an item, you check those 4 and hit the calculate button. If each of those players has 10 saved DKP, you'll be given something like player A is 1 - 10, player B is 11 - 20, player C is 21 - 30, and player D is 31 - 40. You would then /roll 40 to see who wins the item.
Jan 13, 2009 at 3:41 AM
The XML service is taking shape at I'll hopefully have it ready by the end of this week.

To fully support the service, I'm making a second DNN module that automates adding data to the tables that feed the XML service. I probably won;t have a release ready till this is done, because I see having a fairly responsive database update system as being a huge asset to this module.
Jan 13, 2009 at 3:50 PM

You are rly making fast progress!

A cool thing you could think about adding is a tool to add all the data for a raid boss in one long string.
I have started to make a WoW addon for this module to track the raid data with.
I want to use the addon to give out items like a bidding system.
It will save data per raid boss like your module does, so i.e. one raid boss has the following data:
Who's in the raid at the boss kill.
Who got loot and for what price.
Other manual things like adding a member to a raid boss or adding or substracting dkp from a member in the raid.

I would make and extract button to extract all the data to one long string with all the data for a given raid boss.
So it would be nice if there were a tool where you could paste this string in and it would add the Raid Boss and the members who were in the raid and add the dkp to them and also add the loot to whoever got the loot and substract the dkp from that member.

I hope you understand what i mean ;)

If you are interested in creating this tool i would love to make this addon a Public and a Specific addon for this DNN module :)
Jan 13, 2009 at 4:01 PM
Anything's possible!

What I'd do is come up with your format, and then put it into xml. That'd make it the easiest to parse on my end. It can dtill be one long string from the addon, but the xml element tags should already be embedded.

This will let you formalize an XML scheme, which will make it easier for me to write a parser on my end.
Jan 13, 2009 at 4:22 PM
I guess the string actually could just be one long XML code in some way like:
<Instance Name="Naxxramas" /><RaidBoss Value="25" /><Members>ExA, ExB, ExC</Members><Loot><Item Name="SomeEpixItem" Value="200" Reciever="ExA" /><Item Name="SomeOtherEpixItem" Value="150" Reciever="ExB" /></Loot><MemberAlterations><Alter Name="ExC" AlterDKP="-35" /></MemberAlterations>

Could this be a way?
Jan 13, 2009 at 4:43 PM
Edited Jan 13, 2009 at 5:02 PM

Yeah, the formal definition would be what you really need to put together though.
An example of a DTD is something like this...

<!ELEMENT raid (boss, date, value, roster)>
<!ELEMENT value (#PCDATA)>
<!ELEMENT roster (member+)>
<!ELEMENT member (#PCDATA)>

Fairly simple, but it fully expresses what the parser can anticipate.

From this DTD I can infer that every raid entry will have 4 parts, and one of those parts will be a list that has at least one item in the list, there maybe more.

Jan 13, 2009 at 4:59 PM
Edited Jan 13, 2009 at 5:00 PM
I think the easiest way for me would be for you to tell me how you would like the string cause then i can basicly just put in the values from the addon.
I don't rly have that much of a clue how the XML works in your module / DNN, so if it's possible for you to make a full list of how the string should look it would be awesome.

It doesn't have to be right now ofc :P
Jan 13, 2009 at 5:11 PM
Fair enough.

<!ELEMENT raid (boss_name, date*, boss_value*, roster, drops*+)>
<!ELEMENT boss_name (#PCDATA)>
<!ELEMENT boss_value (#PCDATA)>

<!ELEMENT roster (member+)>
<!ELEMENT member (#PCDATA)>

<!ELEMENT drops (member_name, item_name, drop_value*)
<!ELEMENT member_name (#PCDATA)>
<!ELEMENT item_name (#PCDATA)
<!ELEMENT drop_value (#PCDATA)>

I forgot some of the notation, so here's what my *'s and +'s mean.

* means optional
+ means at least one of this type will be present, there may be more.

This is basically the database's schema. A raid can have rosters and drops, and to add those things, you need members and items. DKP values can come from the libraries if they're omitted, or they can be present in which case they should take precedence over whatever the library says. The importer will resolve item, boss, and member names to their internal ID's.
Jan 13, 2009 at 8:19 PM
What if i would want an option to substract dkp from one member cause he screwed up or something, how would that look like?

Other than that it looks cool, shouldn't be hard to make.