Golly I just love bumping old threads. Don't you? If this post needs to become it's own thread, please split it off. I just thought I'd continue here since it was easy to find.
Some discoveries...
Accepting an Adventure:
After some research, it appears the LDoN code that is currently in the emulator does support adventuring (except for that missing adventure_id offset), and if I interpret it correctly, how it used to work is a group of adventurers accept an adventure - and the "in use" flag goes up, so that particular adventure (and zone) are no longer available to another party. The second party comes along and wants an adventure, and again, the next one not "in use" is offered.
What I need Dev help with is either identifying the actual adventure_id offset in the playerprofile_struct, or as KLS suggested, using the extended profile to store the data for now. What I tried was adding a new value to the extended profile struct, then changing the existing code in client.h from m_pp.adventure_id to the new struct m_epp.adventure_id, but no love. I'm learning, but not fast enough. The bane of my existence is "GetAdventureID()", for anyone who wants to help figure this out.
If I could get more of a hint what else needs to happen for the emulator to globally recognize a new profile variable, I could continue to try and revive this functionality.
Titanium UI (maybe others?):
There is no support for the (newer) "pick your own style", if I remember correctly LDoNs used to be a crap shoot as to what adventure you'd get - and you'd have to decline and request again until you got the type you wanted (Collection, Kill, Rescue, Named). Also, there is no support for Normal or High Risk currently. I believe these toggles are newer than the old LDoN code by Cofruben(?)
Instancing - Nope!:
Next, as stated, there is no true instancing in the Emu yet - but I feel LDoNs could still work based on the above concept of "pick the next in line".
Dynamic Levels:
What I have not yet discovered is how the original developer sorted out the mob levels and/or loot tables for LDoNs of level 20, 30, 40, etc. In Live, I remember the dungeon created itself based on the average level of all party members (or maybe that was one helluva smoke & mirrors performance). The only way I can imagine it was done was each of the 7 or so base dungeons had a hard-spawn of mobs as Zengez stated above. Guka = level 20, Gukb = level 30... Gukg = Raid.
Adventure Time Limits:
"You have 90 minutes to complete your task" - there does appear to be code in place to start an adventure timer. I cannot identify if the 30 mins TO the dungeon, and 30 mins after timeout, is supported. But if not, that's probably the easy part. The expected functionality here is to accept an adventure, run your arse off to the dungeon, and click in before 30 mins is up (which is displayed on the UI if I remember). Then, you have 'x' minutes to finish the adventure. At the end of 'x' minutes, you still have 30 more minutes to ravage the place before you are ported out by the system (zone shuts down?) Again, I do not see this code, but I could be missing it.
Acquiring LDoN Points:
It appears the code is in place to award the party who meets the goal of the adventure, but of course I cannot test this yet. I see code in UpdateLDONPoints and SendAdventureFinish that makes me think this could currently work... which brings me to my next unsupported feature...
Spending LDoN Points:
If I give myself 1000 points and head over to a merchant, I am unable to buy anything. I am not sure if this is not currently supported in the emulator, or if I am doing something wrong because I am trying to cheat. =) Regardless, even without Adventure Merchant support, the savvy admin could come up with a different way to "sell" items to the player for winning adventures. Convert Points to Cash, or Tokens for hand in, etc. But of course, I'd prefer to buy direct.
Leaderboards:
I see nothing at all for tracking LDoN adventure bragging rights. When you click on the leaderboard buttons in the UI, the world complains of more unknown opcodes.
Code:
- Adventure Stats button: Opcode 0x5fc7
- Adventure Leaderboard: Opcode 0x230a
Putting these in patch_*.conf naturally does nothing, because there is no code on the back side to handle them anyway. So this would be a from-the-ground-up development effort to add this, which is the least important imo, but nice to have.
Missing Opcodes
I left this for last, because I honestly have no idea how to identify opcodes coming from or to the client. Example, if you hack the code around GetAdventureID() and manage to fake an assignment, you still cannot proceed to the adventure because of an opcode the client (I think?) is waiting for that is not identified anywhere.
In "Client::SendAdventureRequest()", after successful adventure assignment, wants to send something back to the client that is unknown
Code:
outapp = new EQApplicationPacket(OP_AdventureDetails,strlen(AF.text)+1);
The only reference to this I can find is in eq_opcodes.h and emu_oplist.h, and the patch_*.conf shows 0x0000. How do I find out what this opcode is so I can set it? I do not see any errors or warnings in any logs showing me unknown opcode like the incoming ones do, so I am at a loss here.
Bottom line:
First, without an adventure_id offset in "a" struct, the current code will not work. Re-writing it to add a field to the character_ table is not something I think we should do. Extended profile would be fine for now if I had more input on adding something to the extended profile.
Second, once I DO get that adventure_id, where does the OP_AdventureDetails get created if there are zero references to it in the source?
Lastly, can an actual dev review the code currently in client.cpp and zonedb.cpp and let me know if it's still viable, or should the whole system be scrapped and started over?
Thank you, that is my quarterly update.
-J