Reply to Re: Unusual method for one-time events
If you don't have an account, just leave the password field blank.
if (get_sprite_with_this_brain(2, 0) != 0)
DinkC is weird. It is unclear whether things like this work. In my preprocessor, I never generate any expressions more complex than a simple compare in an if for that reason; instead, I create a variable before it, and use that in the if:
It's probably not needed most of the time, but it is needed sometimes, and I have no motivation at all to find out the details of what does and what doesn't work. I know it always works if you put the function call on a line of its own.
For finding other sprites, I have seen DMODs that give those sprites a script which sets a global in their main function (to ¤t_sprite), and the other script can use this global.
That works; my editor does it better (it doesn't waste a global on it): it allows you to use sp("name"), where name is the name of the sprite; it will be replaced by its editor_num, and sp(num) will return its sprite number on the screen (which is not predictable for the editor). However, that method requires you to know the editor_num; my editor gives you tools to know it, but if you try this with any other editor, I think you are waiting for bugs to pop up; it's just too easy to change the editor_num of a sprite (changing the name doesn't happen by accident, but the other editors don't have sprite names).
DinkC is weird. It is unclear whether things like this work. In my preprocessor, I never generate any expressions more complex than a simple compare in an if for that reason; instead, I create a variable before it, and use that in the if:
int &tmp = get_sprite_with_this_brain(2,0); if (&tmp != 0) ...
It's probably not needed most of the time, but it is needed sometimes, and I have no motivation at all to find out the details of what does and what doesn't work. I know it always works if you put the function call on a line of its own.
For finding other sprites, I have seen DMODs that give those sprites a script which sets a global in their main function (to ¤t_sprite), and the other script can use this global.
That works; my editor does it better (it doesn't waste a global on it): it allows you to use sp("name"), where name is the name of the sprite; it will be replaced by its editor_num, and sp(num) will return its sprite number on the screen (which is not predictable for the editor). However, that method requires you to know the editor_num; my editor gives you tools to know it, but if you try this with any other editor, I think you are waiting for bugs to pop up; it's just too easy to change the editor_num of a sprite (changing the name doesn't happen by accident, but the other editors don't have sprite names).
