MOD Questions: haveitem and REMA

[sgqwonkian]

It's possible the code in your post was a paraphrase to preserve cool secrets of your upcoming mod.


If that's the case, and it's definitely triggering PAGE 1 instead of PAGE 0 (and not just failing to trigger at all, either)...

...then the answer is probably a typo in the CONDITION block or REQ1 line of the PAGE block that you paraphrased, and that when you paraphrased you didn't make the typo.

Possibilities to look for:

It might not trigger (but may crash) if it says TYPE have item, TYPE Haveitem, haveitem {no TYPE code} or TYPE noitem instead of TYPE haveitem

It might not trigger if it says STR0 PS_MUKAMB, STR0 ps_muk amb, STR0 ps_muktamb, PAR0 ps_mukamb, etc instead of STR0 ps_mukamb.
If there's a different new passenger you're using instead of the original ps_mukamb, make sure you have it named consistently in this quest, the game.ini and the the items own .ini file. (I had some things that wouldn't run in a mod once because they were spelled sgqwonk in one place and sqgwonk in another).

It wouldn't trigger if it says REQO not REQ0.

It wouldn't trigger if the paraphrased code above doesn't accurately reflect the PAGE order and you actually have the PAGE 1 block above the PAGE 0 block. It would do the first PAGE it qualified for and stop looking for other pages once it got to the ACTN endquest.

[lexicat]

Wowie! what a bunch of answers. you have correctly guessed that I am leaving juicy details out.

Actually the code I posted works (I noticed that, for example, the Even Weirder Worlds mod is pretty strict about using popups for the ACTN command, but that the basic Weird World quests aren't necessarily.) When I test my mod, whether using popups or no popups, I only and always get the last PAGE. In fact an even simpler quest, in which I attempted to make a single PAGE event occur upon the single CONDITION for TYPE haveitem with STR0 ps_mukamb fails.

My STAR blocks are present, and there's no typo in my CONDITION blocks as you have so thoroughly and helpfully suggested. :}

I am beginning to conclude that haveitem does not in fact test for passengers.

But let me set it down for thisaways: can you make a working quest with a condition testing for a passenger using haveitem?

Lexicat

[sgqwonkian]

Well, I'm not using the 1.22 patch (it makes my mac crash... Fingers and Ed are still trying to figure out why), so I might not be able to for reasons other than what you're facing.

Looking at the files from quests in the main game, i see that there are a few TYPE noitem conditions looking for the absence of ps_mukamb etc (ally_muk.ini for example).


So, you could reverse the order your PAGEs, set the new PAGE0 to trigger off TYPE noitem and TYPE explore, and make sure you include ACTN endquest in it. Then, in a later PAGE entry, you set up just a TYPE explore requirement. That should give the same net result, being that they'll only get that second page if they do have the ambassador.

[sgqwonkian]

...or, you could alter the quest that gives the Ambassador in the first place. Add to it a line of "SVAR mukamb yes" just above or below "ITEM ps_mukamb".
Then in the quest you're trying to make, set a CONDITION block with
"TYPE uvar
STR0 mukamb
STR1 yes"

So there's a couple different ways to work around it.

[lexicat]

What a swell space alien!

Thank you!
Lexicat

[lexicat]

Ok, so noitem works with passenger items, but haveitem does not seem to.

On a more general note, I wonder if it is possible to add an operator to negate any condition. (or just to insure that every condition function has an inverse function)?

Thanks again, squidge!

Lexicat

[Phlagm]

Lexicat, you can't negate a condition. YOu're just kind of stuck with what's already there.

and yeah, haveitem won't work with passengers. Even worse, it won't work with items you install!

-Jeremy

[lexicat]

Well boo!

But thanks for the feedback, Phlagm. So on further exploration it seems that noitem is likewise insensitive to passengers. I guess going the user variable is the way to go.

Lexicat