Assault Rework
#7947
Replies: 1 comment
-
|
I've been largely successful in containerizing assaults, but I've quickly realized that instances should be containerized per category. Instances have a few use cases:
Each should possess their own individual framework I believe, to avoid cramping instance.lua; not to mention they all have their own unique behavior and interactions with the instance framework. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Note
To preface this discussion, there's very little that's been done in the scope of assaults, so any kind of changes won't be massive work - or undoing - it will simply be laying down healthy groundwork for things to come.
Assaults, as they currently stand, function well with the instance system, and I don't see any bugs reports related to assaults, but then again there aren't many assaults implemented in order to get a large sample size.
Moreover, the proposals and suggestions I bring up are tasks that I will happily take on. I wanted to open the discussion on how to best tackle and handle these issues.
After delving into the code for assaults, here is some feedback and suggestions for a "revamped" assault system.
1
Assault IDs for mobs are messy, they're not in succinct tables, and can be awkward to work with with the new dynamic ID lookup. Moreover, several assaults use mobs that share names.
I would propose moving a majority of these ID handlings into the individual assault's lua - "golden_salvage.lua" for instance. Where the original zone ID file can store one initial ID for the assault, and using the dynamic ID lookup use offsets to access the mobs needed for the assault.
1.5
Many assaults use shared NPCs that behave as doors or blockages to certain tunnels to craft a unique map. Putting these in the assault's lua would also be beneficial for maintenance and readability's sake
2
Loot is another daunting thing if you've ever looked into it. All loot from assaults + nyzul is kept in one file: appraisal.lua
I would propose moving these loot tables into their respective assault luas if possible in any way. This would make code more readable, auditable, and maintainable in the future. I believe Nyzul might be the exception where one file would be appropriate to store the data as they're NM based drops and not per-floor, or unique sessions.
Potential Difficulties
As of now all mobs and NPCs for all instances and assaults alike are stored in instance_entities.sql. This may be something we'd want to move away from as it can create difficulties when it comes to ID shifts.
Some assaults have extremely unique properties, like NPCs turning into mobs, which has resulted in the database having NPCs and mobs share IDs. So the discussion on how to properly handle it may be complicated and able to be solved through several different approaches.
Therefore writing C++ could prove beneficial for some assaults, however I think it wise to avoid this. As some behaviors can be worked out using DE or other lua implementations. But I'd love feedback on the matter.
To Wrap Up
I think it wise to update assaults to look and behave similar to jmcmorris' rework of BCNMs, where much of the BCNM's content is stored in the individual assault file, and not strewn across several different files. This would create an easier environment to produce and get these assaults up and running.
Beta Was this translation helpful? Give feedback.
All reactions