Mobius-strip Maps

Page: 1 2
#20 Aug 9 2012, 12:21 am
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.
#21 Aug 9 2012, 8:14 am
In response to A.T.H.K (#19)
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.
#22 Aug 12 2012, 6:58 pm
In response to Lummox JR (#21)
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.
#23 Aug 12 2012, 7:04 pm
This feature is already possible by making use of image objects. No need for implementation.
#24 Aug 12 2012, 7:06 pm (Edited on Aug 12 2012, 7:16 pm)
In response to Galactic Soldier (#23)
You should attach an example to back-up that statement.

Just so everyone else won't whinge :P
#25 Aug 12 2012, 7:10 pm
In response to Galactic Soldier (#23)
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.
#26 Aug 12 2012, 8:38 pm
All you do is create an area to update the image objects contained in the maps edges. Of course, it's not that simple, but that's the general idea. I've made similar systems to this in the past, such as a person peaking out of the window on a seperate z-level.

If anybody wants this feature, they can make it themselves. Although, I don't see much point in it.
#27 Aug 12 2012, 8:41 pm
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.
#28 Aug 12 2012, 8:41 pm
A.T.H.K wrote:
You should attach a compiled dmb and rsc showing this system in place.
Otherwise no one will believe you.

I've just explained the concept behind it. Anybody that knew how to program would be able to accomplish it.

@Kaiochao: The idea is to make the map bigger than it already is and attach areas on the edges to send back and forth image objects to give it the perspective that the z-levels are attached to each other.
#29 Aug 12 2012, 8:54 pm
In response to Galactic Soldier (#28)
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.
#30 Aug 12 2012, 8:59 pm
In response to Kaiochao (#29)
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.
#31 Aug 12 2012, 9:30 pm
In response to Galactic Soldier (#30)
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.
#32 Aug 12 2012, 9:42 pm
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.
#33 Aug 12 2012, 9:49 pm
In response to Galactic Soldier (#32)
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.
#34 Aug 12 2012, 9:53 pm
In response to Ter13 (#33)
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.
#35 Aug 12 2012, 9:59 pm
In response to Galactic Soldier (#34)
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,
#36 Aug 12 2012, 10:01 pm
In response to Ter13 (#35)
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.
#37 Aug 12 2012, 10:08 pm
In response to Galactic Soldier (#36)
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.
#38 Aug 12 2012, 10:12 pm
In response to Ter13 (#37)
Ter13 wrote:
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?

I wasn't wrong, you transfer the data back and forth between areas on the ends of the maps to give it the illusion that they're all connected. So now, I haven't been wrong on every single detail, only regarding images because my sub-conscious mind thought you could attach the same instance to more than one object.

Synching an object is as simple as changing an icon state, location, or even adding and removing overlays.
#39 Aug 12 2012, 10:21 pm
BOTH of you just compile something and try prove each other wrong? instead of arguing on the forums please.
Page: 1 2