Changed how share progress work #1570
Conversation
|
Thanks for your time on this. I'm confused about a few aspects of the request:
|
|
Pushed some changes:
About questions: Parties and DungeonsXL friends are calculated before quests iteration but its possible to add some options to filter them at quest-level, so you can decide which friend to use per quest. |
|
Continuing our Discord discussion, I found time to experiment using multiple game instances. It actually seems your original methods (in master) are working just fine. All share levels function correctly (tested Break Block and Kill Mob), and I was able to get the Catch Fish objective that you and DeadlyKill had problems with working, see 87d847f Am I missing something? |
|
You can see clearly that there is a problem with this setup:
When you try to fish can happen a lot of things based on how quests options are setup: double incrementation, share only same quest not working And most important, if Player A doesn't have a quest or doesn't trigger it, the quest of friends doesn't increase. (Player A no quest, Player B fish quest, Player A fishes, no increase) |
|
Thanks for the clarification. Just went fishing and had no trouble with either situation. Player A and Player B both had different quests each, both with a Catch Fish objective, and they all incremented after catching one fish. I also tried Player A with only one quest and Player B with both, worked fine. Didn't experience any double incrementation. Even Player A having no quest also worked like a breeze - Player B received progress for the catch. I'm just not seeing any issues. My testing setup is as follows.
Quests file: https://pastebin.com/nbBDKysC |
|
I am not able to replicate it with your files: when I use the fish rod, automatically increase quests of the members to 2/2 and 2/3. So I changed my About About double incrementation one, its replicable with the same config but with the opposite player:
|
|
For the same-quest-only issue, that's the intended behavior? The "left" quest has I was able to replicate the double incrementation there. Please see my commit 49da2b0 for a tested fix of Break Block only. |
|
No, its not the correct behaviour. Same quest true means that the quest must be incremented only if the other player have the same quest.
About the double incrementation, the issue is fixed but its a work around :P
The multiplayer dispatch will be triggered only on the first one (your fix), and will increase correctly A and B: |
|
Thanks for your patience, but I thought the other player does have the same quest? At least, it looks that way from the screenshot: Unless you mean to say that the second player should have only the same quest, and no others. In which case, we have different interpretations of how that setting should work. Imo forcing the player to exclusively hold a certain quest should be enforced with quest blocks, and maybe the I'll go ahead and test that ABC scenario, but I think you're probably right. Will update soon. Edit: You were correct. See latest commit |
|
The meaning of |
|
OK, that's what I thought. It appears to be working correctly, then. |
|
Tested a little bit, with this quests.yml its not working properly: https://pastebin.com/N0dJapNe Quests: Test1 (share true), Test2 (share false), Test3 (share true) Its not increasing the quest Test3 |
|
I'm not able to replicate that issue using your sample. PlayerA breaking an IRON_ORE block worked fine:
Only the test2 quest did not increment, which is correct in this scenario (because PlayerA does not have that quest). Edit: For your convenience, https://ci.codemc.io/job/PikaMug/job/Quests/201/ |
|
Test2 should increase by one because the option So any iron break event should increase that quest.
Right now its behaviour is like About my previous test, probably I confused Test3 with Test2. |
|
Sorry for the misunderstanding. I see what you meant and have made another attempt. See dcb0d8f |
|
Perfect now it works if PlayerA always have at least one quest about block break :) But in the case PlayerA doesn't have any quest (or for example he already completed one) after a block destroy, PlayerB quests don't increase. |
|
I would say that's acceptable. Even as a Party member, they ought to be participating in quests somehow. In other words, we can interpret |
|
I don't really know, that would be a good feature. To avoid the "free labor" thing you can setup a distance, so the quest is shared only if you are near the main quester. Another great way to use the same-quest-only false is when you have a big quest like: Break 1000 stone. Player A is 800/100 and Player B is 900/1000. I mean, personally I would prefer the |
|
As pure example on my Server docs is. I have a Custom item that has 0.1% drop chance on my server and it gives special quest to the player that is to kill world boss. The way my server handles World boss is. It requires 20-30 people Raid in order to be able to have any chance versus this Mob. Leaving it 1:30 ratio chance for this player to be able to Last hit the Boss and get the quest done. In such case scenario when not having same-quest: false option. This would be nearly impossible to make as nobody can keep track on boss that has 3-4 Million hearts and it takes decent 30-40 minutes to kill. Other example of that would be like Alessio mentioned. Large quests like Mine 1000 Stone or even Mine 50,000 Stone. It can significantly help so people can help each other even when one of the players has finished the quest already or another person it's not eligible for it. We spoke with Alessio about the Distance feature. Which can pair with same-quest: false. Leaving it like Only party members within 50 blocks of Quester to benefit progress to his quest. Which means. If you ever have "labor" in your server you would need to have them near you in order to "work for you" In general same-quest: false option would benefit a lot those "rare tier" quests that are obtainable only through non-traditional quest obtain methods... |
|
As for Options 2-3-4 from current quest. They were originally added but made no sense at all to be used ever. The way new Parties branch and code from Alessio seemed to do perfect job while we was performing the tests. I'm personally thinking the way Alessio branched the stuff is more efficient and better to use. And the option Everything in my opinion should be basically the only one available. |
|
Thanks for the input @DeadlykillOfficial and yes, many popular games use the One might say those are niches and the The (seemingly) final issue is the example from @AlessioDP
If Player B no longer has a quest and |
|
We've spoke with Alessio and got into conclusion that initially the current parties branch does all the job without any issues and it handles stuff differently and Alessio can add different options later on including the Distance option and many more. From my many years experience of MMORPG games. And my entire Quests experience and my time since Parties were introduced to quests. I've honestly never heard anyone ever having usage of Option 2-4 for Sharing. Everyone mainly uses "Everything" as this is the most understandable Quest sharing option that 99% of RPG games have and it's accepted as normal sharing way. As for Boss example. The Quest was entirely Exclusive rare quest. That's available to 1% of players in the server. Which means from 30 people raid. There will be most likely only 1 person that will have the same quest. Therefor same-quest: false is required. |
|
Also same-quest: false can help a community quests. Which are basically Master tier Quests including custom plugins. |
|
Could you briefly explain what's stopping you from pulling Alessios rewritten system of how entire MP works and it's fully tested every event everything. And then letting him basically add the features later on. As Stages/Objectives and etc. We are having Discussion and trying to find solutions of already fixed thing and already coded. Yes, at the moment it's missing several Quests default options but they will be readded shortly. Could you explain why you are trying to fix and keep the old code of something that has not been working for so long and even right now, it's not working as originally intended. While the new code does exactly what it's supposed to do and it's coded in a way for easy expanding on it's features. |
|
I see that the old system can be tweaked and fixed so it works but is it really necessary? I can implement the share level thing in the new one too xD About the "no-quest player that cannot help others": its the same thing of "same-quest-only":
If Player A breaks a stone, it will help Player B to progress. This thing works. |
|
@DeadlykillOfficial I expressed this in my first reply: removing features seems unnecessary if a reasonable alternative exists. I was totally prepared to accept this PR if it came to that, but I've found a solution that lets users keep the current level of customization. Your examples make sense for a standard WoW-like quest, but the ultimate goal of this plugin is to let users design quests however they like. If an operator wants players to independently mine 50000 stone, but award everyone at once when somebody hits that goal (like a contest), removing the other options makes that implausible. Imho the few ms performance benefit of this PR is nice but not substantial enough to outweigh perceived benefit. @AlessioDP If you're able to implement the old features as well, by all means. I appreciate both of your input and the effort you've put in here. Should my solution have some major unforseen issue, we can certainly come back to this PR. |
No description provided.