Images... those images in Design Philosophy

ID:153797
 
Jan 15 2003, 9:09 am
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
</<>
#1 Jan 15 2003, 10:06 am
Gazoot wrote:
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?

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
#2 Jan 15 2003, 11:17 am
In response to Lummox JR (#1)
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?
#3 Jan 15 2003, 1:52 pm
In response to Gazoot (#2)
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.
#4 Jan 15 2003, 2:04 pm
In response to Spuzzum (#3)
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):

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.

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
#5 Jan 15 2003, 2:09 pm
In response to Lummox JR (#4)
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. ;-)
#6 Jan 15 2003, 2:12 pm
In response to Spuzzum (#5)
When you mean complxity you mean like the amount of icon states, or the overall icons complexity?
#7 Jan 15 2003, 2:58 pm
In response to Spuzzum (#3)
What a simple and elegant solution. Another stroke of genious from the Spuzzman... thanks!

/Gazoot
#8 Jan 15 2003, 3:11 pm
In response to Maz (#6)
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.
#9 Jan 15 2003, 3:56 pm
In response to Lummox JR (#4)
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