If possible, I think a good solution is to have a subfolder called pallets and inside that one more subfolders titled 000 and then 001 and 002 to as many as we want. Then have several palette bmps inside each, then in the map builder options, be able to select which palette folder to use for the palette and also for npc head shots could be told what palette to use (which could just be a copy of the headshot being used as its palette)
Correct me if i'm wrong but I think there are patch commands that will change palettes on the fly.
I agree with keeping the custom palette though. I have various yellows and reds and greens and blues that are all important. And grey to black. Since I will use a dream world and outer space.

I like the optional color remapping idea. if the 16 color thing were a permanent fixture it would still make my job much more difficult because i am frequently remapping my custom pallete to account for new tiles i create and add to it and i switch back and forth between indexed and rgb mode taking advantage of Photoshop's excellent auto-palette conversion features and tools. So if I had to always keep the first 16 a set order and color I would have to manually select and move or rearrange all the colors in the palette, select 16 of them for deletion and then manually add in each of the 16 colors in their proper places. And I would have to do this every time i decided to add something new to the palette.

I think to avoid stepping on the toes of designers like Garth who have spent a lot of time customizing their game palette, I would probably have an optional 'color-remapping' feature, which can be used to define what the base colors are.

If your first 16 palette entries are the 'default' color values (or something close to them), then no problem, otherwise you could set up remappings like:

colormap 0 100

for example, where 0 is the default color (which would normally be black or the background color). In your palette, however, color 100 is black, so this makes the necessary adjustments.

This wouldn't affect tiles, bitmaps, etc. which already have the pixels predefined; just stuff like fonts, lines and other graphics that are drawn on the fly (indicator arrows, flashing selector boxes, things like that). I might adjust any 'system icons' that are used (like the crosshairs or the 'this weapon/armor is selected' arrow) so that if they use the base 16 colors, they can be remapped when loaded. Or alternatively, this could be solved by making the system icons editable like the rest of the tiles.

rld wrote:In your custom palettes, do you tend to keep the first sixteen colors set to the 'standard' values, or do you change those as well? If ACK could at least assume that the first sixteen palette entries had known values (or force them to known values) that would make it easier to ensure that all the editor graphics, etc. behaved consistently, like that selector box you had mentioned.

That is a good compromise; since much of ACK is geared to the first 16 colours being DOS/CGA ones. Remember CGA and EGA, anyone? There are still some issues where ACK assumes the first 16 colours are standard.

BTW, I use only the standard palette (so far).

Good point - have to keep in mind lots of people are not as lazy about graphics as I tend to be. :)

In your custom palettes, do you tend to keep the first sixteen colors set to the 'standard' values, or do you change those as well? If ACK could at least assume that the first sixteen palette entries had known values (or force them to known values) that would make it easier to ensure that all the editor graphics, etc. behaved consistently, like that selector box you had mentioned.

Yeah I can see how that would simplify things from a modding perspective as well as making it easier on new ppl coming trying ACK for the first time. However, that would completely ruin all of my custom tiles i worked so hard on and make it impossible to recreate anything like them. I make extensive use of subtle variations of color, both hues and brightness to achieve a much smoother or more seemless over all look when all tiles are seen together.

Having to limit myself to a single hard coded palette would make graphics such as appear in screenshots of my Wasteland remake impossible. And when I finish that and move on to some other genre or theme with an entirely different mood or atmosphere I am going to want to develop a complete different palette with a completely different overall dominant hue and brightness level and some specific colors I would need more or less variations of than others. I just never know until I actually start working on them.

I think I would almost prefer to have the palette dependency and setting functions removed, and just have a hardcoded palette. You could have some tools to convert tiles and BMP files from whatever palette they were using to the hardcoded palette, or have ACK do some of it on the fly as it loaded tiles/pictures, if that didn't slow things down too much.

But if you knew the palette in advance and made it fixed, that would make it a lot easier to do more interesting on the fly graphic effects in the engine (like for projectiles and spell effects) and also do things with tiles like make them fade/reappear by using the predetermined color gradients. Or have a 'brighten/fade' function in the tile editor.

Maybe if possible have the macro and dialog editors show more lines at once too in addition to the pgup/pgdn suggestion.

And yes all map editors could use some improvement.

tile editor: I have difficulties with the hard coded selection box that is supposed to be a visual aide that shows you which tile is the currently selected one. I waste so much extra time messing with my custom palettes just to get the selector to show up and so far rather unsuccessfully. Since it is hard coded it should not depend at all on whatever palette you are using or if it must then there should be a built in default palette that the hard coded stuff always uses. Otherwise, remove the palette dependency and add to the hard coding a specific color designation for things like the tile selection box, pure white would probably be best.

And the color selector has always been difficult for me to use. the blinking cursor over the currently selected color in the color palette obscures the color it is on so that i have a hard time telling what color it is, especially if it is among similar colors. Would be nice if there was a currently selected color indicator that showed you a larger version of the color currently selected which changes as you navigate through the pallete moving the cursor from color to color.

I found no bugs - but - as I said before - I do a lot of editing of large macros and would find it nice to use the PgUp / PgDn keys to do pagewise scrolling. It wouldn't be a big change to the Macro Editor but it would save me from pounding or holding down the arrow keys to get to line 74.

whenever I change the map edge options, the map gets changed. Sometimes it is only a 16x16 space, but then
on a larger map there were 3 16x16 portions. So I thought that maybe it was due to making the map first before deciding what edges do. I readied myself to say the map edge (when portal) before making the map and 3 16x16 chunks of the map the portal went to showed up on the newly created blank map. I just erased those parts and no further problem happened.

Ok, so by fiddling around with some of the content in ACK04.PAS, I got rid of the error that was preventing the editor modules from compiling from the source distribution.

Are there any bug fixes or minor changes that anyone has seen that need to be made to the editor portions of ACK, like the object editor, macro editor, or creature editor? Those are probably the most likely bits that I would actually try to tinker with. In particular, it would be nice to have the macro editor recognize the patch commands, etc.

Still looking to keep the data files compatible with standard ACK, so anything I change would have to keep the data files to where they could be opened in either the patched version or the nonpatched version without crashing anything.