Undocumented object variable?

I was reading Help with Oscillation Function in Pulp and I noticed Terry using this pattern:

aboveTarget = sTargetX,aboveTargetY
nameAT = name aboveTarget

I tried it out, and it works in browser, in simulator and on device! Test snippet:

xy = 8,7
tile_name = name xy
// This first say works
say "tile_name: {tile_name}" then
  // This second say causes a crash
  say "xy: {xy}"
end

According to the pulpscript docs "variables can hold a number or a string", and there is similarly no mention of this pattern under the functions type, name, etc.

Logging out the value of xy in browser gives [object Object] and attempting to format xy into a string causes this crash on the simulator (and similar on device):

Update error: invalid value (table) at index 6 in table for 'concat'
stack traceback:
	[C]: in function 'table.concat'
	?: in function <?:77>
	(...tail calls...)
	?: in upvalue '?'
	?: in function <?:1465>
	(...tail calls...)
	?: in function <?:1365>
	(...tail calls...)
	?: in upvalue '?'
	?: in upvalue '?'
	?: in upvalue '?'
	?: in function <?:3743>
09:52:00: Update failed, simulator paused.

Is this an intentional feature of pulpscript?

I would guess not and might want fixing given the string formatting bug, but it is interesting that it works with the name function!

2 Likes

Resurrecting this thread just because it was linked to in Discord recently :slight_smile:

It's pretty cool you can assign pretty much anything to a variable. Under the hood (when the pulpscript gets converted to its actual underlying data format), these can then get converted into different types - just as you have a value that's a number, or a variable name, you can also have an "xy" type (for n,n pairs) and a "rect" type (for anything with more than 2 values, including n,n,n). This is what other commands use, as required.

For instance, these all work:

  x = 1
  y = 2,3 // converted to "xy" type
  z = 2,3,4 // "rect" type
  aa = 1,2,3,4,5 // also "rect"
  bb = a"Hello"123 // "wtf" type... no, actually treats as a var called "a\"Hello\"123"
  cc = "Hi there",1,2,3 // "rect" - the first arg is not treated as a var
  dd = event.room,event.px,event.py

The pulpscript parser then normally checks to see if the number of args is valid for a command, so you can't have goto my_xy for example, as goto needs 2 arguments.

But there are then a few commands which take either 1 or 2 arguments - either an ID, or an X and Y pair. In these cases, there's a grey area where the pulpscript parser accepts a single argument because it has to, but doesn't check the type. When it actually runs the command, it effectively uses the "2 args" version though, eg my_xy is a lookup to an xy type, which then gets used for the command.

I haven't tested these except for tell (which seems to work), but in theory it could/should work with:

  • type
  • solid
  • tell

(id doesn't work as the parser checks for a string if there's only 1 arg.)

(frame takes 1 arg as well as 2, but 1 arg is used to set the frame instead, so this doesn't seem to work - each command can handle its args differently.)

(random takes 1 or 2 args, but not 2 as an xy-type arg, so gets confused.)

No idea if it's useful! I tried it, but generally find I need to modify one or both of the values at some point, so end up separating it out anyway. Might be useful for custom event handles that want to take an x and y and not manipuate them, though.

1 Like

ok, one reason not to use any of this cursed voodoo is because it can lead to weird variable assignments. Try this for instance...

	xy = 2,8 // location of 'computer' tile
	myName = name xy
	randomVar = 5,11 // location of 'disk' tile
	myName2 = name xy // xy is now 5,11 !?
	
	xy = 2,8
	myName3 = name xy // back to 2, 8

I'd look into it more but I feel like Pulp is just punishing us :laughing:

1 Like