Copying and pasting chips, adding the chip name to the top of screen, pin I/O colors

[masademan]

I would LOVE to have a Ctrl+C/X and Ctrl+V. It's cool that when you drag from menu bar at the bottom, holding shift duplicate them, but I don't like how you can't duplicate a bunch of chips you already placed down.

Also, side note, would love a textbox at the top that tells you what chip you're working in, just in case you forget, or it's a project you work on time to time.

[Dom-c-d]

there is a basic duplication, highlight the chips you want and press Shift+D

[RobMayer]

you might want to make the name of this ticket something meaningful so it's easier for folks, namely Seb, to actually parse

[masademan]

👍

[masademan]

there is a basic duplication, highlight the chips you want and press Shift+D

I guess this works, but if I want to copy and paste something from one chip to a different chip, this doesn't quite pan out anymore.

[BestGiter]

what about pin I/O colors, do you want more

[masademan]

Yeah, maybe like an RGB type thing after the default colors. I'm working on an 8-bit computer and I run out of colors pretty quickly

[Dom-c-d]

I have actually been tinkering with adding more colors, adding more default options would be simple but adding a custom input need some more work

[Raniem36]

I have actually been tinkering with adding more colors, adding more default options would be simple but adding a custom input need some more work

You already have custom input for chip colors. Why would it be difficult to add the same behavior to pins?

[RobMayer]

I have actually been tinkering with adding more colors, adding more default options would be simple but adding a custom input need some more work

You already have custom input for chip colors. Why would it be difficult to add the same behavior to pins?

Probably because of how the pins and wires use a different mechanism to store their colors. Pins and wires seems to be enumeration based: 0 == red, 1 == yellow, etc, etc, whereas chip colors are actual RGB values.

[Dom-c-d]

I have actually been tinkering with adding more colors, adding more default options would be simple but adding a custom input need some more work

You already have custom input for chip colors. Why would it be difficult to add the same behavior to pins?

Because they are not handled in the same way, currently pin colors are hard coded values and the pin only saves the index for the color. But to have a custom pin color the system needs to change it to saving the pin colors to the project save and then dynamically populating the context menu. then you need a way to input/edit/delete colors so thats a new menu to build

[Raniem36]

I have actually been tinkering with adding more colors, adding more default options would be simple but adding a custom input need some more work

You already have custom input for chip colors. Why would it be difficult to add the same behavior to pins?

Because they are not handled in the same way, currently pin colors are hard coded values and the pin only saves the index for the color. But to have a custom pin color the system needs to change it to saving the pin colors to the project save and then dynamically populating the context menu. then you need a way to input/edit/delete colors so thats a new menu to build

Ah makes sense. Thank you

[DaBaldEagul]

Because they are not handled in the same way, currently pin colors are hard coded values and the pin only saves the index for the color. But to have a custom pin color the system needs to change it to saving the pin colors to the project save and then dynamically populating the context menu. then you need a way to input/edit/delete colors so thats a new menu to build

Would it be possible to have both HEX and the current default options implemented? I.e. the wire has 2 values: color and hexColor. The color remains as it is now, and hexColor is either set in the save already, or it gets set on runtime based on the color enum.

This way, old save-files aren't impacted, but the complexity of adding the custom color values is reduced as well. You wouldn't have to deal with maintaining a list of possible enum values.

The only drawback would be that it wouldn't be as easy to select custom colors as it is to select default ones, since you'd need to copy-paste the hex code every time. But an array could be used, so (at least within a session) some recent colors can be remembered. This way you still avoid adding a new menu for editing the project's colors to disk.

[Dom-c-d]

Would it be possible to have both HEX and the current default options implemented? I.e. the wire has 2 values: color and hexColor. The color remains as it is now, and hexColor is either set in the save already, or it gets set on runtime based on the color enum.

This way, old save-files aren't impacted, but the complexity of adding the custom color values is reduced as well. You wouldn't have to deal with maintaining a list of possible enum values.

The only drawback would be that it wouldn't be as easy to select custom colors as it is to select default ones, since you'd need to copy-paste the hex code every time. But an array could be used, so (at least within a session) some recent colors can be remembered. This way you still avoid adding a new menu for editing the project's colors to disk.

I mean at that point you are just complicating the system, if you are going to introduce custom colours (which i did in my own build) you may as well just scrap the enum and save a list of custom colours to the project file and have it start the list with the default colours.

Its not that its not impossible to do, its that you need to rewrite how the colours are handled/applied to the sim and how that menu of colours is loaded and updated. And then for handling old saves you just have it update the old indexes to a default value if it cannot map the old value to a new one (you shortened the list of colours for example)

There was a brief discussion about the number of colours actually needed in the discussions section of github where the question of really, how many custom colours could one need before they look too alike? (keep in mind each colour is actually 3 different ones, for Low state, High state and when hovered) theres not a huge number of new options. So really could Sebastian just add one or two more colours and that would meet everyones needs?

[DaBaldEagul]

you may as well just scrap the enum [...] And then for handling old saves you just have it update the old indexes to a default value if it cannot map the old value to a new one

The reason I said 2 values is so that presently applied colors will not be reset to some default. Because it'd be a PITA to change every wire to the color you want after updating.

its that you need to rewrite how the colours are handled/applied to the sim and how that menu of colours is loaded and updated

That is fair, but seems relatively easy for the amount of times it has been requested (alas, speaking as not-a-C#-or-Unity-dev). Personally I don't really mind if wires are fully customizable or not, I was just reading through some GH issues because I have nothing better to do and this one got my mind spinning.

[Dom-c-d]

The reason I said 2 values is so that presently applied colors will not be reset to some default. Because it'd be a PITA to change every wire to the color you want after updating.

It wouldn't need to update all of them, if you preserved the colour order when changing the system, as long as the user doesnt make their list shorter than the default they would move over to the colours ok and then you can just save them with the new way of storing (in my case i changed this to save colours by name so if someone wants to copy chips over itll look by name and not the index to try and preserve colours better, and if it detects this is an integer storing an index for an old chip it falls back to indexing by order for that chip)

That is fair, but seems relatively easy for the amount of times it has been requested (alas, speaking as not-a-C#-or-Unity-dev). Personally I don't really mind if wires are fully customizable or not, I was just reading through some GH issues because I have nothing better to do and this one got my mind spinning.

While its not a hard thing to add, it is quite a bit of work to do as you've also then got to add in a new screen for colour creation/editing/deletion. As well as changing the save/load systems. When i implemented this i think it was ~400-500 lines of code changed/added and it still wasnt complete enough that it would be a new version. It still needed more work to catch issues like all colours being deleted otherwise the game crashes, or what to do if the list gets too long. adding in a colour picker rather than only being able to type values.

For what little it really adds (previous comment on limited variety of colours) its a lot of work, and with the game needing more optimisations to improve performance this probably ranks low in a list of things todo.

[DaBaldEagul]

I guess I wasn't quite clear in my explanation. Basically my suggestion would be to leave the current enum system as a "legacy" implementation for old saves, and basically replace it with hex codes. Colors can just be saved to the wires/pins themselves, so you don't have to change any project-wide settings, and there wouldn't be issues with deleting all of the colors – the base colors still exist and are not modifiable.

[Dom-c-d]

Colours are currently handled as a single int within the Pins instance, and then that int is used as an index to colour values hardcoded, and the right click menu on pins populates the colours from the enum values stored in the same order.

In your idea we save the colours to the pins but how do we consistently use those across our save? do we need to note down and copy the Hex code everytime we do a new Pin? otherwise we do need to change project wide settings to add in the custom colour list somewhere accessible to tack on to the end of the right click menu after the enums and to the lists of colour values.

If we stuck with only saving colours in the Pin instances we now need to check every pin in every chip file on startup to see if its custom, check if we already have that one loaded and then add it to the list if not. And then if we update a colour do we need to check every existing chip for the old value and update or do we now just end up with odd colours dotted about?

And further to saving on the Pins, you would have to then change the way we store and save the Pin data so it can handle both the index as an int and the Hex value as a string (although the system uses RGBA so might be better to store those values directly as a Color type, like chips do) either way this has now made the existing classes more complicated to handle.

The system simply wasn't built for custom colours and adding them in wouldn't just be a small change, so rather than use a mix of old and new, you'd be better off biting the bullet and updating it entirely. And then you are still not going to see any crazy high number of colour saves as there really isnt too many colours that you can use that look distinct enough to justify the changes

[DaBaldEagul]

Alright, thanks for clarifying! I am not a designer or C# dev so I don't have a lot of experience with the best ways to handle some things here. I would like to say that I did in fact address the convenience factor of selecting colors before, though:

The only drawback would be that it wouldn't be as easy to select custom colors as it is to select default ones, since you'd need to copy-paste the hex code every time. But an array could be used, so (at least within a session) some recent colors can be remembered.

Changing this system sounds like it is more work than I thought at first glance, though! So thanks again for the info :)