In response to Tom
Tom wrote:
Would this support just taking up a block at the bottom or side of the screen? In other words, doing the buttons in DragonSnot shouldn't cause the loss of turf all the way around.

Yes and no. This system will allow you to effectively have a "window" into the viewport. Since the view must be square, you won't be able to have a row of fixed buttons that take up half of the bottom row and, at the same time, make the other half part of the map itself.

I actually didn't mean to suggest half a row -- just that taking a row on one edge not require taking up a row on every edge!


Dense parts of your client map will determine the viewport of your server map. Non-dense parts will be overlayed onto the viewport at every square. This means that you could set a background image for your entire client (in place of the default black) and possibly make irregularly shaped views if you are willing to handle the edge-detection. It's a pretty flexible system.

Intriguing...how would layers work for such a background image? I guess the layer of the area/turf on the HUD map would indicate the drawing order like usual?

If that's correct, then if we got the future ability to control individual player HUD settings, this could give rise to huge new possibilities...like being able to implement fog of war, and even manual handling of view, by setting the layers of an individual player's HUD turfs so that they draw over everything or not based on your own criteria.

It's so cute to see engineers/physicists try to have a code freeze! Waving a cool new feature under the nose is like giving a brownie to a person on a diet...
In response to Deadron
Deadron wrote:
Tom wrote:

I actually didn't mean to suggest half a row -- just that taking a row on one edge not require taking up a row on every edge!

Oh, in that case it should work fine. With the map system you can specify which rows and columns are to be a part of the HUD, effectively reducing the viewport.

Intriguing...how would layers work for such a background image? I guess the layer of the area/turf on the HUD map would indicate the drawing order like usual?

Yes. And since the HUD map is just populated with objects, you can of course control the layer yourself.

If that's correct, then if we got the future ability to control individual player HUD settings, this could give rise to huge new possibilities...like being able to implement fog of war, and even manual handling of view, by setting the layers of an individual player's HUD turfs so that they draw over everything or not based on your own criteria.

I think so too!

It's so cute to see engineers/physicists try to have a code freeze! Waving a cool new feature under the nose is like giving a brownie to a person on a diet...

Shaddup.
In response to Tom
Tom wrote:
Deadron wrote:
Tom wrote:

I actually didn't mean to suggest half a row -- just that taking a row on one edge not require taking up a row on every edge!

Oh, in that case it should work fine. With the map system you can specify which rows and columns are to be a part of the HUD, effectively reducing the viewport.

Intriguing...how would layers work for such a background image? I guess the layer of the area/turf on the HUD map would indicate the drawing order like usual?

Yes. And since the HUD map is just populated with objects, you can of course control the layer yourself.

If that's correct, then if we got the future ability to control individual player HUD settings, this could give rise to huge new possibilities...like being able to implement fog of war, and even manual handling of view, by setting the layers of an individual player's HUD turfs so that they draw over everything or not based on your own criteria.

I think so too!

I just wanted to pipe in to say how psyched I am about these discussions. This is going to really add a lot to what we can do.

Keep 'em flying, boys!
In response to Tom
Tom wrote:
Well, that's doesn't quite fit in with the current notation, but it's the same basic idea. Here's how it will tentively work:
spells_icon.loc=locate(1,1,ID)
where ID will be some reference to the hud map, which will be assigned with client.map = 'hud.dmp'. Perhaps it could even just take that as an argument: locate(1,1,client.map). This will allow you to have multiple client maps and even be able to change them at runtime as needed (eg: when you get in a tank you get a gunner map, when you exit, you get a solider map, and so forth). For now, you'll have to use these in tandem with image() if you want to toggle stats on a per-user basis since, just like the normal maps, the hud maps will be shared between users. Clearly this just begs for dynamic map support, but that's a considerably more difficult feature that will probably have to wait for a while. But it's not so bad-- Deadron has shown, in DragonSnot, that images can make excellent control elements.

Interesting idea. I like that.
One thing you should keep in mind with dynamic map support is that it will often be desirable to give the impression of a much larger, more fluid map. It might be a good idea to set up maps in such a way that they can connect.
Setting up connectivity will be challenging, but it'll be considerably more difficult if the z parameter refers to a map reference. I suggest a compromise notation:

spells_icon.loc=locate(1,1,1,ID)

That is, a map reference should be an optional fourth parameter to locate().

The benefit of this is that dynamically loaded maps could then cover various ranges, like for example one could be (65-128,65-128,1-2) and the one due east could be connected to it as (129-192,65-128,1-2). Mobs could walk from one map to the other without hindrance.

The problem with introducing nifty new features like this is that they begin to spawn feature creep, since obviously so much more can be done. We have to be careful!

Indeed. :)

Lummox JR
In response to Skysaw
Keep 'em flying, boys!

That could be construed as sexist... ;-)
In response to Spuzzum
Spuzzum wrote:
Keep 'em flying, boys!

That could be construed as sexist... ;-)

"Keep 'em flying, boys!" Was a popular saying in the 1940s, and I believe it came from wartime efforts, as in "Keep the planes flying... we need them for the war."

Now I wasn't alive in the 40s, but I thought it was a quaint saying nonetheless. It popped into my head when thinking about getting our airlines back into the sky.

How it could be sexist is b(e)yond me.
In response to Skysaw
Skysaw wrote:
Spuzzum wrote:
Keep 'em flying, boys!

That could be construed as sexist... ;-)

"Keep 'em flying, boys!" Was a popular saying in the 1940s, and I believe it came from wartime efforts, as in "Keep the planes flying... we need them for the war."

Well here is a historical perspective:

Women were flying jets in WWII also...they shuttled them around the country as necessary.

Of course, the military promptly went into amnesia about this so they could spend the next 50 years claiming that women can't fly jets at the quality level necessary for the military.
In response to Deadron
Deadron wrote:
Well here is a historical perspective:

Women were flying jets in WWII also...they shuttled them around the country as necessary.

I think you mean planes, specifically prop-driven planes, not jets. As I recall the jet wasn't invented until late in the war or just after, and didn't see any production in military aircraft until WWII was finished.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
Deadron wrote:
Well here is a historical perspective:

Women were flying jets in WWII also...they shuttled them around the country as necessary.

I think you mean planes, specifically prop-driven planes, not jets. As I recall the jet wasn't invented until late in the war or just after, and didn't see any production in military aircraft until WWII was finished.

Jets started showing up late in the war, but the P51 Mustang was a more powerful design despite being prop-driven. For example, the ill-fated Luftwaffe Komet was one of the fastest jets built during the war. As I remember it (my memory is my source, and it is probably flawed), one hit the sound barrier and exploded when performing a high-speed dive, one was shot down, and the other four crashed because they alternately either ran out of fuel, or hit the runway too hard and crushed their landing gear, which was unsuitable for their design. There were only six ever made.
In response to Spuzzum
that has nothing to do with the heads up display for byond, but i cant gripe, we've all done it =)

--FIREking
In response to FIREking
FIREking wrote:
that has nothing to do with the heads up display for byond, but i cant gripe, we've all done it =)

Why shouldn't I reply off-topic to something off-topic? He made a statement he wasn't completely certain about, so I pointed out where I was certain and where I wasn't and added additional information.

Moving a single reply over to babble, on a subject that would not receive much attention, would unnecessarily complicate things...
Page: 1 2