ACS-controlled "mini-map"

[Rachael]

I believe that all TC's can survive without imposing user restrictions. That being said, I still support the idea of having an extra automap on the screen that is exclusively ACS or SBARINFO controlled, does NOT interfere with the overlay map, and does NOT interfere with the actual regular automap.

Besides, if you're really that worried, most users have the overlay map turned off, mainly because they don't use it.

[Project Shadowcat]

Besides, if you're really that worried, most users have the overlay map turned off, mainly because they don't use it.

I'm in the minority of that one.

[HotWax]

I'm not saying I'm "worried" and could care less what mapping settings the user chooses to display. It just seemed redundant to me to have a full-screen overlay while at the same time offering a smaller one in a corner of the screen.

But if that's not desirable, that's fine.

[AFADoomer]

Right now it "replaces" neither map... It shows up when the normal player view would be on the screen, and +togglemap (Tab) allows you to toggle between that and whatever your normal map settings include, be it overlay or the normal map, or both...

@Graf - What do I need to change about this implementation to get it seriously considered for inclusion in ZDoom?

Right now I need to figure out a way affect either the activator or all players (not that easy, since all 5 arguments are filled with x, y, w, h, and transp... But I've come up with a solution where scripts activated by a player affect only that player, and map-executed scripts affect all players (still testing)), and (possibly) rewrite the toggle function to affect only the custom map, and ignore the normal map.

I was also thinking of adding a CVAR ("am_allowcustom" - default "1") to allow the user to disable custom maps altogether. This could also possibly tie in with the suggested 'temporary, per-mod, KEYCONF' map colors idea...

[zwouth]

This seems too obvious, I must be missing the boat...

The addition of a "modification definable map mode" that is in the normal map rotation (TAB default).
Classic, Overlay, AFAHUDOverlay, User Defined, Modification Defined

User Defined being any combination of settings a user wants for general use. Map color, background, overlay type, gametype, etc. In user cfg file.
Modification Defined is optional lump in a wad that a pwad can define as recommended. If you don't want this at all you simply disable MOD mapmodes in zdoom options.

Am I way off?

[HotWax]

Right now I need to figure out a way affect either the activator or all players

First, why are you limiting yourself to 5 arguments? Is there a particular reason you can't implement this as an ACS function rather than a line special?

If you have to keep it a line special, you could make two versions -- One to affect everyone and one for just the activator.

Or you could turn the 5th argument (Transparency) into a flags argument and implement flag bits that provide different amounts of translucency (3: 100, 2: 50, 1: 25, 0: 0 for example). This would sacrifice some granularity in exchange for adding room for additional flags.

Finally, as a last resort, you could just leave it as a single special affecting only the activator. It could always be placed in ENTER scripts and triggered for everyone by the setting of a global variable. Any competant ACS coder should know how to do this by now, and it wouldn't be the [wiki=FadeTo]first function[/wiki] to be available only in activator form.

I've come up with a solution where scripts activated by a player affect only that player, and map-executed scripts affect all players

I don't think that's a good idea. It's too specific to this situation and would change the way people expect ACS to behave. It also means that you couldn't trigger an activation for all players from a line, which would seem to diminish the usefulness of it being a line special instead of an ACS function.

[AFADoomer]

Right now I need to figure out a way affect either the activator or all players

First, why are you limiting yourself to 5 arguments? Is there a particular reason you can't implement this as an ACS function rather than a line special?

Mostly because I know how to implement line specials, and don't know (yet?) how to implement separate ACS functions... Mostly because I haven't looked into it yet, but I'll be working on trying to figure that out...

I've come up with a solution where scripts activated by a player affect only that player, and map-executed scripts affect all players

I don't think that's a good idea. It's too specific to this situation and would change the way people expect ACS to behave. It also means that you couldn't trigger an activation for all players from a line, which would seem to diminish the usefulness of it being a line special instead of an ACS function.

Yeah, I don't like it either... I'd rather stick to the standard first-argument-sets-who-it-affects pattern.

[Graf Zahl]

Note:

Deleting the link only ensures that this gets closed.

I would have moved it to 'code submissions' to be revisited when I have more time but as it is this will be dumped.