Grim 1 function arguments

Talk about creating Grimrock 1 levels and mods here. Warning: forum contains spoilers!
Post Reply
RayB
Posts: 94
Joined: Fri Mar 06, 2015 3:45 am

Grim 1 function arguments

Post by RayB » Fri Mar 01, 2019 6:57 pm

In Grim 1, I was having trouble passing arguments to functions in another script so I placed a small script in a test dungeon I created for such purposes. I found that as long as the function I was passing the argument to was in the same script everything worked fine but if the receiving function was in a different script in would not work. I seems the argument gets passed as a table.
I could understand this if I was passing an array or table, but I would think that a string or number value would get passed as a string or number. Needless to say, in the receiving function 'pt(a)', the error -attempting to perform arithmetic on a table value- is generated in the second line. Can anyone tell me why arguments get passed as a table when calling a function in another script? What I am doing wrong?

Code: Select all

	function argTest()		--main function
		local n = 10
		n = pt(n)
		print(n)		--> (prints 15)
	end

	function pt(a)		--called function
		return a + 5
	end

But if  'function pt(a)'  is placed in another script ( call it  'test_pass' ), it does not work:

	function argTest()		--main function
		local n = 10
		n = test_pass:pt(n)
		print(n)
	end

-- <OTHER SCRIPT> 'test_pass'
	function pt(a)	--called function in script 'test_pass'
		return a + 5	--error generated here
	end

Zo Kath Ra
Posts: 731
Joined: Sat Apr 21, 2012 9:57 am
Location: Germany

Re: Grim 1 function arguments

Post by Zo Kath Ra » Fri Mar 01, 2019 7:44 pm

Short answer:
test_pass:pt(n)
should be
test_pass.pt(n)

More info:
https://stackoverflow.com/questions/491 ... and-in-lua

User avatar
Isaac
Posts: 2836
Joined: Fri Mar 02, 2012 10:02 pm

Re: Grim 1 function arguments

Post by Isaac » Fri Mar 01, 2019 11:25 pm

Addendum:

Most calling functions will send themselves as the first argument, so (for instance) buttons/levers, and plates, will give their own reference to the functions they are connected to, when they trigger them.

Image

When you call a function that exists within the same script, it is visible by name, but when you call a function in a separate script, that needs the full path to the function, and you can choose the calling convention. One can write their custom functions to not break if the first argument is the caller instead of expected data or parameters.

**Another function tip: Function names that have underscores in their names do not appear to outside callers; it's a feature, not a bug. You can use an underscore in the name for internal functions that are never called from other scripts, and won't clutter the list used for connectors, when choosing from the editor.

Post Reply