Resolve conflict in handlers_stage.go: keep lock-free packet
building pattern (copy session list, release lock, then build)
over upstream's in-lock QueueSendMHF approach.
Fix test compilation: remove objectIDs field references after
upstream removed it from Server struct.
Resync vendor directory with updated go.mod dependencies.
Mainly, there are differences in the MHFG low version network protocol when pkt.ShopType=1 or 2 in handleMgMhfEnumerationShop. Conducted code judgment and differentiation processing.
If you need to configure the optional material list among the three options,
Configure directly in gacha_detries
The same Entry Type can be merged and displayed in GG
In addition, the prizes are also directly configured in the gacha-entries table,
MHFG1~GG does not use the gacha_items table throughout the entire process, which meets the lottery function of MHFG with a more single function
In addition, the MHFG function itself is relatively simple
Example of lottery configuration for G1~GG:
eg:
gachaname:test
entry:
itemgroup:
group1:(choose one of the two) ITEM_1_ID:7 COUNT:1 ITEM_1_ID:8 COUNT:2
group2:ITEM_1_ID:9 COUNT:3
reward:
reward1: ITEM_ID:1 COUNT:4 weight:10%
reward1: ITEM_ID:2 COUNT:5 weight:90%
table:gacha_shop
|id|min_gr|min_hr|name|url_bannel|url_feature|url_thmubnail|wide|recommendded|gacha_type|hidden|
|1|0|0|test|null|null|null|f|f|3|t|
table:gacha_entries
|id|gacha_id|entry_type|item_type|item_number|item_quantity|weight|rarity|rolls|frontier_points|daily_limit|name|
|1|1|0|7|7|1|0|0|0|0|0|null|
|4|1|0|7|8|2|0|0|0|0|0|null|
|5|1|1|7|9|3|0|0|0|0|0|null|
|8|1|100|7|1|4|1000|0|0|0|0|null|
|9|1|100|7|2|5|9000|0|0|0|0|null|
