Reality Factory

case RGF_SM_GETATTRIBUTEHIGH:
{
// USAGE: GetAttributeHigh(char* Attribute),
// GetAttributeHigh(char* Attribute, char* EntityName)

CPersistentAttributes *theInv;

if(arguments.entries() > 1)
{
strcpy(param0, arguments[1].str());

if(!stricmp(param0, "Player"))
theInv = CCD->ActorManager()->Inventory(CCD->Player()->GetActor());
else
theInv = CCD->ActorManager()->Inventory(CCD->ActorManager()->GetByEntityName(param0));
}
else
theInv = CCD->ActorManager()->Inventory(Actor);

returnValue = theInv->High(arguments[0].str().c_str());
return true;

}

   case RGF_SM_GETATTRIBUTEHIGH:
      {
         // USAGE:   GetAttributeHigh(char* Attribute), 
         //         GetAttributeHigh(char* Attribute, char* EntityName)
         
         CPersistentAttributes *theInv;

         if(arguments.entries() > 1)
         {
            strcpy(param0, arguments[1].str());

            if(!stricmp(param0, "Player"))
      {
               theInv = CCD->ActorManager()->Inventory(CCD->Player()->GetActor());
      }
            else
     {
               theInv = CCD->ActorManager()->Inventory(CCD->ActorManager()->GetByEntityName(param0));
    }
         }
         else
    {
            theInv = CCD->ActorManager()->Inventory(Actor);
    }
      
         returnValue = theInv->High(arguments[0].str().c_str());
         return true;

      }

Jay wrote:I am not sure, but are you really sure that the entity from which you want to get the high amount of the attribute actually has the attribute BEFORE you use the command? (In earlier versions i think it could cause a crash if you wanted to get or set the value of an attribute if it didn't exist on that entity) Or don't you use the command at all?

Jay wrote:to make sure the function returns the integer portion of the attribute (it could somehow confuse the compiler and it gives the return value a float for example, not sure how to explain this...)

In the official RF source code QoD does this with the SetAttribute and GetAttribute commands, so i guess it should be in your attribute command too, if only to be conform with the official source code.

Also, this line:

returnValue = theInv->High(arguments[0].str().c_str());

could be changed to

returnValue = (int)theInv->High(arguments[0].str().c_str());

returnValue = atoi(theInv->High(arguments[0].str().c_str()));

// Valid
if (!some_var)
    return;

// Also valid
if (!some_var)
{
    DoSomething();
    DoSomethingElse();
    return;
}

The reason why i wrote this was mainly because QoD used the implicit int conversion to make it clear that the script command always returns an integer value.

paradoxnj wrote:Juutis, are you running this using the debugger (the green arrow in the toolbar) or just double-clicking the EXE? If you are running using the debugger, you have to set the working directory in the project options. That may explain why it cannot find the INI files.

Assertion failed!

Program: C:\Nirhis\RF\test\RealityFactoryD.exe
File: C:\RF_FINAL\Genesis_02052007\GenesisLib\A...\actor.c
Line: 1115

Expression: geExtBox_IsValid(ExtBox) != GE_FALSE

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application - JIT must be enabled)

Assertion failed!

Program: C:\Nirhis\RF\test\RealityFactoryD.exe
File: C:\RF_FINAL\Genesis_02052007\GenesisLib\A...\actor.c
Line: 1159

Expression: Box->Max.X >= Box->Min.X

...

Assertion failed!

Program: C:\Nirhis\RF\test\RealityFactoryD.exe
File: C:\RF_FINAL\Genesis_02052007\GenesisLib\A...\ExtBox.c
Line: 186

Expression: geExtBox_IsValid(B) != GE_FALSE

...

paradoxnj wrote:My apologies...I saw .c_str() at the end of that and was lost in the excess brackets. Even though...you shouldn't use C-style casts. Use static_cast<int> to cast the integer. It's more efficient.

Jay wrote: The reason why i wrote this was mainly because QoD used the implicit int conversion to make it clear that the script command always returns an integer value.

No offense to QoD, but this is inefficient. It's an unnecessary cast. Casting takes away FPS. I can bet that if you change all the C-Style casts to static_cast<> you will gain FPS. In addition, you will also gain some FPS if you stop the unnecessary casts.

paradoxnj wrote: The reason you give is exactly what Hungarian Notation is for. If the function was iHigh(), you would know it returns an integer.

What good is static_cast?
Casts are generally best avoided. With the exception of dynamic_cast, their use implies the possibility of a type error or the truncation of a numeric value. Even an innocent-looking cast can become a serious problem if, during development or maintenance, one of the types involved is changed. For example, what does this mean?:
x = (T)y;

We don't know. It depends on the type T and the types of x and y. T could be the name of a class, a typedef, or maybe a template parameter. Maybe x and y are scalar variables and (T) represents a value conversion. Maybe x is of a class derived from y's class and (T) is a downcast. Maybe x and y are unrelated pointer types. Because the C-style cast (T) can be used to express many logically different operations, the compiler has only the barest chance to catch misuses. For the same reason, a programmer may not know exactly what a cast does. This is sometimes considered an advantage by novice programmers and is a source of subtle errors when the novice guessed wrong.
The "new-style casts" were introduced to give programmers a chance to state their intentions more clearly and for the compiler to catch more errors. For example:

int a = 7;
double* p1 = (double*) &a; // ok (but a is not a double)
double* p2 = static_cast<double*>(&a); // error
double* p2 = reinterpret_cast<double*>(&a); // ok: I really mean it

const int c = 7;
int* q1 = &c; // error
int* q2 = (int*)&c; // ok (but *q2=2; is still invalid code and may fail)
int* q3 = static_cast<int*>(&c); // error: static_cast doesn't cast away const
int* q4 = const_cast<int*>(&c); // I really mean it

The idea is that conversions allowed by static_cast are somewhat less likely to lead to errors than those that require reinterpret_cast. In principle, it is possible to use the result of a static_cast without casting it back to its original type, whereas you should always cast the result of a reinterpret_cast back to its original type before using it to ensure portability.
A secondary reason for introducing the new-style cast was that C-style casts are very hard to spot in a program. For example, you can't conveniently search for casts using an ordinary editor or word processor. This near-invisibility of C-style casts is especially unfortunate because they are so potentially damaging. An ugly operation should have an ugly syntactic form. That observation was part of the reason for choosing the syntax for the new-style casts. A further reason was for the new-style casts to match the template notation, so that programmers can write their own casts, especially run-time checked casts.

Maybe, because static_cast is so ugly and so relatively hard to type, you're more likely to think twice before using one? That would be good, because casts really are mostly avoidable in modern C++.