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.

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.

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.

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:

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:

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.

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?

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.

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.

No one has addressed this in nine years apparently, but this is about the topology of a torus, not a Möbius strip.