A.T.H.K wrote:
Sounds good but for now it can be soft coded, and Goku is soooo close to getting it done I don't want him to give up now! Otherwise he may just wait for the update..


I already got it its all good hehe.

DarkCampaigner is nice and helpful.

Although i have on issue with moving from side to side smoothly but ill figure it out.
In response to A.T.H.K
A.T.H.K wrote:
Sounds good but for now it can be soft coded, and Goku is soooo close to getting it done I don't want him to give up now! Otherwise he may just wait for the update..

You misunderstand. What I'm talking about, what this whole thread is talking about, is a seamless map feature that cannot be soft-coded. Yes, anyone can write code such that as they approach the edge of the map they'll either stop moving (due to EDGE_PERSPECTIVE) or see blackness, and teleport to another location as they walk off the edge. What they can't do is actually see everything beyond that and have verbs and such continue to work.

Anyway there's no update to wait for on this yet, since it's not like anyone has come out and said this will definitely happen. It's a theoretical feature that would take a lot of work to get into place. It'd be darn nice to have though.
In response to Lummox JR
Lummox JR wrote:
A.T.H.K wrote:
Sounds good but for now it can be soft coded, and Goku is soooo close to getting it done I don't want him to give up now! Otherwise he may just wait for the update..

You misunderstand. What I'm talking about, what this whole thread is talking about, is a seamless map feature that cannot be soft-coded. Yes, anyone can write code such that as they approach the edge of the map they'll either stop moving (due to EDGE_PERSPECTIVE) or see blackness, and teleport to another location as they walk off the edge. What they can't do is actually see everything beyond that and have verbs and such continue to work.

Anyway there's no update to wait for on this yet, since it's not like anyone has come out and said this will definitely happen. It's a theoretical feature that would take a lot of work to get into place. It'd be darn nice to have though.

It can be faked with a lot of work, but there is no good implementation, really. You have to account for the behavior by writing your own range/orange procs, you have to create proxy objects that call back to their original, and you have to reference the clone from the original with every call.

I've gotten around this essentially, by only using click commands, and creating a new type of atom/movable that references back to a source object, then set up a system of handlers that will duplicate all visual/interactive behavior from one side of the map to the other.

All in all, though, it's WAY too easy to break.

Personally, I'd like to see a system of z-painting implemented, essentially where you can access the properties of an individual z-layer, and link Z-layers to an absolute coordinate system. It'd be a nice feature, but I imagine it wouldn't be an easy feature to implement. Until then, though, swapmaps and fakery.
You should attach an example to back-up that statement.

Just so everyone else won't whinge :P
Galactic Soldier wrote:
This feature is already possible by making use of image objects. No need for implementation.

No, no it can't be. Good luck trying to get it work with nothing but images, by the way.
Lummox JR wrote:
You misunderstand. What I'm talking about, what this whole thread is talking about, is a seamless map feature that cannot be soft-coded. Yes, anyone can write code such that as they approach the edge of the map they'll either stop moving (due to EDGE_PERSPECTIVE) or see blackness, and teleport to another location as they walk off the edge. What they can't do is actually see everything beyond that and have verbs and such continue to work.

Anyway there's no update to wait for on this yet, since it's not like anyone has come out and said this will definitely happen. It's a theoretical feature that would take a lot of work to get into place. It'd be darn nice to have though.
It's clearly not about image objects. It's about seamless interaction and verb compatibility from one side of the map to another. Image objects cannot be interacted with in any way.
Galactic Soldier wrote:
Kaiochao wrote:
It's clearly not about image objects. It's about seamless interaction and verb compatibility from one side of the map to another. Image objects cannot be interacted with in any way.

The object the image object is attached to can interact just fine.
Point is, this can be accomplished if the developer wants it to be, however the game will have to be designed for it.

If you have to attach the image objects to an object in order to make them interactive, you don't need to use image objects at all, because they should ALWAYS be visible at the edge of a map layer.

This is NOT an easy problem to solve. I. Have. Done. It. And it's far from an elegant solution.

You have to create seamless links between two distinct objects. In other words, objects at the edge of a map have to duplicate themselves, and all changes to one need to affect the other. This is not a simple solution, it completely changes the way you have to write each and every object in the game, and all interaction now changes as well.

It can be done, but it's a MAJOR pain to do so, and it's much harder than "just using image objects", because you have to proxy the interaction.
Galactic Soldier wrote:
As to why I've stated that whatever game that wishes to use this can already accomplish it, but they have to be designed for it. Plus, the performance change as if it were to be native would be little to none. If the developer wants this feature, they can already have it.

Couldn't be more wrong on the subject. Doing this incurs a pretty large object overhead as well as an additional function call overhead on the CPU for EVERY function called on an object. It'd be a pretty significant improvement.

Native code is MUCH faster than DM is, and handling it natively is going to improve efficiency quite a lot.

By your logic, the pixel movement update never should have happened.
Galactic Soldier wrote:
No, one function call to the main object, making any visual or movement changes to the other.
Pixel movement is something that should have been native, not moving two objects at once.

And what happens when an action affects the cloned object, galactic? You have to sync both objects,
Galactic Soldier wrote:
Ter13 wrote:
Galactic Soldier wrote:
No, one function call to the main object, making any visual or movement changes to the other.
Pixel movement is something that should have been native, not moving two objects at once.

And what happens when an action affects the cloned object, galactic? You have to sync both objects,

So complicated.

If it's so easy, can you explain to me why you've been wrong about Every. Single. Detail. You have said on the matter until corrected?

That's my last word on the matter. I think our conversation above adequately shows who knows what they are talking about, and who doesn't.
BOTH of you just compile something and try prove each other wrong? instead of arguing on the forums please.
Edo Tensei no Jutsu!

I'm still looking forward to this feature, is there any feedback about progress of the implementation or it remained as a feature suggestion.

Made some experiments or attempts to implement it?
Still nothing? Is it even on the priority list what so ever?
This is still on my wish list. I have not forgotten about it, but I haven't been in a place to put in the time and changes needed to do it.
I'm going to ressurrect this now, kill me for it if you want.

How high in the priority list is this, in the nearby future maybe? I am sure there are plenty of people who wish to see this.

I am still hoping to see this on BYOND, really am.
Near- and medium-future it is not on the priority list. There are too many other items there. But it is on my personal wish list and I have never forgotten about it.

In fact just recently I was realizing how this change would impact a number of loops, which is something I'll need an answer for. It's actually kind of a big change internally because so many things that assume the map is a cube format would have to be updated to understand these connections.
So I am resurrecting the feature request again, seems like we talked about this about 5 years ago.

Pretty please?
No one has addressed this in nine years apparently, but this is about the topology of a torus, not a Möbius strip.
can't you just do this with vis_contents now?
Page: 1 2 3