ID:1972045
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Make it where a developer can make more than just 1 Map that a client eye can constantly return feedback from.

The way byond currently works with a map screen is that it has only 1 client eye that focuses on the default map. Why not expand a client eye to a list of eyes where each eye can only focus on one map that another eye is not focus on. This also requires the addition of client procs to return back an eye depending on a passed map id.

Why I want this in? Isn't it obvious? This will create split-screen support for Byond.

I've notice games where if you steer stuff and view other people, you cannot see what's happening around you. You can easily get gank'd (Killed) just because Byond only supports a single screen.

Just so nobody is confused. I know you can make multiple maps, but I'm talking about maps that updates on its own.
I wouldn't mind the ability to have secondary eyes that can be viewed from secondary map controls.
I could see plenty of uses for this. Just have the default one attached to the player mob, then another map with an eye on their opponent or ally, and so many possibilities open up.

I definitely support something like this.
This has been requested a few times in the past, and when the addition of secondary map elements got announced people got their hopes up, but alas.

Adding this would be very non-trivial and involve reworking massive amounts of the core, last I checked.
Yeah, I know it requires a massive amount of work to put it in Byond. The only way I can suggest adding it in which it doesn't require everybody that have client.eye commands to redo their code is by having a list to hold more client eyes and have the current client eye only work for the default map. You don't need to revamp the actual client.eye var to make this work, you just have to add on to it.
The problem comes from things like the redrawing code, the rendering code, the code that handles view-related things, etc etc etc
Basically all of the map-related routines assume a single view.

- The server keeps track of the client's eye, map bounds and dimensions, etc.
- The server sends updates about what that client can and can't see within its map dimensions.
- The client keeps a global list of turfs, and globals lists of objs and mobs on those turfs.

IMO the biggest hurdle is really the client side, because a lot of vars that are currently global would have to be reworked into more self-contained structures.
I know what you mean cause I do stuff like this from time to time and it sucks. So, everything that encapsulates rendering a map should be turned into a list instead of a single entity.

Yeah, its going to be a hell of a job because of everything else that was added to it has to be redone to have multi-support.

If you're going to add it, the best case is to add it as soon as possible because if you keep updating map related parts of Byond, you're just adding on to the split-screen update you gotta do.

It's gonna take atleast a good week or more to recode all that and errors can be expected too so you should make backups.

But if you keep this on hold, it will be a longer task to do the next time.

So the three scenarios is to either work it out the soonest you can for the least amount of things to recode, put it off for another time which also means that you will have to recode even more stuff to make it work than before, or just not add in the feature.

This is basically the equivalent of building something from the bottom up, but to add in something like this, you gotta unscrew everything from the top to add it to the bottom.
You could create two processes, hide one, and then share the memory with the other one for rendering... I actually feel like this could be done easily but somewhat wonky for plug and play.

Games would have to be designed to manage the conflicting macros.
In response to BlackProgrammer
BlackProgrammer wrote:
If you're going to add it, the best case is to add it as soon as possible because if you keep updating map related parts of Byond, you're just adding on to the split-screen update you gotta do.

Actually, I don't think the newer stuff would have any impact whatsoever on the logistics of multiple true-maps. Almost all of those features are appearance-related, or happen at an atom level that has nothing to do with map output (e.g., animate()), so they'd be unaffected.

It's gonna take atleast a good week or more to recode all that and errors can be expected too so you should make backups.

It would take a lot longer than a week. The single-map concept is so ingrained, it'd take a great deal of brainstorming just to come up with a way around that on both the server and client ends. Then it'd be a matter of slowly moving the code in an encapsulated direction, and after that only then would final "hookup" be achievable.