Functions are not called

#1 I have had this problem before, although very rarely and I have never been able to track down a reason for it.

Sorry to be of no help :/
I generally just found different ways to do things.

#2 Haven't seen that problem... it sure sounds interesting! If you can post a script that will reliably stimulate that bug I'll try to track it down.

#3 It seems like this bug appears when a script is compiled.

I did not change anything of the playdeathcry function and suddenly it was no longer called.

One file:

echo("SOUND?");
playDeathCry();

...


function playDeathCry(%this)
{
   echo("SOUND!);
   ...
}

Result:

SOUND?

There is no SOUND! and there is no syntax error in the script otherwise the SOUND! would not have been appeared anyway.

greetings
Daniel

#4 Was that lack of a " in the second echo a typo? or is it actualy in the script like that?

#5 This is not the script.
This is just for showing that call and function are in the same file and, as you see only one echo appears, although there has to be two echos.
Because of you get no error, the function must be called, but where is the echo? In fact the function is neither called nor missed and that's the bug.

greetings
Daniel

#6 I haven't tried to find out why, but code in the global context has to be read after any function(s) that code invokes. In the case of your example, if the line that calls playDeathCry is not inside a function, then you should get the console warning "Unable to find function playDeathCry".

Since 99% of scripting code should be inside functions -- basically everything but a little bit in the top-level main.cs -- this hopefully shouldn't be a big problem.

If you're experiencing weirdnesses like that with code inside a function, though, then I don't know what's up. If you can give me a specific example that will reliably demonstrate the problem with unmodified TGE, then I'll go after it.

#7

function Armor::onEnterLiquid(%this, %obj, %coverage, %type)
{
	// The play is gone die if he does not leave the water with in 10s
	$killplayer[%obj]= schedule(10000, 0, "Armor_applyLiquidDamage", %obj, %this, 2000, 10, "Drowned in sea");
	
	ServerPlayRandom3D(%this.race @ %this.type @"EnterOceanWaterSound", %obj.getTransform());
	
   switch(%type)
   {
      case 0: //Water
      case 1: //Ocean Water
      case 2: //River Water
      case 3: //Stagnant Water
      case 4: //Lava
         %obj.setDamageDt(%this, $DamageLava, "Lava");
      case 5: //Hot Lava
         %obj.setDamageDt(%this, $DamageHotLava, "Lava");
      case 6: //Crusty Lava
         %obj.setDamageDt(%this, $DamageCrustyLava, "Lava");
      case 7: //Quick Sand
   }
}

function Armor::onLeaveLiquid(%this, %obj, %type)
{
	%obj.clearDamageDt();
	cancel($killplayer[%obj]);
}


function Armor_applyLiquidDamage(%obj, %this, %damageDelay, %damageAmount, %damageType)
{
	%obj.setDamageDt(%obj, %damageDelay, %damageAmount, %damageType);
}

As you see I had to change Armor::applyLiquidDamage to Armor_applyLiquidDamage, otherwise the function was no longer called.

These functions are uncut and unplugged.

greetings
Daniel

#8 Thats because you are doing the schedule call wrong.

If you want to schedule a function then you do it like you are. If you want to schedule a member function then you must do it like this:

$killplayer[%obj]= [b]%this.schedule[/b](10000, 0, "applyLiquidDamage", %obj, 2000, 10, "Drowned in sea");

might need to use %obj.schedule(...) in this case for it to logically work....not sure try both of them.

also in your applyLiquidDamage your first param needs to be %this for naming conventions and it will be autopassed by the member function version of schedule. (if you noticed I removed the %this in the schedule call)

Here is how applyLiquidDamage header should look:

function Armor::applyLiquidDamage(%this, %obj, %damageDelay, %damageAmount, %damageType)
{
....

-Tim aka Spock

#9 My original version of torque admin encountered this bug.
Basically how torque admin was originally structured was like this.

It would search for all files that were *_admin.cs and make a script object for each one, as each was a plugin, such as BlaAdmin.
It would then exec these files which contained four functions

BlaAdmin::CreateNormalMenu
BlaAdmin::CreateForcedMenu
etc, etc

Then it would run this functions to load in that plugins specific data. It was quite a good system imho and it worked 99% of the time.

Occasionally, I would find that a plugin would not load correctly and it was due to the fact that one of the functions was reverting pack to its superclass function (ie. blank) so that its details were not getting run.

It was a very strange thing becasue there was nothing wrong with the function, if you loaded it under a differnet name it would load.... it was just this odd bug

If anyone would like to investigate this I can give you the version of torque admin that had this bug in it. (It was never released)

#10 Could you mail it to me?

I had many problems with this bug in the last week.

thx
Daniel
dkollmann@futureint.de

#11 In ya mail mate
Good luck on this one :)

#12 @fi, did you read spock's post above? he's right, you are calling the schedule wrongly.. it will never work that way

#13 Hi

I think we tracked the problem.
You cannot add a function to an object.

WRONG!
new ScriptObject(TestMe);
function TestMe::test(%this)

You can only add a function to an objectClass.
RIGHT!
new ScriptObject(TestMe);
function ScriptObject::test(%this)

Now you can call TestMe.test() because TestMe is a member of ScriptObject.

We are implementing an error message for this distinction.

greetings
Daniel

#14 Hi,

I added some code which will prevent that.

Change console/compiledEval.cc:

const char *CodeBlock::exec(U32 ip, const char *functionName, Namespace *thisNamespace, U32 argc, const char **argv, bool noCalls)
{

	:
	:

      switch(instruction)
      {
         case OP_FUNC_DECL:
            if(!noCalls)
            {

		:
		:

		// if no body, set the IP to 0
		ns->addFunction(fnName, this, hasBody ? ip : 0);

		:
		:

            }

	:
	:

      }

    :
    :

}

TO:

const char *CodeBlock::exec(U32 ip, const char *functionName, Namespace *thisNamespace, U32 argc, const char **argv, bool noCalls)
{

	:
	:

      switch(instruction)
      {
         case OP_FUNC_DECL:
            if(!noCalls)
            {

		:
		:

		if (fnNamespace && Sim::getDataBlockGroup()->findObject(fnNamespace))
		   Con::errorf (ConsoleLogEntry::Script, "Functions cannot be added to datablocks! Unable to add function %s::%s (%d)", fnNamespace, fnName, ip);
		else
		   // if no body, set the IP to 0
		   ns->addFunction(fnName, this, hasBody ? ip : 0);

		:
		:

            }

	:
	:

      }

    :
    :

}

cu
Felix

#15 Actually the correct method is:

new ScriptObject(TestObject)
{
class = TestMe;
}

Function TestMe::Test()
{
echo("This is the test");
}

TestObject.Test();

#16 fi: look in engine.overview.txt (this will be in one of the html files too) The correct method is like so:

new ScriptObject(MyObject) {
	class = Bar;
	superClass = Foo;
};

function Bar::doSomething(%this)
{
	echo("Hi!");
}

MyObject.doSomething();
> Hi!

Doh...you beat me too it labrat. :)

-Tim aka Spock

#17 I forgot the SuperClass line.

#18 So, first of all: what Harold and Tim are saying is correct.

Something that might help clear things up and establish why they are correct, and why your code wasn't working (although perhaps it's a case of me having a hammer and seeing everyone's problem as a nail) is a refresher on the way namespaces work w.r.t. function invocations, and on how the creation of objects affects or doesn't affect the namespace hierarchy. For example, when you create a ScriptObject, the name of the ScriptObject does not affect the namespace hierarchy; generally an object name will only affect the namespace hierarchy if the object is a datablock or derived from GuiControl, altho there are a couple of exceptions. See the scripting language reference section on Namespaces.

#19 What you guys have all said is correct but occasionally a bizarre bug does eventuate and it has existed (and still occurs) in Tribes 2.

This bug occurs in the old version of torque admin that I mentioned above even though the script objects were defined as you guys have written.

Let me explain what happens...
Lets say we do the following...

new ScriptObject(MyObject) {
	class = Bar;
	superClass = Foo;
};

function Foo::doSomething(%this)
{
	echo("Hi hi hi!");
}

function Bar::doSomething(%this)
{
	echo("Hi!");
}

Now if we get
MyObject.doSomething();
it outputs Hi! or, if Bar::doSomething is not defined it will output Hi hi hi! and that is correct.

The situation I was getting in the torque admin mod was I would have this situation...

new ScriptObject(MyObject) {
	class = Bar;
	superClass = Foo;
};

function Bar::doSomethingA(%this)
{
	echo("Hi hi hi!");
}

function Bar::doSomethingB(%this)
{
	echo("Hi hi hi!");
}

function Bar::doSomethingC(%this)
{
	echo("Hi hi hi!");
}

where the functions for Foo had been previously defined. 99% of the time it would work but there was one function in one plugin that didnt. (note...onyl one of the functions didnt work!) and it would revert back to its superclass function. There was no syntex errors, there was nothing wrong. Hell... if I loaded it again it would load properly and work.

There is some bug in relation to the class/superclasses in there and I was not able to track it down.

If anyone would like a copy of the version of torque_admin that has this bug then please email me and I will send it to you.... its a wierd one

#20 Sure, if it's reasonably sized mail it to me.