Jump to content

Photo

retrieve ffc's unique ID from inside the ffc script?


  • Please log in to reply
13 replies to this topic

#1 Shadowblitz16

Shadowblitz16

    Illustrious

  • Members

Posted 09 January 2017 - 02:58 PM

can someone tell me how to retrieve a ffc's unique ID from inside a ffc script?

I want to do this so I can store it in a variable for this script 

 

bool shopCarrying   = 0;
int  shopCarryingID = 0;
 
 
ffc script FFC_Shop{
    void run(int tile, int itm, int price, int number, int input){
int origTile = this->Data;
int origX    = this->X;
int origY    = this->Y;
        while(true)
{
 
if (!shopCarrying)
{
Screen->DrawInteger(3, this->X + 0,  this->Y + -8, FONT_MATRIX, 8, -1, 16, 16,  price, 0, 128);
Screen->DrawInteger(3, this->X + 16, this->Y +  8, FONT_MATRIX, 8, -1, 16, 16, number, 0, 128);
if(CanPick(input, origX, origY))
{
shopCarrying   = true;
shopCarryingID = this->ID;
this->Data = tile;
}
}
else
{
if (shopCarryingID == this->ID)
{
this->X = Link->X;
this->Y = Link->Y - 8;
 
if(CanPick(input, origX, origY))
{
shopCarrying   = false;
this->X = origX;
this->Y = origY;
this->Data = origTile;
}
}
}
Waitframe();
        }
    }
}
 
bool CanPick(int input, int x, int y){
    return (Abs(Link->X-x) < 8 && Abs(Link->Y-(y+16)) < 8 && SelectPressInput(input) && Link->Dir == DIR_UP);
}
 

Edited by Shadowblitz16, 09 January 2017 - 02:59 PM.


#2 MoscowModder

MoscowModder

    Sometimes lurking. Rarely posting.

  • Members
  • Location:Wisconsin

Posted 09 January 2017 - 03:52 PM

Loop through the FFCs on screen. If the FFC equals this, then the loop variable is your ID. Would write an example but I'm on a phone.

#3 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 09 January 2017 - 04:29 PM

I glanced at your code, and something to note, is that ffc->ID is another of my additions to 2.54. You can generally determine the ffc running a script using loops, as MM described, in 2.50.x.

 

FFCs do not have UIDs though. They have a valid screen index range of 1 to 32. I don't think I have ever tried to do Trace(this). Might trace the REFFC value?



#4 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 09 January 2017 - 05:17 PM

Wouldn't trace(this) return an address since this is a pointer?

 

[edit]

 

Never-mind, you have to iterate through them to figure out which one of the 32 FFCs you are using, don't you? Man, it has been a while since I touched Zscript.


Edited by SUCCESSOR, 09 January 2017 - 05:30 PM.


#5 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 09 January 2017 - 05:37 PM

Wouldn't trace(this) return an address since this is a pointer?

 

[edit]

 

Never-mind, you have to iterate through them to figure out which one of the 32 FFCs you are using, don't you? Man, it has been a while since I touched Zscript.

 

I would suspect that Trace(this) just generates a parser error. Verified, it does, because Trace() doesn't accept any of the custom ZC datatypes, and 'this' is ffc typed.

 

You do need to do iteration, and I've found that it is not impossible to generate an invalid match in the process. This is specifically why I added ->ID to the class.

 

What you can do, is this:

int GetFFCID(ffc ff){
    int q; ffc f;
    for ( q = 1; q <= 32; q++ ) {
        f = Screen->LoadFFC(q);
        if ( f == ff ) return q;
    }
}
 
//Call GetFFCID(this) in your script.

Note that returning a value outside the range of 1 to 32 is dangerous. You cannot specify an error return for this function, and it might be safer to do it otherwise, but really there is no ideal solution. (Note that this is what MM was stating in his response.)

 

For the example above, in the OP's code, you would do this:

shopCarryingID = GetFFCID(this);

This is also arguably, a very slow way to get a flipping screen ref.

 

One thing to note, for anyone who wants to try using 2.54, is that ffc->ID is at present, read-write. I may disable writing to it, but first we need to discover if that causes any sort of bugs, or corruption. As a read-only value, it is perfectly safe, but I do not yet know if writing to REFFC is safe in this manner.


Edited by ZoriaRPG, 09 January 2017 - 05:45 PM.


#6 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 09 January 2017 - 05:57 PM

I would suspect that Trace(this) just generates a parser error. Verified, it does, because Trace() doesn't accept any of the custom ZC datatypes, and 'this' is ffc typed.
 
You do need to do iteration, and I've found that it is not impossible to generate an invalid match in the process. This is specifically why I added ->ID to the class.


I suspected that is what would happen, but I figured if it did anything it would print an address.

I know. I have done it before. It just has been so long I forgot it was necessary.

#7 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 09 January 2017 - 06:30 PM

I suspected that is what would happen, but I figured if it did anything it would print an address.

I know. I have done it before. It just has been so long I forgot it was necessary.

 

If it did trace aything, it would trace the integer associated to the pointer. There aren't really true address values involved. I'd like to add either a way to typecast any pointer to int, and typecast it back to a classed type, or something of that sort; specifically so that you can store object array pointers in global float arrays.

 

For example. ffc f[16]; The pointer for this is a long, and could be stored into int arr[n];, but because the parser does not know how to typecast these, it's problematic, and you need to maintain arrays local to the run() function of the active script, and make insane functions to fetch, or store them from the script scope. 

 

I suppose that this isn't the topic for that discussion, but it does sort of tie into the same kind of efficiency and pointer stuff, that the OP may find good to know. The bottom lie for the OP, is that you can't declare global arrays with types other than int/float and bool. This makes storing ffc (and other classed type) pointers, difficult, and from what you have been doing, I suspect you will eventually need to do that.

 

The inability of the parser to typecast array pointers also precludes doing SizeOfArray() on non-int/float arrays. (While nonstandard anyway, it would be nice to do that on ZScript bool typed arrays. I do not use bool typed var declarations simply for this reason, as in ZScript, they have no distinct advantage, and I believe that the memory footprint is identical.)

 

If we add pointer typecasting into the parser, that fixes this issue entirely. ffc f[32]; int size = SizeOfArray(f); should be allowed...

 

When you start using ffc, item, *weapon, npc, or (gasp) itemdata arrays, and rn into these issues, come around and have a chat. I noticed that you are using them, even now. :)

 

Oh, and aye, I have very good uses for itemdata arrays now. :D


Edited by ZoriaRPG, 09 January 2017 - 06:31 PM.

  • SUCCESSOR likes this

#8 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 10 January 2017 - 05:48 PM

the integer associated to the pointer.

You mean like... the address? :P

I do know how limited Zscript pointers are. Though, they are pretty sufficient.
 

The inability of the parser to typecast array pointers also precludes doing SizeOfArray() on non-int/float arrays.

If you are talking about internal code that prevents SizeOfArray() from being overloaded for bools or pointer types, I have no idea. It is surprising that in ZScript you don't have to pass the size of the array with the pointer for even int/float arrays like you have to do in C++.

 

I'm a little confused about what you mean and why you mean to typecast array pointers. Also, is there a particular need for global ffc, weapon, npc, etc arrays/pointers?  What is wrong with just passing the array pointer to your functions?


Edited by SUCCESSOR, 10 January 2017 - 05:50 PM.


#9 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 10 January 2017 - 08:40 PM

You mean like... the address? :P

I do know how limited Zscript pointers are. Though, they are pretty sufficient.
 

If you are talking about internal code that prevents SizeOfArray() from being overloaded for bools or pointer types, I have no idea. It is surprising that in ZScript you don't have to pass the size of the array with the pointer for even int/float arrays like you have to do in C++.

 

I'm a little confused about what you mean and why you mean to typecast array pointers. Also, is there a particular need for global ffc, weapon, npc, etc arrays/pointers?  What is wrong with just passing the array pointer to your functions?

 

We've briefly discussed adding a real addresses system, but that's a matter for another time.

 

This is what I was talking about, and I've already inserted all of this into 2/future, 2.54 beta 52:

Spoiler

 

The *ptr->UID getter vars need testing, but everything else works perfectly, thus far. There are several situations where you want to maintain a static object, refreshing it on screen change; or for another, one thing I wish to do, is to save typed values that might need to read in and out of multiple scripts.

 

Global special typed arrays would be ideal, and DD might allow, or even add those, but at the least, being able to reference an ffc or npc array at the scope of the run function of the global active script without either global arrays of matching types, or some sort of typecasting mechanism is a true pain in the arse.

 

In this method, you need only do this:

 
int PtrsArr[214747];
const int NPCS_PTR = 0;
global script a{
    void run(){
        npc npcarr[256];
        PtrsArray[NPCS_PTR] = npcsarr->GetPointer(npcsarr);
        //Typecst and store the pointer.
    }
}
 
//We want to be able to manipulate things externally...
void foo(){
   ffc ptr = ptr->SetPointer(PtrsArray[NPCS_PTR]);
   //now we can reference npcsarr[] in the run() function of the flobal active script.
   ptr[0] = Screen->LoadNPC(1); // Loads NPC ID 1 into the array in the global active script.
}

There are several applications for this. For me, two of these are save state functions, and engine control scripts, such as mass enemy handling for scrolling scripts, and other esoteric things. Grayswandir and ywkls, have also pushed for this kind of functionality. Everone has priorities, some of them are bizarre, but at the least, now you can actually do this, and should all of that fail to be any more than trivial, you can do SizeOfArrayNPC(PtrsArray[NPCS_PTR]) and return 256. :)

 

Bother, UID seems not to be updating per instance. It's fetching the first enemy on a screen, and reporting its UID for all of them. :(


Edited by ZoriaRPG, 10 January 2017 - 09:02 PM.

  • ywkls likes this

#10 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 11 January 2017 - 01:38 PM

Static data would be nice. Pass by reference would be nicer. Honestly, though we would be getting to the point where we are going over the top and might as well just swap Zscripting for C# plugins or something.


Edited by SUCCESSOR, 11 January 2017 - 01:39 PM.


#11 Gleeok

Gleeok

    It's dangerous to dough alone, bake this.

  • Members
  • Real Name:Pillsbury
  • Location:Magical Land of Dough

Posted 13 January 2017 - 08:55 AM

Static data would be nice. Pass by reference would be nicer. Honestly, though we would be getting to the point where we are going over the top and might as well just swap Zscripting for C# plugins or something.

Y'know what? I've written a c# scripting engine around Mono. ...We could totally do this! 8)
  • SUCCESSOR likes this

#12 Shadowblitz16

Shadowblitz16

    Illustrious

  • Members

Posted 13 January 2017 - 01:58 PM

thats would be cool next you guys can update zc so that it revolves around scripts and not build int flags, types, and classes



#13 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 16 January 2017 - 09:27 AM

Y'know what? I've written a c# scripting engine around Mono. ...We could totally do this! 8)


Pretty sure we had this conversation in chat a few years ago. ;)

Monodevelop is a nice IDE. I used it to make a simple block breaker game in c#. I enjoy the language.

#14 SUCCESSOR

SUCCESSOR

    Apprentice

  • Banned
  • Real Name:TJ

Posted 16 January 2017 - 01:07 PM

thats would be cool next you guys can update zc so that it revolves around scripts and not build int flags, types, and classes


I know what you are saying. I love scripting and programming. But shifting to solely focusing on that would be ignoring a lot of what makes zc powerful and successful. The quest editor has some issues and limitations but once you get used to its quirks it is very useful and a great creative tool. There's a reason so many of us stick with it and don't switch to something more modern and powerful like Game Maker, Solaris, Unity, etc. I don't think we need to expand the scripting language so much until we expand and rework work some of the barriers that hinder the scripting already available.


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users