'if ( a_check<x> )' functionality detection

[Major Cooke]

So you actually tried it? I just wanted to make sure. Still testing a bunch of stuff on my end to make sure it works.

[Fishytza]

So you actually tried it?

Of course.

Code: Select all

		{
			if( randompick(0,1) == 1 )
			{
				A_Log("jumping");
				return A_State("Skok");
			}
			else
			{
				A_Log("not jumping");
				return A_State(0); //crashes without this
			}
		}

[Major Cooke]

Try moving the return statement to just after the else's closing bracket, see if it crashes.

[Fishytza]

No crash if "return A_State(0);" is outside and right after the two if-else blocks.

It seems to be smart enough to expect a return of some sort if it finds one inside a if block but gets caught off-guard with something like:

Code: Select all

		TNT1 A 0
		{
			if( randompick(0,1) == 1 )
			{
				A_Log("jumping");
				return A_State("Skok");
			}
		}

In this instance, if the if condition is not met then it just crashes. If you add another function (eg. A_SpawnItemEx) after the if block then you get a error at start up "Action list must end with a return statement"

So not only is "return" mandatory even though you don't want to jump, but you cannot use "return A_State" and "return A_Int/A_Bool" in the same action block, else you get this error "Return types are incompatible"

IE this is a big no-no

Code: Select all

		TNT1 A 0
		{
			if( randompick(0,1) == 1 )
			{
				A_Log("jumping");
				return A_State("Skok");
			}
			A_Log("fffff");
			return A_Int(1);
		}

[Major Cooke]

The real bug is "Action list must end with a return statement" is not covering all corner case scenarios. Looks like it's going to need some further checks added.

I'll report this on the bug forums if you haven't already.

[Fishytza]

I'll report this on the bug forums if you haven't already.

Be my guest. Nevermind.

[randi]

So not only is "return" mandatory even though you don't want to jump

Use A_State(0) or A_State("") to signal you don't wish to jump. This is the way all the A_Jump functions are doing it now too.

but you cannot use "return A_State" and "return A_Int/A_Bool" in the same action block, else you get this error "Return types are incompatible"

Because you're defining an anonymous function, it needs to have a single return type. If you try to mix them, it can't deduce which one you really wanted to use and will give you that error.

[Major Cooke]

I think I'm starting to get it. Because custominventory can essentially be used for determining true and false conditions based on pickup/use success or fail, the moment its processed, it's sent back to the owner of the one doing the giving and thus they can use this in A_SetUserVar... Right? So something like A_SetUserVar(user_given, A_RadiusGive(...)) <--entirely speculation, haven't even tried it yet.

[randi]

I think you're confused, and you're confusing me.

[Major Cooke]

Yeah I am. I'm trying to understand how A_Int and A_Bool can be used best... I know you said mainly only useful for custom inventories.

[randi]

Would it help you if I renamed A_Int, A_Bool, and A_State to int, bool, and state so that they look like function-style casts ala C++? Because that's pretty much what they're there for: Declaring the type of the return value.

• If a function returns a non-NULL state, it causes a jump. If a NULL state is returned, no jump happens. Either way, a CustomInventory chain is not affected.
• If a function returns an int of non-0 or a bool of true, a CustomInventory chain will succeed. If it returns 0 or false, that state will fail, possibly failing a CustomInventory chain. If not called as part of a CustomInventory chain, the return value is ignored.
• If a function returns nothing, a CustomInventory chain will succeed.

So use return A_Bool(false); or return A_Int(0); to mark the state as failed. If every state fails, then the chain fails. If any state succeeds, then the whole chain succeeds. (Or if I renamed those functions, that would be return bool(false); or return int(0);)

Nothing about CustomInventory's behavior has changed. The only "difference" is that now you can write your own functions to make it fail.

[Major Cooke]

Nah they're fine. I get they pretty much represent what they say. I just wasn't sure how to properly use them but with that explanation, that clears things up. Thanks for that!

[Fishytza]

I'm likewise fine with how they're named.


Let's see if I got this right.

Within a chain state, if an X determines success then the whole chain succeeds.
X can be a single action function EG

Code: Select all

TNT1 A 0 A_SpawnItemEx("etc")

or it can be a action block EG

Code: Select all

TNT1 A 0
{
    A_Stuff;
    A_Etc;
    ....
}

Now, within a action block the action functions used are irrelevant since what actually determines success of the action block is "return A_Bool(true/false);" or "return A_Int(0/1);".

Assuming I guessed everything correctly so far, what happens if I don't use "return A_Whatever;" or just use "return;"? Does success of the action block depend on what functions were called within it?

[randi]

what happens if I don't use "return A_Whatever;" or just use "return;"? Does success of the action block depend on what functions were called within it?

If a function returns nothing, a CustomInventory chain will succeed.

[Fishytza]

If a function returns nothing, a CustomInventory chain will succeed.

Okay so, to be quite specific:

This on its own doesn't declare 'success' (because it's a jumping function)

Code: Select all

TNT1 A 0 A_Jump(111, "bleh")

while this does declare 'success' because it doesn't return anything, nevermind its contents, correct?

Code: Select all

TNT1 A 0
{
    A_Jump(111, "bleh"); //I know this will never jump, that's not the point
}