dandelO's device not working

Started by mogn, April 26, 2009, 08:21:50 AM

Previous topic - Next topic

Oshyan

I understand what you want. What I'm saying is that TG2 currently does not have unique identifiers for nodes, it uses the node name, so that's why node names *must* always be unique, and hence TG2 renames nodes that have the same name as an existing node. As I said, we intend to fix this in the future.

- Oshyan

Mohawk20

I think an easier solution would be to increase the number from _1 to _2, in stead of adding an extra _1.
The result in this case would be 'point01_4' in stead of 'point01_1_1_1_1'.
Howgh!

mogn

Quote from: Oshyan on May 07, 2009, 02:14:56 AM
I understand what you want. What I'm saying is that TG2 currently does not have unique identifiers for nodes, it uses the node name, so that's why node names *must* always be unique, and hence TG2 renames nodes that have the same name as an existing node. As I said, we intend to fix this in the future.

- Oshyan

I wonnder why this (paint in the ass) has not been solved.

reck

mogn,

They've said they'll fix it and i'm sure they will. You don't have to remind them every 6 years.  :D

Matt

#19
Quote from: mogn on April 06, 2015, 08:04:23 AM
Quote from: Oshyan on May 07, 2009, 02:14:56 AM
I understand what you want. What I'm saying is that TG2 currently does not have unique identifiers for nodes, it uses the node name, so that's why node names *must* always be unique, and hence TG2 renames nodes that have the same name as an existing node. As I said, we intend to fix this in the future.

- Oshyan

I wonnder why this (paint in the ass) has not been solved.

Originally I intended that shaders could be uniquely identified by their path in the network; e.g. "shader1/subnode" would be different from "shader2/subnode", but early on a made it enforce globally unique names just to simplify the implementation.

I'll remove the globally unique requirement in our development builds now and see what issues show up. One of the problems that will need to be solved is how to diferentiate between "somenode" and shader1/somenode" when referenced by a shader1. Right now, shader1 can access shader1/somenode with either "somenode" or "shader1/somenode", so if there is another node on the same level as shader1 called 'somenode', they will clash.

Matt
Just because milk is white doesn't mean that clouds are made of milk.