Navigation

    TripleA Logo

    TripleA Forum

    • Register
    • Login
    • Search
    • TripleA Website
    • Categories
    • Recent
    • Popular
    • Users
    • Groups
    • Tags

    Dyeing/Colorizing Unit Images

    Feature Requests & Ideas
    10
    68
    14606
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • redrum
      redrum Admin @LaFayette last edited by

      @LaFayette I think you meant option #2 🙂

      prastle 1 Reply Last reply Reply Quote 1
      • C
        Cernel Moderators @LaFayette last edited by

        @LaFayette said in Dyeing/Colorizing Unit Images:

        I'd advocate for option 1.

        RGB is option 2 (except that it is just taking hue and saturation out of RGB info).

        1 Reply Last reply Reply Quote 1
        • prastle
          prastle Moderators Admin @redrum last edited by

          @redrum Anything that allows tweaking for my colour blindness I am willing to learn 😉

          1 Reply Last reply Reply Quote 0
          • Panther
            Panther Admin Moderators last edited by

            @redrum I vote for the RGB option.

            1 Reply Last reply Reply Quote 0
            • redrum
              redrum Admin last edited by

              I've decided to move forward with Option #2, thanks for everyone's feedback. I think this is easier for players to use since they already need to understand color codes when changing territory ownership colors.

              C 1 Reply Last reply Reply Quote 2
              • C
                Cernel Moderators @redrum last edited by Cernel

                @redrum So, how does the saturation work?
                If you define a RGB value, that value has a specific saturation value implied.
                Are all pixels in the units images, then, set to that same saturation value (like I assume it happens for the hue)? If not, how does it work?

                I think that, at this point, the most important item would be having a way of changing the hue without effecting the saturation, of the images (meaning each pixel in them keeps its original saturation value, only the hue changing).

                LaFayette 1 Reply Last reply Reply Quote 0
                • LaFayette
                  LaFayette Admin @Cernel last edited by

                  @Cernel I'd note that the HSB version would specify 'saturation' as well and would not be just a hue shift. Having both brightness and saturation be additional parameters would be nice, in this way a person could have a hue-only shift if desired and/or increase saturation explicitly. I think though we're getting to an over-engineering level. Adjusting unit color will still need manual work to make sure that it looks good, a hue only shift may not guarantee that the results will always look good. I don't think offhand it's that easy for the code to adjust 'hue' only.

                  1 Reply Last reply Reply Quote 0
                  • redrum
                    redrum Admin last edited by

                    Properties Description

                    # Unit color settings (apply effects similar to colorize functions of image editing tools)
                    #units.color.<player> applies the given color's hue and saturation to the player's units
                    #units.color.Russians=00BBBB
                    #units.color.brightness.<player> allows the brightness (-100 to 100) to be adjusted when above unit color is set 
                    #units.color.brightness.Russians=25
                    #units.color.flip.<player> flips the player's units horizontally
                    #units.color.flip.Russians=true
                    #units.color.ignore provides a comma delimited list of units that aren't impacted by the above units.color properties
                    #units.color.ignore=factory,fighter
                    

                    POS2 PR: https://github.com/triplea-maps/the_pact_of_steel/pull/33

                    ron-murhammer created this issue in triplea-maps/the_pact_of_steel

                    closed Update unit color properties #33

                    C 1 Reply Last reply Reply Quote 1
                    • C
                      Cernel Moderators @redrum last edited by Cernel

                      @redrum Strange that you have to set the other thing to be able to use the brightness option.

                      Even without any intentions of having anything flipping the units vertically, I believe the name should specify that the flipping is horizontal. Also probably not color. So like: units.transform.flip.horizontal.

                      LaFayette 1 Reply Last reply Reply Quote 2
                      • LaFayette
                        LaFayette Admin @Cernel last edited by

                        @Cernel said in Dyeing/Colorizing Unit Images:

                        Even without any intentions of having anything flipping the units vertically, I believe the name should specify that the flipping is horizontal. Also probably not color. So like: units.transform.flip.horizontal.

                        I strongly agree with you Cernel on color adjustment and image rotation not necessarily being related. These properties once defined are probably going to stick around for a very long time.

                        I'd also agree brightness and color would also be ideally decoupled, for now it's difficult on the backend. If there is a reason to need the feature, it could be a nice enhancement to see added later.

                        With regards to coupling, I've also been wondering if the 'ignore' of coloring and image flipping should be decoupled. Is it always the case that any unit where we want to ignore coloring, we will also always want to ignore image flipping? In other words, should a map maker be allowed to say "flip this image, but do not color it".

                        The cost of enabling that is likely duplication, ie:

                        units.color.ignore=factory,fighter
                        units.color.flip.ignore=factory,fighter
                        

                        But the above would allow for something like the following where, for example, 'fighters' are colored but not rotated:

                        units.color.ignore=factory
                        units.color.flip.ignore=factory,fighter
                        

                        For property names, I'd recommend keeping them singular and prefixing with "unit.image", as a suggestion:

                        unit.image.color.<Player>=FF00FF
                        unit.image.brightness.<Player>=100
                        unit.image.rotation.flip.horizontal={true|false}
                        

                        Or:

                        unit.image.color.<Player>=FF00FF
                        unit.image.brightness.<Player>=100
                        unit.image.rotation.flip={horizontal|none}
                        
                        C 2 Replies Last reply Reply Quote 2
                        • C
                          Cernel Moderators @LaFayette last edited by

                          @LaFayette Ah, right. It's important that the ignore thing will not effect the flipping; the two matters are really not related, and I can see you should not be normally wanting of not flipping the units you don't want to colourize. That's probably an even bigger reason than my purely self-consistent considerations.

                          1 Reply Last reply Reply Quote 0
                          • C
                            Cernel Moderators @LaFayette last edited by

                            @LaFayette said in Dyeing/Colorizing Unit Images:

                            With regards to coupling, I've also been wondering if the 'ignore' of coloring and image flipping should be decoupled. Is it always the case that any unit where we want to ignore coloring, we will also always want to ignore image flipping? In other words, should a map maker be allowed to say "flip this image, but do not color it".

                            The cost of enabling that is likely duplication, ie:

                            units.color.ignore=factory,fighter
                            units.color.flip.ignore=factory,fighter
                            

                            But the above would allow for something like the following where, for example, 'fighters' are colored but not rotated:

                            units.color.ignore=factory
                            units.color.flip.ignore=factory,fighter
                            

                            I believe that ignoring units for colourization should not effect flipping.
                            I would not have an option for ignoring units for flipping.

                            redrum 1 Reply Last reply Reply Quote 0
                            • redrum
                              redrum Admin @Cernel last edited by redrum

                              I've renamed the properties to use "units.transform" instead of "units.color" prefix:

                              units.transform.color.Germans=FF0000
                              units.transform.flip.Germans=true
                              units.transform.color.Russians=00BBBB
                              units.transform.brightness.Russians=25
                              units.transform.color.British=00FF00
                              units.transform.ignore=factory,fighter
                              

                              @Cernel The ignore needs to apply to flip as well as generally the units you ignore will either be things like factory which appear exactly the same for all nations (not flipped like the rest) or will be damaged BB or AA radar which you'll already manually colorize/flip if you want them to be ignored (wouldn't want to flip them back). I don't think there is really a use in TripleA to be flipping images and not coloring them which is why they share a single ignore unit list. Remember this isn't meant to be an image editing program just give users and map makers the common functions that they would need if creating a shared unit set.

                              C 3 Replies Last reply Reply Quote 1
                              • C
                                Cernel Moderators @redrum last edited by

                                @redrum Personally, if I would make an Axis vs Allies game, with Axis all facing a side and Allies all facing another side, and I would have something like a capturable emplacement or bunker (a combat infrastructure), I would have that unit too being one the flipped version of the other alliance, like all other units, while, as long as they don't move and always belong to the territory owner, I would leave them generically colourized the same way for everyone. For consistency, I would go the same way with factories, even if they would be non combat infrastructures, but I see that currently in assets the factories are all always the same, no matter where the other units appear to be facing. However, I believe having no colourization is not related to being a non combat units (as if you have mobile factories that can go in allied territories, you need to tell them apart), but to always belonging to the territory owner where the units is, which means being an infrastructure, and currently infrastructures can be combat units too, while this was not the case when Classic and Revised were made.

                                redrum 1 Reply Last reply Reply Quote 0
                                • C
                                  Cernel Moderators @redrum last edited by Cernel

                                  @redrum said in Dyeing/Colorizing Unit Images:

                                  @Cernel The ignore needs to apply to flip as well as generally the units you ignore will either be things like factory which appear exactly the same for all nations (not flipped like the rest) or will be damaged BB or AA radar which you'll already manually colorize/flip if you want them to be ignored (wouldn't want to flip them back).

                                  I really would go the same way with such things. If I'm colourizing a unit, I would colourize the same way also his damaged or tech versions (that is why I would not colourize units that have any sub-versions of the same being not monocolour, even if the basic unit is). Besides, elements that are beyond this scheme should rather really be icons that the program overlays.

                                  On this matter, it should be decided if calling "battleship" will call "battleship_hit" and "battleship_r" too, as well as if calling "aaGun" will call "aaGun_r", "rockets" and "rockets_r" too, as well as if calling "fighter" will call "fighter_lr" and "fighter_jp" and "fighter_lr_jp" too etc.. I think all those cases if you are calling the basic unit, all the related damaged or tech variants should be called too. So, for example, if I exclude "bomber", then "bomber_lr", "bomber_hb" and "bomber_lr_hb" should be excluded the same way, as well.

                                  1 Reply Last reply Reply Quote 0
                                  • redrum
                                    redrum Admin @Cernel last edited by redrum

                                    @Cernel Well looking at just about every existing map... it appears no one else agrees with flipping factories and similar units. I think the part you are missing is that the units that generally aren't colored/flipped are 0 movement capturable units which generally represent some sort of building/fortification/etc that it makes more sense for them to never "move" or change orientation as they are just being captured.

                                    Even look at TWW (probably the best map from a graphical standpoint) which has a bunch of these types of units (barracks, factory, rails, airbases, etc) and you'll see they all are uncolored and face the same direction for all nations.

                                    C 2 Replies Last reply Reply Quote 0
                                    • C
                                      Cernel Moderators @redrum last edited by

                                      @redrum Maybe I'm used to 270BC that when you capture a city it immediately becomes a completely different city.😆

                                      1 Reply Last reply Reply Quote 0
                                      • C
                                        Cernel Moderators @redrum last edited by

                                        @redrum Quick question: currently, if "factory" is excluded, are "factory_hit", "factory_it" and "factory_it_hit" excluded too?

                                        redrum 1 Reply Last reply Reply Quote 0
                                        • C
                                          Cernel Moderators @redrum last edited by Cernel

                                          @redrum said in Dyeing/Colorizing Unit Images:

                                          I've renamed the properties to use "units.transform" instead of "units.color" prefix:

                                          units.transform.color.Germans=FF0000
                                          units.transform.flip.Germans=true
                                          units.transform.color.Russians=00BBBB
                                          units.transform.brightness.Russians=25
                                          units.transform.color.British=00FF00
                                          units.transform.ignore=factory,fighter
                                          

                                          @Cernel The ignore needs to apply to flip as well as generally the units you ignore will either be things like factory which appear exactly the same for all nations (not flipped like the rest) or will be damaged BB or AA radar which you'll already manually colorize/flip if you want them to be ignored (wouldn't want to flip them back). I don't think there is really a use in TripleA to be flipping images and not coloring them which is why they share a single ignore unit list. Remember this isn't meant to be an image editing program just give users and map makers the common functions that they would need if creating a shared unit set.

                                          In GIMP "transform" means those things like rotating etc., not changing colours, but of course this is just a nomenclature. For coherency with "flip", I suppose the other one should be called "colorize" instead of "color", but, then, it would be not coherent with "brightness", instead (tho this is the same in GIMP too). Maybe it should be rather called "hs", or something hinting that it is changing only the hue and saturation, not sure.

                                          1 Reply Last reply Reply Quote 0
                                          • redrum
                                            redrum Admin @Cernel last edited by redrum

                                            @Cernel Yes, currently it checks the actual unit name against the ignore list not the specific image. So will ignore transforming for all the unit's various images (_hit, _lr, _it, etc). I figured that probably makes more sense but I'm open if folks feel they would want ignore to list each specific image for a unit.

                                            Well, "color" fits better with "brightness" and "color" is used in other areas of the map.properties. "flip" is probably the one that's a bit questionable but I think that was the most straightforward name I could think of.

                                            1 Reply Last reply Reply Quote 1
                                            • 1
                                            • 2
                                            • 3
                                            • 4
                                            • 3 / 4
                                            • First post
                                              Last post
                                            Copyright © 2016-2018 TripleA-Devs | Powered by NodeBB Forums