[suggestion] Different quest requirement/lock-out of quests handling
Darkmega18 opened this issue ยท 6 comments
So I'm been derping around trying to work out 3 input logic gates, when it I just eventually said "balls to it" and decided to come post this. Essentially I'd like to ask if you can change how the quest requirement window works or atleast have an option that enables an advanced requirements option, by basically allowing the player to select all quests that are related to a quest and then mark them as if they are either "needed" or "Need one of" or "need some of" or "Don't do".
Basically i'm writing a story to the modpack in my quests and I was interested to have a different pathway be presented at the time of the quest being gained if a certain hidden quest was done earlier on. Basically a standard path and a more revealed path with different wordings and rewards that would lead a slightly different chain due to the interaction with the quest giver having been read.
So I was thinking in the requirement window, do away with the logic gates and instead have in the requirement window a small box next to each quest that you add to the requirement window of the quests.
so like say:
{A}[quest one]
{A}[Quest two]
{X}[Bad guy quest]
in this case it requires quest one and two to be done, but if the bad guy quest was done it would instead lock the quest out and you wouldn't get it cause one of the negative requirements if fulfilled and you'd probably have another quest somewhere to handle the consequences or new path. they could be set to O which would mean quest 1 or two done would unlock it but X would still lock it out.
Also, then you could define blocks and then move the quests around within the blocks which have parameters which have values like Lock out quest if done, Required to be fulfilled or Require one to be fulfilled. so say:
{A}(Parameter box 1, have atleast 3 of these done)
{O}[Quest 1]
{O}[Quest 2]
{O}[Quest 3]
{O}[Quest 4]
{O}[Quest 5]
{A}(Parameter Box 2, both of these done)
{A}[quest 6]
{A}[quest 7]
[lock-out](Parameter box 3, not done 2 of these)
{X}[badquest 1]
{X}[badquest 2]
In this case, you need both box 1 and 2 done. Box one needing an amount of contained quests, in this case 3 out of 5 to be done. Box 2 requiring that all it's contained quests be finished... But the not box of parameter 3 has two quests that if both of them are inadvertently done the quest is locked out.
Cause in the the off case that I wanted to do such a quest where I'd have to hunt down a pair of bosses and get loots and have a good standing by having done 3 quests in this group of quests that happen to be for a faction say I can do this current quest which is the conclusion of it. But if it gets locked out, well, gonna have a bad time or miss out on some rewards although the bad quests might've had some equally enticing rewards that could have locked you out.
If I want to do this currently I don't think any number of dummy quests can tell a quest that you need atleast 3 of these. it can certainly tell you to have all of them, or only one of them or none of them, but not a few of them. I could probably dummy quest the two bosses and the bad guy quests tho but then it gets messy and stuff...
Is this clear as atleast slightly murky water? :V Just some flexibility there, rather than these hardcore ands, nots, ors and stuff. Cause my head is ripping in peace cause I want to do something slightly different than normal. :V
Well you'll be glad to know that I already have this planned:
https://github.com/Funwayguy/BetterQuesting/blob/1.12/src/main/java/betterquesting/api2/questing/IQuest.java#L41
Eventually BQ will have a sudo scripting support in that you can query a ton of different things at any given time. There is just a LOT to do before I can implement this including burning down the rest of the legacy GUIs and expanding the API to be able to deal with these kinds of advanced conditions. There's also the problem of making sure that existing modpacks don't breakdown when upgrading from the old logic system to scriptable quests. It's a slow process I know but I can't just drop this functionality in.
well dang, good on you. I look forward to giving it a shot. cause was about to also suggest quest mutual exclusivity cause of having multiple versions of a quest stacked on a single spot, so if one is active the rest become dormant and stuff. but alrighty, I hope it goes well. :) in that case, time to just make do for a time and go try some reward based structure spawning...
If you're talking about optional quests that's aready possible with xor logic but it's still a bit messy
well, yeah, you can do it with an Xor, the "if this quest is done, this quest can't" deal. but I'm more like, just hiding multiple quests on the same spot in the design window but only ever having one display based on the quests gotten to unlock it. so that when it unlocks and appears when using UNLOCKED hide mode, the rest of the quests won't appear under or over it. it's a neatness and being tricksy based thing. kinda like how in mine just now if I could i'd have this quest be worded differently but still take up the same spot for progression as the other if a hidden quest was completed before the standard version was done, and then lock out the hidden quest too so the underlying different consequences/differently worded one wouldn't appear anymore. then the next quest would just use an OR and be a direct continuation without fluff so to obscure the fact that either of the two ways would have unlocked it.
Also worldedit still won't fire when using command rewards. I'm guessing they're locked out of being used by simulated players or when being used remotely cause they need location data and player data like loading the schematic to it's clipboard and loading at the players location or mouse pointer and stuff... D:
BQ can simulate player coordinates just fine in command rewards and it isn't classified as a fake player. They must have additional checks outside of the standard command permission. If that's the case then I don't have a lot of options to resolve it.