Color changes made by an E2 are not copied by the duplicator tool

[nighthawk475]

It's a pretty simple to explain bug, and it's entirely possible the fault is in gmod/duplicator and not wire, but I can't prove that so I figured I'd post about it here in the event it is something fixable.

Title pretty much says it all, if you color a prop using an E2 chip and later try to copy and paste that prop with the duplicator tool the color changes do not copy with it, it is instead pasted with it's original coloring.

I've tried it on a prop spawned by an e2 chip, a prop I spawned from the Q menu, and another prop spawned from the duplicator tool.

I've tried E:setColor(V), E:setAlpha(N), E:setColor(N,N,N), E:setColor(V4), and probably one or two others of the setcolor/alphas, none of which have worked at all, (Set alpha doesn't copy either, not just RGB color)

And I've tried the built in duplicator tool from Gmod as well as Advanced Duplicator 2 and 1, none of them copy the colors on the prop

I originally found the bug on a multiplayer server but also tested it further in single player to confirm there was no weird addons from the server causing it to behave differently.

The code I ended up testing with mostly was just a simple one line e2 to change color:

@name ColorChanger
entity():isConstrainedTo():setColor(255,0,0)

I'd place the chip on the prop to change it's color, then undo (tried remover tool as well) the e2, and then copy it with duplicator and paste it to see if it would come out as red (or whatever color), never got it to work once

And I realize that if I duplicate the e2 I can have it recolor the prop but the original e2 I was writing when I ran into this bug will not work for that (I was trying to use the color of a prop as a sort of storage when a contraption was copy/pasted)
Also, yes, I tried just changing the color of props with the color tool and it did copy correctly, which is mostly why I assume this is a wire/E2 bug and not a Gmod/duplicator bug.

[thegrb93]

Yeah, I don't think e2 writes the color or material duplicator modifier to the object. Shouldn't be too hard to add it.

[nighthawk475]

I'm glad to hear that, if it's not too hard to fix I'd certainly appreciate it then ^.^,

[TomyLobo]

Does advdupe capture colors without someone explicitly a modifier?
If so, maybe that should be removed in order to align its functionality with garrydupe more
nm you mentioned that it doesn't

[Divran]

This is not only true for colors, but for anything that can be duplicated. Materials, etc. Tons of things. E2 doesn't save these things because it would add a lot of additional overhead, and it's pretty easy to re-apply them in if (first()) {. That said, it still might be a good idea to add this feature, I'm not sure.

[nighthawk475]

Well, my opinion on if it's worth it is biased, I think it would only be used for purposes similar to what I was trying to do. I was trying to store data using the color of a prop as the 'index' and it's position relative to the e2 chip as the 'value' stored (holding a single byte), I was hoping to make it easy to copy/reuse, especially for people who aren't familiar with e2, though I suppose I can do this using just position instead if it's never added.

I'm not sure if you meant overhead in terms of processing time, or memory taken, but if you meant the first, a slightly more logical reasoning behind why this could be added:
In general adding extra lines into color changing code is less impactful than say, applyForce, or arithmetic functions.
Either A) A chip will only use setColor/Mat/Alpha one time (per entity), and it won't make a huge difference except in the if(first()){
or B) The chips that will call setColor many times per second are generally joke/ 'rave' like things where changing colors rapidly is their only purpose, and the chip isn't responsible for much else, meaning it won't be limiting how much else the chip can do anyway.

applyForce and similar functions by comparison are called every tick in a lot of E2s, sometimes more, and when they are it's in chips which do a lot of other calculations and features, so adding overhead to them is significantly worse

Just an argument for why adding additional lines to setColor would be one of the most tolerable ways to add overhead.

However admittedly, pretty much anyone who posts here knows much better than I do how impact a change like this would be and whether it would be for the better or not.

[KiralyCraft]

This is still not solved. Got the same issue

[bigdogmat]

This is still not solved. Got the same issue

It has been explained why this isn't the current behavior, without any further discussion it was left to die.

[TomyLobo]

Well @nighthawk475's use case is broken, too. He should have used that dupable HDD thing i think @Divran added a while back.

@KiralyCraft Is your use case better than that?

[KiralyCraft]

I actually wanted to do the same thing, and this is so far the only thing i could find this useful for. However this would be something so simple to implement that i think i'm going to fix it myself

[abirduphigh]

@Divran, is this issue still open because you might still considering implementing the solution? I believe the project I'm working on could really use it.

The E2 allows the owner to build a house. For example: A holo "ghost" of a floor panel ( simple hunter plate prop ) is translated around the map by aiming and walking. The owner may spawn the panel by pressing the preset key ( E ) and propSpawn() places a matching physical entity.

I'm relying on the E2 to setColor() and setMaterial() of the spawned entity. I want the owner to be able to use advdupe to save the creation and paste with the color and material attributes intact.

Without being able to permanently set the color/material, I think I'd have to come up with a pretty heavy workaround that seems like a more expensive solution altogether. Perhaps there's a clever, inexpensive workaround that I'm not considering?

[Divran]

It's still open because it was forgotten. I dunno how much overhead the duplicator modifier function adds

[abirduphigh]

Ok well if it would still be considered, I'd really like to see this implemented. Duplicator can copy entity skin index and bodygroup index... but not color or material (and I guess also alpha?) It really feels like a bug more than anything else.