Large updates bcnm, alliance ect

[link]

Large update:

BCNM treasure chest system:
-Crate spawns on win
-Triggering crate ends bcnm
-New sql table bcnm_treasure_chests.sql
-Chests reset along with everything else in the bcnm
-treasure pool loot system works with chests
-message "You find <item> on the armory crate." works
-added lua function - player:getBCNMloot();

I've added Armoury_Crate.lua to the Waughroon_Shrine folder. This new lua function is used there, it takes no arguments, it will just spawn the chest of which ever bcnm instance that player is in.

more bcnm notes:
The sql file bcnm_treasure_chests.sql will need new bcnm chests adding to it (see below).
I've added a file in documentation:
Waughroon_Shrine_armory_crates.txt which contains a list of armory crates for that zone
-------------------------------------------
Waughroon_Shrine
armory crates
17367089 - operation desert swarm
17367093 - operation desert swarm
17367097 - operation desert swarm
17367101 - hills are alive
17367105 - hills are alive
17367109 - hills are alive
17367113
17367117
and more...
-------------------------------------------
This is so we know which crates are free for other bcnm's and which are being used.
This will be a painful process setting up each chest individually so I thought this would be a good idea

Loot can currently be set in mob_droplist using the bcnm_info's lootdropid as the dropid, although this will need work because on ffxiclopedia the bcnm loot is in groups and can only obtain 1 item from each group. Maybe adding another column "group" or something in mob_droplist could solve the problem?


Alliance code: (Big thanks to onetime for the lesson)
-fixed a bug in bcnm alliance system
-used the correct uint8 values for all party & alliance loops (I understand all that now - mostly should be uint8 lol)
-removed all duplicate if statements- "if (PChar->PParty !=NULL)" and then repeats later in the sub
-It should be top quality now

Hopefully this will dramatically improve server perfomance for alliances.


New GM command @changesjob:
-@changesjob, changes SUB job if your a GM

Please add this wonderfull GM command to the cause!

[whasf]

Thanks, I'm checking this out. I hope to put it on the test server on 8/29

[cipherx]

looks good r1675
http://code.google.com/p/onetimexi/source/detail?r=1675

tnx
link

[PrBlahBlahtson]

Did a run through of The Hills Are Alive, just to test this out. Drops followed the wiki chart, and there weren't any errors I can think of. You're just knocking the big stuff right out, link.

[link]

Diatanato commented on the bcnm loot system and said it wasn't a good solution. I think the loot in the mob_droplist table is a good solution. I don't quite understand using google translate but I think he means this:

The program would fish the items from the database in the same order each time.
example:

(group 5. only 1 item can get picked)
item1(10%) > item2(20%) > item3(40%) > item4(24%) > item5(19%) > item6(7%) > item7(3%) >item8(15%) > item9(11%)


so item9 has very little chance of of getting picked as items 1-8 will most probably get picked before the program reaches item9.

Is this what he means?

A solution I can think of is to add code randomly sorting the droplist before it goes into the picking process.

[diatanato]

(group 5. only 1 item can get picked)
item1(10%) > item2(20%) > item3(40%) > item4(24%) > item5(19%) > item6(7%) > item7(3%) >item8(15%) > item9(11%)

http://en.wikipedia.org/wiki/Percentage

item1(%) + item2(%) + item3(%) + item4(%) + item5(%) + item6(%) + item7(%) + item8(%) + item9(%) MUST BE 100%

[PrBlahBlahtson]

Tried out Operation Desert Swarm today and got loot for Hills Are Alive. Not sure what caused that.

edit: nm, figured it out. ODS still has lootdropid 0 in bcnm_info, because no other BCNM loot has been set up. That'd do it.

Is it preferable to assign arbitrary values to lootid, or match lootid to BCNM ID? I can't think of a situation where a BCNM would have multiple possible loots.

[Flunklesnarkin]

The only situation I can think of that would have multiple different potential loot tables would be the

Aht Urghan expansion ENM's, specifically the Ashu Talif line of instances

I farmed those a lot to sell the rare drops from them.

Depending on your actions during the ENM 1 , 2 , or 3 different chests will appear all with different loot.

Now that is a bit out of the scope for Zilart only development currently. I just thought I'd bring it up to show that such examples do exist.

I'm sure there are more out there that I'm not thinking of, but that one came to mind when you mentioned multiple possible loot.

[bluekirby0]

After my update to it, it is intended to use an arbitrary ID. If you wanted to do something like use a bcnmID that would be fine too. Just make sure the db var is large enough to hold the bcnmid. I suppose if you match them then you can take out the lootdrop id from bcnm_info and junction db queries by bcnmid.

[PrBlahBlahtson]

Re: Aht Urgnan ENMs - Just have to assign different loot IDs to different chests, assuming you used the BCNM system to handle the loot instead of regular treasure chests. I'd have to look closer at what's necessary to see if the core could even handle that right now. It does argue against only using BCNM IDs though.

Re: Arbitrary vs BCNM IDs... 'sokay, I couldn't figure out what "Rolls" represented and where the data was coming from, even after tearing through the multi-nested functions to see what it was used for.