View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006038||DarkRadiant||GUI||public||31.07.2022 09:04||05.08.2022 06:27|
|Summary||0006038: Material Editor: changing the material will rewrite the declaration, dropping comments and custom whitespace|
|Description||Whenever an image path for a diffusemap/bumpmap/specularmap is changed, the material editor seems to rearrange the source text to some kind of default configuration or template. In some cases this lead to a loss of information:|
1) example textures/darkmod/decals/clock_hand_01_long_dark: comments are lost
2) example textures/darkmod/metal/detailed/panel_circledesign01_brown_ns: "noshadows" keyword is usually lost, while sometimes (i.e. textures/common/tdm_nodrawsolid_ceramic) it's preserved
3) example textures/darkmod/decals/webs/cobweb1: sort keywords may be changed, so i.e. "sort 5" becomes "sort close" when changing paths
4) example textures/darkmod/camera: "remoteRenderMap 232 232" is lost while blend gl_one, gl_zero is added
5) example textures/common/mirror: "mirrorRenderMap" and the "map" line are lost in the blend blend material stage
6) example textures/washroom/mirror: similar to (5), the "translate" line is lost in the "mirrorRenderMap" material stage
7) example textures/darkmod/decals/blood/blood09_fading: macros seem to be converted into their constituent keywords
8) example textures/darkmod/glass/clear_warp: "vertexprogram" is replaced with "program"
Maybe the generally safest option would be that simply changing image paths in the Material Editor only updates the paths themselves in the source text. So the rearrangement would only occur if working with the "Advanced" tab.
|Tags||No tags attached.|
This is something I cannot provide for the moment being. The source text is parsed and interpreted, but comments contained in the declaration body are inevitable lost by this process - they are not ignored by the parsing code, it doesn't even see them.
To change that behaviour the parsing approach would need to change completely to produce syntax trees including trivia, like the roslyn framework is doing. For now, any change to the material will lose whitespace and comments.
That's a shame - so I suppose for any change no matter how small, the material has to be reconstructed from the parsing and interpretation output.
So my suggestion of only updating the image paths themselves would be no good. Unless it's possible for the Material Editor just to take the current material source text, Find&Replace the paths, then feed it back into the parser?
|Any text manipulation is rather dangerous and might do more harm than good. If the search string is occurring more than once then this is most likely not doing what it should.|
I've split of parts of the report into another issue 0006052, because losing keywords is not something that should happen and could be caused by some different problem.
|31.07.2022 09:04||Dragofer||New Issue|
|31.07.2022 09:07||Dragofer||Description Updated|
|31.07.2022 15:05||greebo||Status||new => acknowledged|
|31.07.2022 15:43||greebo||Status||acknowledged => feedback|
|31.07.2022 15:43||greebo||Note Added: 0015100|
|31.07.2022 16:13||Dragofer||Note Added: 0015104|
|31.07.2022 16:13||Dragofer||Status||feedback => new|
|31.07.2022 16:13||Dragofer||Status||new => acknowledged|
|31.07.2022 16:29||greebo||Note Added: 0015106|
|31.07.2022 16:30||greebo||Summary||Material Editor: changing image paths can be destructive => Material Editor: changing the material will rewrite the declaration, dropping comments and custom whitespace|
|31.07.2022 16:32||greebo||Issue cloned: 0006052|
|31.07.2022 16:33||greebo||Note Added: 0015108|
|31.07.2022 16:33||greebo||Note Edited: 0015108|
|05.08.2022 06:27||greebo||Relationship added||related to 0006054|