I'm here to ask you, how the world << output works?
If I had two z levels of a map would world << "output." output to all players on bolth z levels?
I'm thinking yes.
But if I had two map files or dmp's and then outputted to world. Would it output to all the people on bolth .dmp's?
I'm thinking thats a yes too.
I think that all players are included in world as long as they are connected to the world. So then my next question is how do you make it so only people on that .dmp or map file hear an output while the others don't?
Thanks for any help. I'm sorry if this should have been posted in newbie's topic.
ID:275801
Nov 24 2004, 3:10 pm
|
|
world << "output" outputs to everyone in the world, whether or not they're on a map. As for you're other question, something like this would work:
var/z_level = 1 // change for your map level ~X |
In response to Xooxer
|
|
Xooxer wrote:
As for you're other question, something like this would work: Actually, block() only returns turfs. So you need to do something like this: > var/z_level = 1 // change for your map level The M.client check isn't really necessary. I don't know whether it's more efficient than letting BYOND do the check itself; I suspect not. A more efficient way, though, would be to loop through clients and then check the Z levels of their mobs: var/z_level = 1 // again, change this And finally, I seem to remember that you can send a message to a container and everything inside it will also get the message. I don't know where I got that from, though, and I'm very possibly wrong. But if I'm right, you could do something like this:
block(locate(1,1,z_level), locate(world.maxx, world.maxy, z_level)) << "output"
Don't take my word for it, though, test it yourself. |
In response to Crispy
|
|
Regarding the for(var/client/C)... I thought if you didn't put "in [whatever]" it defaulted to in world. Care to explain how that works?
[edit] http://www.byond.com/docs/ref/info.html#/proc/for/list "List: The list to loop through. This defaults to the whole world. " |
In response to Crispy
|
|
Crispy wrote:
Actually, block() only returns turfs. So you need to do something like this: Meh, I always forget that. Shows how often I use block() The M.client check isn't really necessary. I don't know whether it's more efficient than letting BYOND do the check itself; I suspect not. Ture, true. Ok, so I have a tendency to slightly over-complicate things. >.> A more efficient way, though, would be to loop through clients and then check the Z levels of their mobs: Yep, unless he keeps a list of active players, which I usually like to do, then the loop would only encompass those with clients actively playing. But, yeah, that's probably a better way to go. And finally, I seem to remember that you can send a message to a container and everything inside it will also get the message. I don't know where I got that from, though, and I'm very possibly wrong. But if I'm right, you could do something like this: Just did, and nope. If this was possible, then my reply would have been too. ~X |
In response to Xooxer
|
|
Xooxer wrote:
Just did, and nope. Okay. Good to know. If this was possible, then my reply would have been too. Not really, because you were looping through mobs in block(). You would have had to be looping through turfs. But this is a moot point anyway, seeing as it won't work either way. =) |
In response to Airjoe
|
|
Airjoe wrote:
Regarding the for(var/client/C)... I thought if you didn't put "in [whatever]" it defaulted to in world. Care to explain how that works? On this subject, the reference is wrong. =P Try it yourself; it doesn't work when you add "in world". Don't ask me why, it just doesn't. |
Actually, when you include two maps - it joins them together. So, if "map_one.dmp" is the first, and it has 5 z levels & "map_two.dmp" has 3 z levels, you'll have a total of 8. And, if one dmp is larger than the other in terms of "x" & "y", it changes the world.maxx & world.maxy to the largest map.