Using two inventory items on one hotspot (separately)

[TheVolumeRemote]

I’ve searched for a long while on the forums and in the manual as I’m sure this is covered somewhere but alas, I can’t find anything or figure it out!

So I need to use two inventory items on one hotspot to make a fire.

Use matches with hotspot
Use lighter fluid w hotspot
Hotspot becomes visible and animates

I don’t want to combine the items if I can avoid it. So how do I add an inventory item to a hotspot, take the inventory item away w LoseInventory and then when the second item is used, tell AGS to go ahead and make the hotspot (fire) visible?

Also I don’t need the player to use one item before the other, either the matches or fluid can be used first.

The roadblock I’m hitting in my ideas and similar issues that I did see posted is regarding hasinventory. Because I’d like the inventory item to be gone after one use, checking the inventory status doesn’t help since the player could have already say, used the fluid (on the hotspot) and therefore won’t have the fluid on them anymore.

Thank you so much for any help. Here is the code I used that for several reasons will not work, using activeinventory and not hasinventory, not combining them if this was the route I wanted (it’s not) and so on. I guess I just wanted to show I’m trying and to give whoever reads this an idea of what’s happening. Thank you

Code: ags

 
function hFirepit_UseInv()
//This very obviously wont work unless I have the player combine them which i'm trying to avoid
{
  if (cEgo1.ActiveInventory == iFluid && cEgo1.ActiveInventory == iMatches)
  {
    cEgo1.Say("Alight let's make a fire!");
    cEgo1.FaceDirection(eDirectionUp);
    oFire.Visible = true;
    oFire.SetView(VFIRE);
    oFire.Animate(0, 4, eRepeat, eNoBlock, eForwards);
  }
  else if (cEgo1.ActiveInventory == iFluid)
  {
    cEgo1.Say("I still need something to ignite it with.");
  }
  else if (cEgo1.ActiveInventory == iMatches)
  {
    cEgo1.Say("I'm going to need something to help start the fire. The wood is too damp.");
  }
}

[arj0n]

Code: ags

// room script file
bool matchesUsed = false;
bool fluidUsed = false;

function startFire()
{
  cEgo1.Say("Alight let's make a fire!");
  cEgo1.FaceDirection(eDirectionUp);
  oFire.Visible = true;
  oFire.SetView(VFIRE);
  oFire.Animate(0, 4, eRepeat, eNoBlock, eForwards);
}

function hFirepit_UseInv()
{
  if (cEgo1.ActiveInventory == iFluid)
  {
    if (matchesUsed == false)
    {
      player.LoseInventory (iFluid);
      fluidUsed = true;
      cEgo1.Say("I've put the fluid over the firepit, now I still need something to ignite it with.");
    }
    else if (matchesUsed == true)
    {
      player.LoseInventory (iFluid);
      startFire();
    }
  }
  else if (cEgo1.ActiveInventory == iMatches)
  {
    if (fluidUsed == false)
    {
      player.LoseInventory (iMatches);
      matchesUsed = true;
      cEgo1.Say("I'm going to need something to help start the fire. The wood is too damp.");
    }
    else if (fluidUsed == true)
    {
      player.LoseInventory (iMatches);
      startFire();
    }
  }
}

[Crimson Wizard]

EDIT: well, arj0n posted quicker than I finished typing, but I just leave this as a general note.

When there's something that updates its logical state multiple times - the straight solution is: variables.

Create a global or local room's integer variable, and increase it for every correct item used on object. When it reaches certain value - trigger the fire.

This also allows you to change responses when player looks or interacts with the campfire, for instance: test if variable == 0 - it has nothing, if variable == 1 - it has fluid, and so on.

If some another situation allows several items to be applied in any order - and you also want to distinct these states - you may either use a group of variables (applied item1 true/false, applied item2 true/false, etc), or as an advanced method combine values using bitwise operations (this is an oldschool programmer style).

PS. Alternatively, you may use object's Graphic as a state (given each state has a different one). That won't help if you need to check object's state from another though.

PPS. Alternatively, there are Custom Properties, but with the way they work in AGS right now they are more useful when multiple objects have similar states.

[TheVolumeRemote]

Thank you so so much Arj0n and Wizard, you are amazing. It’s quite a community here thanks to mates like you both.

Arj0n, thank you so much for the code, it works wonderfully (of course)! Really kind of you to take time out of your day and write that all out

Wizard, thank you so much as well- I’ll keep all that close to mind going forward, I’m sure I’ll need it again soon! In fact the next puzzle slash ‘thing I haven’t done yet’ is an inventory combining puzzle (with 5 different items) and I’m sure I’ll need to keep track of where everything is, so thanks again that will really be of help to know.

[Manu]

In my case, I did the same using the custom properties. As a beginner, I found them more useful than code variables, because I can define them and set the default value with the GUI. Also, it's very handy to be able to see the list of all possible properties in the property definition screen.
I know it's ugly that all objects/characters etc share the same custom properties, but on the other side, having just one list is easier to manage (I guess things become complicated if you have a big game with a lot of rooms and objects).

[Khris]

You can define global variables in the editor, in the project tree's section "Global variables".
You can set name, type and initial value using a GUI.

Like CW said, using custom properties only makes sense when many hotspots/objects/etc. need the same additional property.

[Cassiebsg]

Custom properties have another disadvantage, and that's that they don't show up on the auto-complete, so you either know the exact name you used or one needs to constantly go check it. For this reason I only use them when it's the best solution. Otherwise... global variables! 

[Crimson Wizard]

Custom properties have another disadvantage, and that's that they don't show up on the auto-complete, so you either know the exact name you used or one needs to constantly go check it.

You can declare a macro for your property's name, and use that instead, then you should get auto-complete:

Code: ags

#define CHAR_CUSTOMPROPERTY "CustomProperty"


cChar.GetProperty(CHAR_CUSTOMPROPERTY);

[Manu]

Nice trick! I'm going to use it