A look at what's neccessary to go from RC3 to RTM

It's been many months since the birth of the drag and drop project. Through it's long development cycle of on and mostly off development, the project had evolved from a simple test map into it's own full right project, one which supersided my magnum opus in its featurettes, if not in core design alone.I had come to a conclusion that RC3 was going to be the last beta edition. There isn't much more to add to a bag and spellbook.

As far as interfaces go, the bag is perfectly complete. I really can only think of one thing to add to the bag, and that in its self would not even be related to the bag. It would be an anytime pickup item. That would smartly determine that if all slots were full it would enter the bag and forgoe the error message. I had done such technology in DT4a. The main annoyance is the drop but I also solved that in DT4a. The interface would be simple to to add so I don't know if it's really neccessary. However, for the sake of being complete I may include it.

The spellbook, for the later end of development, has been the main focus of the project. The spellbook is lacking certain key fundamentals that I believe would really make it a more acceptable interface. As it stands now, it would be too much of annoyance to really use in a map with a large skill set because when you aquire a late game skill it'd be all the way at the end of the spellbook. There is a way to fix that. It's called sorting. Unfortuantly, I would need some sort of comparision sake.Another issue is levels. It was the real dettereant of completing the project as I could not release a spellbook that could not handle multi-level spells. I felt that would be cheating the project of its ultimate goal. Adding levels thanks to 1.17 will be a breeze. Unfortuantly, it means spells need new fields and would need some core work arounds. Finally, another problem is that spells should be allowed to be removed from the book. I don't see this as an issue, but it could provoke some questions.
My idea for spell removal:
When removing a spell, It provokes the question, should the ability remain on the units command card? I figure no. But then I realize that if you don't want them to have the ability you could just remove the spell from the queue and then remove the spell. It's a simple question but it raises a question in the next issue.
My idea for level ups:
I would rather not include an interface to allow you to attribute spell points. I would rather you find scrolls or by triggered events gain levels in spells. The interface is not really my bag and I think it needlessly will complicate things anyway.
My idea for sorting:

I could add a new field to spells (priorty). But then there is another issue; spell A at level 1 may be of less priorty then Spell B at level 1, But when Spell A reaches level 2 it is clearly a better spell than B at level 1. I would probably add another field PriortyIncPerLevel or whatever. Since sorting is a nightmarishly complex operation compared to removing and inserting at the right indice, I would probably rather remove the spell, then simply readd it. ( n2 vs log base 2(n) at best) This comes to the issue above, since I would rather remove it would remove the spell from the queue. Not a big deal, except if he had a cooldown on the spell. now the spell is gone from his command card and he's greated with an error message which probably will confuse him. I don't know if I see this as a too big of a problem, but it may be. For instance a spell may have reduced cooldown at higher levels. Since you casted it at level 1 you have to wait the full duration of the level 1 cooldown, even though at level 2 the cooldown is halfed.

Anyway for the TL:DR crowd...
--RC3 to RTM expected changelist:
Bag related:
-No changes on the bag
-Maybe a pickup anywhere item object added.
Spellbook related:
-Spells will now sort by priorty
-Spells will have levels
-Spells will gain priorty per level
-Spells can be removed
-No spell level attributer (would be intuitive to say the least)
-Uscroll will upgrade spells //not described above.

I will also release RTM in two versions. A developer edition which will look like all the other releases (all objects as seperate triggers, all private triggers as seperate triggers), and I will release the end user edition like I released DT4a (everything in one giant trigger).

Good stuff man. The only problem I have with it is it's not very accessible if this isn't exactly what you're looking for. I'm attempting to recreate my own version now based on yours with changes I need (Including the levelable spells among other things) and just for the hell of trying to make it. I hope this isn't a problem as long as long as I include your name in the map, right?

I have no problem with you using my technology. I just really wish people would pony up information about what they don't like or do like about the project in its current form. I mean when I got down to confronting people who were chastizing DT4a everywhere it turned out to be something stupid, like they didn't like the icon I was using for no item. I try to leave these projects fairly open ended, (there are things I'm not going to allow ofcourse like running triggers from casting spells, not my code's job really.) and if it does soundlike an interesting proposed change I may do it. Again with in limits.

one thing that i think is interesting, and maybe not entirely realted to your bag: when i was testing out RC3, sometimes warcraft would just stop letting move items, say i right click on an item to drop it, nothing happens, it wouldn't even let me drag the item

Well first of all I need the bags to be undroppable yet still selectable so I can put items to and from it (much like your "next page" item). A nice addition to your code would be a "takes boolean droppable" parameter in CreateBag. Then I need the first page of the bag to be filled up all the time with other bag like things, a crafting "bag", a bag containing items used for crafting by the hero, and a spellbook. Secondly for the bag I need a previous and next page rather than just next. Now the main page needs to be limited to only equipment of certain types (IE slot 1 is a bag, slot 2 is a weapon, slot 3 is armor, slot 4 is boots, etc.). That also means items must go into the bag first when picked up.

Like I said, your code is great, but I just can't quite use it yet. It will still be the backbone to the system I'm creating however.

Undroppable wouldn't really work. If you make the bag undroppable you can't drag items on to it. If you mean a softwired droppable like the cancel button, then that could be done. But I don't see it being practical and defeats the purpose of making the bag an object instead of just more code in hero. Crafting is a much higher level coding then my bag so it's best that you create your own method. (Each crafting formula is explicit and would be more annoying then good really). As far as going to the bag when picked up I'm still debating the pick up anywhere item. It still will try to use your main inventory first though. Finally, the slot 1 restriction garbage is just a poor man's equipment system. I'd really suggest that you look into a higher calibur equip script. Your main inventory should always be for quick use items and if your first 5 slots are wasted on equipment and the 6th is your bag then your left with only being able to use potions in your bag.