Reply to Re: Script created Sprite that can be commanded from multiple other scripts
If you don't have an account, just leave the password field blank.
"Getting sp() works, but I myself stopped using sp() at some point, because the sprite numbers have an annoying habit of changing as long as the screen is still being worked on. Nothing worse than decorating and prettifying a screen, only to have the shopkeeper's script attach to a hatrack because of it."
Not sure how it works in dinkedit because I havent used it for a while but in Windinkedit, I use sp all the time.
The number of a sprite will only change if you pick it up and put it back down in the editor, after deleting a sprite with a lower sprite number than the one you moved. This is because when you put down a sprite in the editor, it defaults to the lowest available sprite number. So either don't move it, or, if you haven't deleted any sprites (or you have and you've already placed down more sprites to replace the deleted ones), it'll be fine, because there's no free sprite number lower than the one currently assigned to it.
Best thing is to just check the sprite number of the sprite after moving it to see if it's the same... in windinkedit you can hold the 'i' key to show all sprite numbers, or enable sprite info on mouse hover, and just mouse over the sprite to view the number.
-------------------------------------------------------------------------
If you don't want to use sp, and don't want to waste global variables your other options are:
- Use a fake brain (you can assign a fake brain to the sprite, such as brain 20). And then retrieve the brain 20 sprite from the other scripts and store it in a local variable.
- save the sprite in a sp_custom key attached to one "control" sprite that has a fake brain, with this method, you can access as many sprites as you want, and only have to assign one fake brain to control them all. The way this works is to set a sprite to fake brain 20 for example. And then in the script of ANY sprite that you want to be able to access, get it to retrieve the brain 20 sprite, and then store itself in a unique sp_custom key attached the fake brain sprite. Then to access it, you just do the same thing, but retrieve the sp_custom key instead.
.... if that makes sense. It's a bit of run around, but it works well for certain scenarios.
Not sure how it works in dinkedit because I havent used it for a while but in Windinkedit, I use sp all the time.
The number of a sprite will only change if you pick it up and put it back down in the editor, after deleting a sprite with a lower sprite number than the one you moved. This is because when you put down a sprite in the editor, it defaults to the lowest available sprite number. So either don't move it, or, if you haven't deleted any sprites (or you have and you've already placed down more sprites to replace the deleted ones), it'll be fine, because there's no free sprite number lower than the one currently assigned to it.
Best thing is to just check the sprite number of the sprite after moving it to see if it's the same... in windinkedit you can hold the 'i' key to show all sprite numbers, or enable sprite info on mouse hover, and just mouse over the sprite to view the number.
-------------------------------------------------------------------------
If you don't want to use sp, and don't want to waste global variables your other options are:
- Use a fake brain (you can assign a fake brain to the sprite, such as brain 20). And then retrieve the brain 20 sprite from the other scripts and store it in a local variable.
- save the sprite in a sp_custom key attached to one "control" sprite that has a fake brain, with this method, you can access as many sprites as you want, and only have to assign one fake brain to control them all. The way this works is to set a sprite to fake brain 20 for example. And then in the script of ANY sprite that you want to be able to access, get it to retrieve the brain 20 sprite, and then store itself in a unique sp_custom key attached the fake brain sprite. Then to access it, you just do the same thing, but retrieve the sp_custom key instead.
.... if that makes sense. It's a bit of run around, but it works well for certain scenarios.
