Hello! I'm trying to create a visibility system based on range and dense terrain. So every mob in the game has a var/image/Self which is simply a copy of the mob. All turfs with concealing terrain has their layer set to MOB_LAYER+1. The Self image has layer set to MOB_LAYER+2. Now when a mob moves into concealing terrain and is spotted, it will just do a spotter << src.Self. The problem is that the Self image is static. The animations won't work, and if you chance icon_state it won't update at all.
So I have two questions. Is it supposed to work like this? Shouldn't an image of an object mimic the object?
Second, if this is a bad way to go, do you have a different solution of this visibility system?
Thanks,
Gazoot
</<>
ID:153797
 Jan 15 2003, 6:09 am
|
|
Lummox JR wrote:
Nope, it doesn't work that way. An image has its own independent state because it's not "of" an object; it's attached to an object. An image is basically nothing more than an atom with no contents that's only visible to the players you specify. Well that's a shame. So do you have any ideas how to solve it in another way? | |
You can always update the image as the player goes along (provided you didn't add it as an overlay, which would be counterproductive to what you're trying to do anyway):
mob/proc/ImageUpdate() Self.icon_state = icon_state Self.icon = icon Self.pixel_x = pixel_x Self.pixel_y = pixel_y Just call mob.ImageUpdate() whenever the mob moves or its icon changes, and you're set. | |
Spuzzum wrote:
You can always update the image as the player goes along (provided you didn't add it as an overlay, which would be counterproductive to what you're trying to do anyway): Unfortunately it's not that simple, because all kinds of things affect the appearance of an atom, including its direction. flick() won't carry over, either. Accounting for all the variables can be a royal pain in the butt. Something like my idea of dummy atoms would probably be closer to a true solution to this mess. Lummox JR | |
Unfortunately it's not that simple, because all kinds of things affect the appearance of an atom, including its direction. flick() won't carry over, either. Accounting for all the variables can be a royal pain in the butt. Something like my idea of dummy atoms would probably be closer to a true solution to this mess. Actually, depending on the complexity of the graphics behind your game, it usually is that simple. I've used such a method before. ;-) | |
Maz wrote:
When you mean complxity you mean like the amount of icon states, or the overall icons complexity? Complexity as in how much programmatical and artistic effort you put into the graphics in the game. If you're flicking icon states, that makes it more complex. If you have different icon states for every possible condition, it's more complex. | |
Lummox JR wrote:
Unfortunately it's not that simple, because all kinds of things affect the appearance of an atom, including its direction. flick() won't carry over, either. Accounting for all the variables can be a royal pain in the butt. Something like my idea of dummy atoms would probably be closer to a true solution to this mess. It's working quite nice right now, but as you say it might be trouble later on. Time will tell. /Gazoot | |
Nope, it doesn't work that way. An image has its own independent state because it's not "of" an object; it's attached to an object. An image is basically nothing more than an atom with no contents that's only visible to the players you specify.
Lummox JR