Cumulative Ignore/Listen

Pulp
1

Hi,
I just stumbled over a weird thing with the ignore/listen commands.
Ignore/listen commands appear to "add up"
I assumed Ignore/listen was an on/off switch; 1 or 0.
But it appears that if "ignore" is run several times, "listen" has to be run an equal amount of times to re-activate controls.
Maybe it is intentional, but i cannot see why.

As the simplest example, say, I create a new game.
Into the script for the room I put

on load do
  ignore
end

Control input is ignored. Great.
Now i change the script to:

on load do
  ignore
  listen
end

Control input is recorded. Still great.
Another change:

on load do
  ignore
  ignore
  listen
end

Control input is ignored. "listen" reverts one "ignore", but the other one stays in place.
And:

on load do
  ignore
  ignore
  listen
  listen
end

Works to override both "ignore"

5 Likes
2

This is an interesting find. In one my Pulp projects, I'm having a problem where occasionally it doesn't respond to player input anymore. I suspected the listen wasn't being reached in my PulpScript but the log shows it is indeed getting to that event.

I am now thinking that what you have discovered could be exactly what's happening here. I think I may start logging cumulative ignore/listens in my game to see if there's a mismatch when the bug happens.

3

I believe it's intentionally designed this way, because there are situations where one script sets ignore while another script has already set it. If nesting weren't possible, then input would be immediately re-enabled as soon as either script called listen when the desired behavior is (in almost every case I can think of) to wait until after both have called it.

The tradeoff is that you have to be a little extra careful to match up your ignores with your listens, but it's a lot easier than dealing with the bugs that would exist otherwise. That's Programming™!

2 Likes
4

I already suspected it must have been intentional.
Maybe it makes sense to clarify this in the documentation? Because I immediately assumed it was an on/off switch. But then again, i am DEFINITELY not a programmer.

5

This is good to know. Thanks!

6

Oh my goodness. I have to thank you for discovering this. I thought I was being clever by doing this in my code:

on loop do
	// I wonder if this will cause perf issues - maybe i should only check when i need to?
	if event.ra==0 then
		IS_CRANKING = 0
	else
		IS_CRANKING = 1
	end
	
	
	if GAME_OVER==1 then
		tell event.game to
			call "reset"
		end
	end
	
		
	if IGNORE==1 then
		ignore
	else
		listen
	end
// ....

So that I could set IGNORE to 1 or 0 anywhere and handle ignoring / listening in one place. But I had this logic in a loop, so my ignore calls were stacking! I could not for the life of me figure out what was happening.

Cheers!

1 Like
7

OMG thank you. This really needs to be documented in the manual, I was banging my head against this, not understanding why input wasn't being turned on again.