NPC Activation Checks and Displaying Items in Battles

[Pepsi Ranger]

Okay, as the header suggests, I have two questions:

1. Is there some efficient way to give NPCs multipurpose activation, or to check how an NPC has been activated?

I have a couple of locations in my game where the NPC should allow for at least two types of activation, and the hero's response depends on whether the NPC has been "used," "touched," or "stepped on." As of now, I have to use some complicated NPC switching and keyval checks to make everything run kind of by plan, but the nature of the scripts often means that triggering can happen only under certain conditions (like, if the menu is accessed on a particular spot, then everything breaks).

I decided to rewrite one of my scripts to check whether the hero is walking or not (hence, to fake read whether the NPC is activated by touch or use) and trigger a response that way, but "touch" NPCs don't seem to register "hero is walking," and regardless whether I use "touch" (which is supposed to send the hero onto a tile and then trigger a response) or "use" (which is supposed to make the hero "use" the tile where he's standing--a completely different response than the one activated by touch), the script assigned to trigger on "use" is always run.

I know the workarounds--surround the trigger NPC with "step ons" and assign them a keyval script that registers whether the player hits one of the use keys or not (or maybe a "wait for key (use key)" would be more efficient) and then trigger the script that would normally work under a "use" bit, but they don't do much good when the script essentially disables their functions after one use and the player has to walk off the tile and back on just to use it again. It's stupid.

Is there some way to check whether an NPC is triggered by "use," "touch," or "step on" in plotscripting? If not, can we have one? Or, could we just have an NPC that allows for multipurpose activation (i.e., a step-on NPC that can also be "used")?

I'm not saying I need an NPC to react differently if I walk into him versus actually trying to talk to him, or, in the case of one of the objects in my game, walk over a very tiny object without notice, or actively pick it up because you do notice it, but it would be nice to have that option.

2. In item menus triggered during battles, is there a way to show only those items that can be used in battle?

I'm playtesting RMZ's Mr. Triangle's Adventure, and my items menu is getting rather cluttered. Autosort does help keep most similar items together, but it doesn't block out the clutter of useless items that I still have to see when trying to figure out what I want. Is it possible to clone the regular items menu to create a special battle items menu, but show only those items that can be used in battle?

If there are already methods in place for doing this, then I don't know about them and I'd like to know how to get them to work. If they aren't in place, I'd like to put both of these up for request (and soon).

Thanks.

[TMC]

Part 1:
But step-on NPCs can't be activated with the use key (IIRC), and while touch npcs can be activated in 2 ways, there's little difference between them. But you can distinguish between them easily by checking whether the use key was pressed (technically you should check whether it was pressed the previous tick, as there's a one-tick delay before the NPC on-use script is triggered). On-touch npcs can be activated while the hero is stationary, so checking that doesn't help.

To allow using a step-on NPC you could write a script which tries to activate a step-on NPC in front of the hero when a use key is pressed; it should be fairly simple. However, I think that the specific use you have in mind is the lost contact lens in Powerstick Man. In that case a better solution would be to make that NPC a regular activation:use npc and use "set npc obstructs(npc, false)".

However I didn't really understand everything in the question, so maybe you've already tried that.

Surrounding something with step-on NPCs is rarely or never the best solution...

Part 2:
I actually started adding an option for that because other people had the same complaint, but got distracted. The only thing that wasn't clear was how rearrange the inventory after some items are hidden. I suppose it could delete slots in the inventory rather than items, so for example if there are 2 usable items, 2 empty slots, and 3 unusable items in front of an item (it's in the 8th slot), it would appear in the 5th slot in-battle.

[Pepsi Ranger]

Okay, I had a feeling I would need to better explain what I'm talking about.

The contact lens does use the workaround system, and I find that it's okay because you can only interact with it once. The likelihood of facing the wrong direction is still lame, but I don't see it being a common problem.

But I've implemented a much more complicated piece later in the game that requires the same type of interface. Rather than trying to explain it, I'll just show you the footage in action.

Keep in mind that it uses the workaround, which is functional, but only under perfect conditions. The player can break it easily:

<object width="640" height="480"><param name="movie" value="http://www.youtube.com/v/8YgEKJJKdig?ve ... ram><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/8YgEKJJKdig?version=3&hl=en_US" type="application/x-shockwave-flash" width="640" height="480" allowscriptaccess="always" allowfullscreen="true"></embed></object>

Your suggestion is similar to the workaround. The way it currently works, you're supposed to be allowed to walk onto the hatch, to which Powerstick Man comments on the noises he hears. Why not just block it off? Because it's flat to the ground. Blocking it off would make no sense. However, to open it, he should be able to trigger it from the side, like he would any other object. As you can see in the video, what happens when he triggers it depends on how he triggers it.

To achieve what you see in the video, I have to make the hatch a step-on NPC, but I also have to surround it with step-ons in order to call up a looped script that checks for keypresses (Enter, ESC, etc.) and responds accordingly. Walking off the tile will cancel the script, as will pressing pretty much any key. The problem is that once the script is run, you can't use it again without walking off the tile or calling it to loop on itself after the follow-up script is run, which I wouldn't have a problem with if it didn't interfere with timers running in the background. Each time I set the looped script to run again (on the spot), it would either break the script I was trying to access, or double-trigger the hatch opening, never allowing me to progress the story. It's a mess on all fronts.

I had attempted to put a touch NPC on the hatch and write a script that checks whether Powerstick Man is walking into it, or "using" it--walking into it would move the NPC and allow him to step forward--but it would never pick up on the fact that it was getting accessed by touch.

My problem with using "wait for key (use key)" is that it would lock up the script until I hit Enter, which would do nothing different than if I were to just make a "use" NPC, which is something I'd have done if this were just another run-of-the-mill NPC. Now, if there's a way I can write "wait for key (use key)" to check for activation rather than lock the script until it's activated via use key, then I would just do that, which is what I had wanted to do in the first place. That's sort of the Part B to my first question, if there is a way to check for that without locking the script or achieving undesirable results.

Hope that's clearer.

[Pepsi Ranger]

Okay, I thought more about what you were saying regarding suspending NPC obstruction and realized that if I place a touch NPC (or a use NPC, which probably makes more sense in retrospect) on top of a step-on NPC and use a zone to determine whether the touch NPC should be obstructed or not (I can't leave that NPC ID without obstruction forever...on other maps...), I can simulate exactly what I want without even having to check how it was triggered. And it works as intended every time. So thanks for that idea (even if that wasn't exactly what you were suggesting).

I still think there's a benefit to detecting how an NPC is triggered (again, things like getting an NPC to respond to pushing AND casual talking might be desirable to some), but this new workaround will meet my needs for the time being.

[TMC]

Yeah, placing a 'use' and 'step-on' NPC on the same tile is the ideal solution here. If I were going to add a built-in feature for this sort of thing it would be to have an NPC that can be set to activate both by use and by being stepped on, and set you set different effects for each. However, that's hardly any better (and likely worse) than just having two NPCs on the same square. And I don't see any use for a feature to check activation cause while only touch NPCs have two different possibilities.

The scripted one-npc solution is to have an on-keypress script which checks the tile in front of the hero for a certain special step-on NPC (so you don't need setnpcobstructs), like so:

Code: Select all

script, dirX, dir, begin
    switch (dir) do (
    case (up, down) do (return (0))
    case (right) do (return (1))
    case (left) do (return (-1))
    )
end

script, dirY, dir, begin
    switch (dir) do (
    case (left, right) do (return (0))
    case (down) do (return (1))
    case (up) do (return (-1))
    )
end

script, on-keypress, begin
    if (heroiswalking == false &&
          (keyispressed(key:space) || keyispressed(key:ctrl) || keyispressed(key:enter)) then (
      variable(npc, dir)
      npc := 45    # the ID of the NPC
      dir := hero direction
      if (npcx(npc) == herox + dirx(dir) && npcy(npc) == heroy + diry(dir)) then (
        use trapdoor from side
      )
    )
end

You could instead make any step-on NPC usable this way

I don't know why you mentioned used a zone... you're using an map autorun on multiple maps?

[Bob the Hamster]

I have to say, I like the idea of an option to hide non-battle-usable items from the item menu inside battle. That sounds like something I would use myself.

I would make it hide both unusable and blank item slots. I know that would make it harder to manually arrange your items outside of battle to control their arrangement in battle, but that seems like only a minor inconvenience (not big enough to outweigh the bigger convenience gain of the feature itself)

[Pepsi Ranger]

I don't know why you mentioned used a zone... you're using an map autorun on multiple maps?

Don't you have to set an NPC's obstruction value manually, both true and false? I thought switching maps doesn't change the obstruction state of that particular NPC. If the NPC's obstruction resets when I leave the map or even go through a door, then I don't need the zone. Otherwise, the zone allows me to switch it back to normal without having to juggle whether the NPC even exists (as in the case if I leave the map).

And I've discovered that my workaround is prone to script errors if conditions checking for the NPC's existence isn't put into place. A warning to anyone attempting to do something similar.

I would make it hide both unusable and blank item slots. I know that would make it harder to manually arrange your items outside of battle to control their arrangement in battle, but that seems like only a minor inconvenience (not big enough to outweigh the bigger convenience gain of the feature itself)

If the player were to use autosort (or "autosort for battles"), couldn't that feasibly move all of the battle-permissible items to the front? I keep thinking of this feature working in a way similar to how menus hide selections if certain tags aren't on.

Too bad we can't utilize an item category submenu to rank our item preferences for autosort using shift+arrow the same way we arrange menu items themselves. Doing so would allow us to move designated item types according to category. Way too complicated to implement, but it could help make the autosort feature more reliable.

For a visual, moving health cure items to the top of the "item map/chart" would mean moving cure-type items to the top of the autosort. Moving magic cure items to the second slot would autosort them under the health cure slot, and so on.

1. Health Cures (top, manually set by player using shift+arrow)
2. Magic Cures
3. Status Cures
4. One-use Weapons
5. Enemy Debuffs
6. Hero Buffs (bottom -- least important to player during battles)

and so on...

Items would need category tags (labels) for this to work, and like I said, that may be too much work to make it worth it. But it could help to clean up the battle menu once all the non-use items are blanked out.

P.S. If you check out a later installment of my Mr. Triangle's Adventure Playtest Videos, you'll see just how crazy the item clutter gets.

[Bob the Hamster]

That category idea only sounds moderately difficult to implement :)

[TMC]

NPCs on different maps are independent. The only thing of any sort that can be transfers from one map to another is slices, if the "recreate map slices when changing maps" backcompat bitset is off.

You can emulate a category autosort order in two ways: either by placing an icon at the front of every item name and using alphabetic sorting, or by giving the items ID numbers in desired sort order. Neither way is practical in all games. Explicit sort categories would be nice.