[Mike Norvak]

Just reporting an issue that has been already reported, please don't treat me as if I were a paranoid

The good old, beautiful and fully functional color code visual system:



Some weird, new and not functional at all pixel based color non-visual system, that doesn't show blocking objects anymore:



Thanks!

[Mark]

Someone, not as lazy as I am, should start a poll on the subject of retaining the color changes or going back to the previous way. It seems there are a number of mappers wishing to revert back to the old color scheme.

[Jblade]

Yeah I wish it would go back, I know they added some functionality to customize the colours and everything but honestly it worked fine before, the colours have been the same for years and it did just feel like a "cos we can" feature.

[Mike Norvak]

Jblade, on 12 March 2016 - 05:42 AM, said:

Yeah I wish it would go back, I know they added some functionality to customize the colours and everything but honestly it worked fine before, the colours have been the same for years and it did just feel like a "cos we can" feature.

A "cos we can" feature that is broken.

[Hank]

What is broken? Looks good to me. And yes, I have not touched mapster32 in years, so not sure what you guys got used to.


The only weird thing is the sprite flashing white to black when the mouse is hovering over one, this should get fixed.

[Mark]

If you have no blocking walls or blocking sprites then you will like the "new" feature. Otherwise its a problem. Re-read the first post and look at the pics. The problem is quite obvious to the rest of us.

[Mike Norvak]

Yeah another ploblem is the flashing sprites when selected, hard to tell where actually the sprite is.

@Mark: I don't think a poll is necessary at all since this is not only a cosmetic change but a change on how mapster represents things to be usable on a coherent mapping workflow and it needs to be restored.

Hence the broken traffic lights metaphor: Imagine if someone changes the red light to white for technical reasons or just because it looks cool.

[Hank]

Mark., on 12 March 2016 - 11:03 AM, said:

If you have no blocking walls or blocking sprites then you will like the "new" feature. Otherwise its a problem. Re-read the first post and look at the pics. The problem is quite obvious to the rest of us.

I did read it the first time around.
My blocked walls show up as a shade of maroon instead of red, and the sprites are white blocked or unblocked. Those items with a HitScan=On are thicker or the sprites have a thicker tail.
So since it is obvious to everyone around here, fine, try not to explain it. I have no issues with the current color scheme, except I would love to see the flashing highlighting thingy disabled, and that may just what the current mapper want.

[Danukem]

Hank, on 12 March 2016 - 10:48 AM, said:

And yes, I have not touched mapster32 in years

Hank, on 12 March 2016 - 01:34 PM, said:

I have no issues with the current color scheme, except I would love to see the flashing highlighting thingy disabled

I don't map, so I don't really have an opinion. But every active mapper I have heard from hates it. Why would it be a good idea to keep changes that are bad for the people actually making maps?

[Hank]

Trooper Dan, on 12 March 2016 - 02:00 PM, said:

Why would it be a good idea to keep changes that are bad for the people actually making maps?

Not sure if my post indicated that.
To be clear, when I hover over a SE sprite, the name field flashes white to black making it unlegible, this is the only issue I have with Mapster32.

[Mark]

Well Hank, I for one would definitely prefer the obvious contrast of red and purple walls instead of red and "a shade of red" walls. We're just different I guess.

[Hank]

Looks like bright maroon or purple to me



as for the sprites, all you could do for now is edit the tile.cfg

Spoiler

/* << delete this
// Uncomment this group to get the [OLD_COLOR_SCHEME].
tilegroup "All"
{
tilerange 0 30704 // MAXUSERTILES

// NOTE: no hotkey, this group will not show up in the 'T' menu.

// NOTE: colors specified here (as well as in the first argument to the DEF
// commands '2dcol' and '2dcolidxrange') refer to Mapster32's editorcolor[]
// index. They can be viewed with "do set showpal 1" assuming that a.m32
// has been loaded.
//
// The actual color indices will be offset in the range [0 .. 4] when the
// mouse hovers near them.
//
// For example, under the Duke3D palette, one can create a color scheme
// similar to earlier Mapster32 builds (non-blocking sprites have an orange
// tint, blocking ones are purple) by first putting in your m32_autoexec.cfg
// file the lines
//
// do gamevar i 0 1 // only if a.m32 is not loaded
// script_expertmode 1
// do for i range 256 ifge i 33 { set editorcolors[i] i }
// script_expertmode 0
//
// which maps editorcolor[] indices 33 through 255 to the same actual color
// indices, and then setting here one of the alternatives:
//colors 139 231 // reddish orange / purple
// colors 6 5 << delete the '//' and enter your preferred color values
// This sets tile colors for all sprites excluding those which have been
// assigned a color by the above tile group declarations.
}
*/ << delete this

[Paul B]

Yea, i noticed this color scheme change almost immediately as I always ran with the latest build of Mapster when mapping. Since the release of this new change I've attempted to restore the color scheme back the best I could but its still far from the way it use to be. I also wasn't overly crazy about the mouse filter changes and movements within 2d mode. As a result I lost interest in trying to restore the color scheme so i've just stopped mapping. Not like there were any known problems using the previous build before the color change. I guess a person can always go back to before the update but then miss out on any future improvements \ optimizations. In my opinion whenever there is a drastic change like that there should always be a way to load the traditional way as well as implement the new look via a customization setting. But to totally prevent the ability to restore the classic look and feel in my opinion isn't a great way to go.

[Mike Norvak]

Paul B, on 12 March 2016 - 06:39 PM, said:

As a result I lost interest in trying to restore the color scheme so i've just stopped mapping. Not like there were any known problems using the previous build before the color change.

I'd rather use any old synthesis before that change than stop mapping at all. And that's actually what I'm doing.

Hank, on 12 March 2016 - 04:15 PM, said:

Looks like bright maroon or purple to me

capt0005.png

as for the sprites, all you could do for now is edit the tile.cfg

Spoiler

/* << delete this
// Uncomment this group to get the [OLD_COLOR_SCHEME].
tilegroup "All"
{
tilerange 0 30704 // MAXUSERTILES

// NOTE: no hotkey, this group will not show up in the 'T' menu.

// NOTE: colors specified here (as well as in the first argument to the DEF
// commands '2dcol' and '2dcolidxrange') refer to Mapster32's editorcolor[]
// index. They can be viewed with "do set showpal 1" assuming that a.m32
// has been loaded.
//
// The actual color indices will be offset in the range [0 .. 4] when the
// mouse hovers near them.
//
// For example, under the Duke3D palette, one can create a color scheme
// similar to earlier Mapster32 builds (non-blocking sprites have an orange
// tint, blocking ones are purple) by first putting in your m32_autoexec.cfg
// file the lines
//
// do gamevar i 0 1 // only if a.m32 is not loaded
// script_expertmode 1
// do for i range 256 ifge i 33 { set editorcolors[i] i }
// script_expertmode 0
//
// which maps editorcolor[] indices 33 through 255 to the same actual color
// indices, and then setting here one of the alternatives:
//colors 139 231 // reddish orange / purple
// colors 6 5 << delete the '//' and enter your preferred color values
// This sets tile colors for all sprites excluding those which have been
// assigned a color by the above tile group declarations.
}
*/ << delete this

It seems you are using a newer synthesis, anyway I prefer the old system.

[Hendricks266]

It seems like this change has met with near-unanimous dislike. I will look into reverting it, or at least making it a non-default option.

For anyone who does like it, in what circumstances would you use it? I can't think of a reason beyond aesthetic color matching...

How would it be if sprites only used the new color scheme when textured floor mode is enabled? Still no good?

[Mike Norvak]

I don't really find any use for a mapper (at least not for me) to know what is the average color of a sprite in 2D mode and it does could be confusing in some cases (specially in mods with new art) to see so much colors not related to the sprite type, there are cases when gray sprites can be missed because they turn almost pitch black. I don't see any problem on leave it as it is on textured mode, since I just use that option to allign floor textures. Not sure about other mappers though.

Also flashing sprites when selected must not completely fade to black.

The wall colours must be bright and contrasting: the red, purple, green trio has always worked fine for me.

Last but not least I remember some older synthesis that let you spam lots of sprites by just holding "S" and move around (useful for grass, or any numerous random placed object). Option that is not longer available.

[Jblade]

Quote

How would it be if sprites only used the new color scheme when textured floor mode is enabled? Still no good?

I used textured floor mode exclusively, sprites are damn near invisible now with that setting on if they're the same colour - I definitely would appreciate reverting back to the old system.

[Hank]

Hendricks266, on 13 March 2016 - 05:54 AM, said:

It seems like this change has met with near-unanimous dislike. I will look into reverting it, or at least making it a non-default option.

For anyone who does like it, in what circumstances would you use it? I can't think of a reason beyond aesthetic color matching...

How would it be if sprites only used the new color scheme when textured floor mode is enabled? Still no good?

As you know, with colours, everyone will have a different preference. If you use a lot of sprites, a colour code differentiating between SE, Light, Weapons, Enemies etc. is welcomed by me. Also, I never use texture mode on 2D view. I fine tune textures only in 3D.
Thus giving an option for yes/no, please do. Thanks

What may enhance the usage of mapster32 is to be able to see blocked sprites versus none blocked sprites.
And the display of SE sprites. First I see (sample) Tranport , 123'. then I hover with the mouse over it and it extends to 'SE 7 Transport, 123', and flashes. Why not just leave it as SE 7 Transport, 123?

[Mark]

I don't use textured floor either. While I am starting to get used to the new sprite colors I still prefer the old way better. For sure I would like to go back to the old color scheme for blocking walls and sprites. Other new features I'm fine with ( the ones I'm aware of anyway )

[TerminX]

Hank, on 13 March 2016 - 09:38 AM, said:

As you know, with colours, everyone will have a different preference. If you use a lot of sprites, a colour code differentiating between SE, Light, Weapons, Enemies etc. is welcomed by me. Also, I never use texture mode on 2D view. I fine tune textures only in 3D.
Thus giving an option for yes/no, please do. Thanks

What may enhance the usage of mapster32 is to be able to see blocked sprites versus none blocked sprites.
And the display of SE sprites. First I see (sample) Tranport , 123'. then I hover with the mouse over it and it extends to 'SE 7 Transport, 123', and flashes. Why not just leave it as SE 7 Transport, 123?

The flashing black is a bug I need to fix. Blocking indicators need some work as well--they are purple, but the Duke pal doesn't really have a purple range that works well here. Sprites don't change color when blocking anymore because it's a complete waste to have something as big of an indicator as a color swap used for showing a flag on sprites that the game changes to whatever it wants at map load time anyway. When was the last time it was more important to know quickly whether an object had a disposable flag applied, instead of what the object itself actually is?

Overall I find it weird how you some of you have so much trouble with the colorized sprites in 2D mode when I don't see such complaints from the teams actually using Mapster32 to make stuff for commercial games. The whole point is to be able to tell sprites apart at a glance without having to actually read the labels for everything, which were previously potentially all the same color--not really a good design cue when everything displays overlapped on top of everything else.

[Mblackwell]

Eh, it's useful to see what's blocking at a glance in 2D mode when deal with larger sprite constructions. It's not the end of the world though.

[Mark]

I don't understand the disposable flag thing. Does that apply only to vanilla content or does custom stuff get ignored at map load too?

[TerminX]

Mblackwell, on 13 March 2016 - 12:40 PM, said:

Eh, it's useful to see what's blocking at a glance in 2D mode when deal with larger sprite constructions. It's not the end of the world though.

I thought about that when I implemented it. I came to the conclusion that it would be a very rare occurrence for a mapper to make a sprite construction which required sprites be placed alongside sprites of the same tile number but with a different blocking mode. Even then, blocking typically goes along with hitscan, and the hitscan bit is still indicated by a wider sprite "tail".

[Mblackwell]

It's also partly nice so when on a static tile you can see when it might have been set to blocking accidentally and causing clipping issues.

But as I said it can be figured out one way or another usually. It mostly just sucks that a lot of tiles don't have a proper color match so they can look the same.

[Jblade]

Quote

Overall I find it weird how you some of you have so much trouble with the colorized sprites in 2D mode when I don't see such complaints from the teams actually using Mapster32 to make stuff for commercial games. The whole point is to be able to tell sprites apart at a glance without having to actually read the labels for everything, which were previously potentially all the same color--not really a good design cue when everything displays overlapped on top of everything else.

Please don't start pulling the 'commercial' team bullshit, I've been mapping for this game for about 17 years now and worked on dozens and dozens of maps and the new colour grade is not useful. Trying to write off everybody else's opinions because a few of you guys have had the freak chance to earn some money from it is really disrespectful man.

[Kyanos]

I think the commercial game may have a different palette and thereby different blocking colours, maybe why they aren't complaining.

[Mike Norvak]

TerminX, on 13 March 2016 - 12:01 PM, said:

The flashing black is a bug I need to fix. Blocking indicators need some work as well--they are purple, but the Duke pal doesn't really have a purple range that works well here. Sprites don't change color when blocking anymore because it's a complete waste to have something as big of an indicator as a color swap used for showing a flag on sprites that the game changes to whatever it wants at map load time anyway. When was the last time it was more important to know quickly whether an object had a disposable flag applied, instead of what the object itself actually is?

Overall I find it weird how you some of you have so much trouble with the colorized sprites in 2D mode when I don't see such complaints from the teams actually using Mapster32 to make stuff for commercial games. The whole point is to be able to tell sprites apart at a glance without having to actually read the labels for everything, which were previously potentially all the same color--not really a good design cue when everything displays overlapped on top of everything else.

Well, if "professional" mappers like to work with any new implementation as flawed or functional as it could be, that's ok. But please don't force us "amateur" mappers to get accustomed to a new workflow that only fit the interests of a particular mod or a commercial game.

[TerminX]

Jblade, on 13 March 2016 - 02:18 PM, said:

Please don't start pulling the 'commercial' team bullshit, I've been mapping for this game for about 17 years now and worked on dozens and dozens of maps and the new colour grade is not useful. Trying to write off everybody else's opinions because a few of you guys have had the freak chance to earn some money from it is really disrespectful man.

What the fuck? I'm not writing off everyone's opinions, I'm explaining the rationale behind the changes. I didn't realize it was disrespectful to say that I haven't really received any direct complaints from any of the teams I speak with who are working with Mapster32 to make maps. Not any more disrespectful than this clusterfuck of a thread devoid of any actual constructive criticism, anyway.

Mark., on 13 March 2016 - 02:02 PM, said:

I don't understand the disposable flag thing. Does that apply only to vanilla content or does custom stuff get ignored at map load too?

It's not so much ignored as it is overridden for a large set of hard-coded actors in the game.

Anyway, I'm open for suggestions to improve things but I'm not going to outright revert the change.

[Kyanos]

TerminX, on 13 March 2016 - 03:24 PM, said:

Anyway, I'm open for suggestions to improve things but I'm not going to outright revert the change.

Here's my two cents

1) a few lines in the config to set wall colors, red white blocking... good for tcs too
2) keep the per pixel color on sprites, with an option in tiles.cfg or somewhere to costumize colors per sprite if wanted
3) purple blocking sprites (original style) maybe deserves to be toggleable

[TerminX]

Drek, on 13 March 2016 - 04:06 PM, said:

2) keep the per pixel color on sprites, with an option in tiles.cfg or somewhere to costumize colors per sprite if wanted
3) purple blocking sprites (original style) maybe deserves to be toggleable

These are already there... you can set up tile groups that change the colors of things for both the normal and the blocking state.