Note about scripts with explicit dress options (those using DressDescription blocks)

[onevision]

In the dropdown menu of several dress zones I found "Option X" and "Option 0X" definitions mixed up.
Since the automatic/primary options use the second convention, I corrected all my dress scripts to "Option 0X".
It's not just an eyesore, it might also be a source of conflicts between addons. This is why I invite you to adhere to this convention in future addons.
Thanks in advance.

[HDiddy]

Kind of confused to what exactly your talking about. Can you post a picture. 

[onevision]

On 4/19/2022 at 5:23 PM, HDiddy said:

Kind of confused to what exactly your talking about. Can you post a picture. 

Of course. Here it is.

There is also another little problem with scripted dress options... Duplicate entries

The first Option 01 was actually named Option 1 before my correction.

I guess this is happening because of the mixed use of automatic options and Dress_Descriptions. I'm looking into it to find a solution.

 

I thought the check:

if !defined

was enough to prevent this from happening, but somehow there is a problem.

[onevision]

You may want to check out my version of the dress script (adapted to vanilla VX )

DcDressVX_DP16Corset17(edit).zip

The duplicate entry is likely due to an "Option 01" declared by a different item in the Corset category, probably with a different method.

Or used as secondary option by a Catsuit item. Hard to tell which one.

[HDiddy]

Ahh ok...seems DP16 is using some non standard way to call dress options which is most likely tied to how the F7Curvy Repack is setup.  The issue is the If statement called first in the scripts.

For reference below is what a standard Dress script with options looks like.

 

DressDescription :DressHDiddyDress17_Description . {
	.DressID I32(0);
	.SceneScriptFile [ :DressBaseDir + "AcHDiddyDress17" , :P + "HDiddyDress17" ];
	.DressName "Little Seduction";
	.PickNodeNameArray [ 
		:P + "HDiddyDress17:HDiddyDress17_mesh";
		:P + "HDiddyDress17:HDiddyDress17_alt1_mesh";
		:P + "HDiddyDress17:HDiddyDress17_alt2_mesh";
		:P + "HDiddyDress17:HDiddyDress17_alt3_mesh";
		:P + "HDiddyDress17:HDiddyDress17_alt4_mesh";
		:P + "HDiddyDress17:HDiddyDress17_alt5_mesh";
		:P + "HDiddyDress17:HDiddyDress17_alt6_mesh";
	];
	.CmdArray [ DressCmd . {
		.Show I32(1);
		.Target :P + "HDiddyDress17:HDiddyDress17_group";
	};
	DressCmd . {
		.IfDressArray I32 [ :option1 , :option2 , :option3 , :option4 , :option5 , :option6 , ];
		.Show I32(-1);
		.Target :P + "HDiddyDress17:HDiddyDress17_mesh";
		.Optional True;
	};
	DressCmd . {
		.IfDress :option1;
		.Show I32(1);
		.Target :P + "HDiddyDress17:HDiddyDress17_alt1_mesh";
		.Optional True;
	};
	DressCmd . {
		.IfDress :option2;
		.Show I32(1);
		.Target :P + "HDiddyDress17:HDiddyDress17_alt2_mesh";
		.Optional True;
	};
	DressCmd . {
		.IfDress :option3;
		.Show I32(1);
		.Target :P + "HDiddyDress17:HDiddyDress17_alt3_mesh";
		.Optional True;
	};
	DressCmd . {
		.IfDress :option4;
		.Show I32(1);
		.Target :P + "HDiddyDress17:HDiddyDress17_alt4_mesh";
		.Optional True;
	};
	DressCmd . {
		.IfDress :option5;
		.Show I32(1);
		.Target :P + "HDiddyDress17:HDiddyDress17_alt5_mesh";
		.Optional True;
	};
	DressCmd . {
		.IfDress :option6;
		.Show I32(1);
		.Target :P + "HDiddyDress17:HDiddyDress17_alt6_mesh";
		.Optional True;
	};
	DressCmd . {
		.Target :P + "HDiddyDress17:HDiddyDress17_tex2d";
		.ParamID I32(2);
		.Attr @ TransformLayer .ColorAddHSV;
		.Value @ ( I32(0) , I32(0) , I32(0) );
	};
	];
	.PrimaryZone :DZ_Dress;
	.DressIconID I32(0);
};

 

[Smoke]

4 hours ago, onevision said:

You may want to check out my version of the dress script (adapted to vanilla VX )

DcDressVX_DP16Corset17(edit).zip 718 B · 1 download

The duplicate entry is likely due to an "Option 01" declared by a different item in the Corset category, probably with a different method.

Or used as secondary option by a Catsuit item. Hard to tell which one.

The value of "0X" is from 7.5. No diss to dp16 but most of the code that he uses either has not been update, probably because he sees no use for it or he hasn't had time to update it.

Regardless, the 7.5 codes are a mess, perfect example is the codes within that file.

The new codes that the game read are what HDiddy wrote. IMO it gets rid of many back and forth codes that really has no use. Like this code:

if ( ! defined ( :Dress13301_Description ) ) {
	DressDescription :Dress13301_Description . {
			.DressID I32(13301);
			.PrimaryZone :DZ_LatexWaist;
			.DressIconID I32(3554);
			.DressName "Option 01";
	};
};

Also note - both methods works in VX. If you are injecting a 7.5, you will have to add a additional code for it to appear and function correctly. But why would you want to overly complicate the codes?

I recall I did this when I was release dual addons (7.5 and VX) and it is a hassle.

[onevision]

@Smoke Yes and no.

"Option 0X" is what you get in VX when using auto-generated options for the primary dresszone (see script). So it's not a 7.5 thing of the past.

But you and @HDiddy are probably right when you say the if statement is the culprit.

I had my reservation about it, I see now that it's a peculiarity of the repack and normally shouldn't be used.

Thank you both!

 

Addendum:

Sometimes it's necessary to use both methods, for elaborate dress options such as those of certain catsuits. It helps keeping the number of options low.

Example: dress with short/medium/long legs options and MC/BBB/Default options.

You can easily run out of dress options this way (dress options can't be more than 10 in the same dresszone - 9 if you start the numbering at XXX01, which is commonplace).

Using also latex options this goes up to 11 (or 10, if XXX00 is unused).

At any rate, my initial remark was about encouraging the use of

.DressName "Option 01";

instead of

.DressName "Option 1";

[Smoke]

1 hour ago, onevision said:

"Option 0X" is what you get in VX when using auto-generated options for the primary dresszone (see script). So it's not a 7.5 thing of the past.

No - its not a VX thing. That code been there since the 7.5 days.

I believe there are a total of 6 different methods in which people can use the option/latex morphs, they all be there for a long time.

Pretty sure you don't want to here my criticism on why it isn't being used. But to shorten it, if the former MG leadership weren't on a ego trip and running modders out for their sake of their pride, such codes code of been implemented and tested.

But returning to this - yes we been warning people about repacks. And dp16 is unique in its own way, not in a bad way but because its recommended to you don't mix and match if you don't know what you are doing and/or his repack is heavily modified to fit his niche. He's been using these codes since 7.5 - hence on the heavy/or alot of latex options. I know this because I had access to it way before VX launched (R9X days lol) and saw that this outfit and many others are heavy users of latex morphs - which I see why he chose this method (to give him a better gameplay for his repack).

On 4/19/2022 at 6:47 AM, onevision said:

It's not just an eyesore, it might also be a source of conflicts between addons. This is why I invite you to adhere to this convention in future addons.
Thanks in advance.

I can see the double being an eyesore but that is the consequences of mixing addons from a repack. And no - I'm certain that these codes/method does not conflict between addons because it is just not possible. The only way it could conflict if the user decided to copy and paste the same code into their addons without fixing the code itself and/or bad coding itself. 

Also imploring to change to another method is not possible right now because you can't rely on just certain people to change their ways. The damage is done and will remain there until it is found and fixed. And in order to have all on board - it will need to be done as a group effort and someone WILL have to document which mods are using different codes - a time consuming task that people don't want to deal with.

3 hours ago, onevision said:

Sometimes it's necessary to use both methods, for elaborate dress options such as those of certain catsuits. It helps keeping the number of options low.

Example: dress with short/medium/long legs options and MC/BBB/Default options.

You can easily run out of dress options this way (dress options can't be more than 10 in the same dresszone - 9 if you start the numbering at XXX01, which is commonplace).

This is my opinion here but I favor PE/customization morphs over static/latex morphs. Given, that I do use static/latex morphs on several occasion, but I never create 5+ version. I only use latex morphs IF the mesh completely changes position in which weights can create major interference in PE mode. But adding a ton of latex morphs - you are basically creating a bloated file, in which, if its too heavy, can crash you game.

[onevision]

I prefer static morphs instead. They fit perfectly straight away, while dynamic ones require a lot of adjustments. Which would be perfectly fine if said adjustments would be persistent but, alas, simply changing the activemod texture will reset the sliders. Having to create a save file for each customization is not very practical in my opinion.

[Smoke]

Well - like I told some people. With PE morphs, take smaller step for greater results. Going big will most likely disappoint you. That why stopped doing crazy PE morphs and some what made a static morph for certain scenarios - its like I mentioned, if the weights shift, it can create massive clipping and unwanted stretching.

[onevision]

16 hours ago, Smoke said:

Well - like I told some people. With PE morphs, take smaller step for greater results. Going big will most likely disappoint you. That why stopped doing crazy PE morphs and some what made a static morph for certain scenarios - its like I mentioned, if the weights shift, it can create massive clipping and unwanted stretching.

Just don't take my words as belittlement of the efforts you, HDiddy and others are putting into dynamic morphs. I'm the first to say that the results are amazing.

Maybe the ideal solution is a combination of dynamic morphs and body autodetection in scripts.

By the way, I removed the if statement and my scripts now work like a charm. No more duplicate entries

[HDiddy]

I think the issue with PE Morphs was simple the timing at which they came out and just the state of the community at the time.  While Rick9 and Euphie were pioneering morphs with version R9X..it was the lesser used version very few people where using. By the time it came to VX, the community was more or less a shell of itself.  All this was important because a feature like that needed content creators to take it and use it to really show off what you can do, but so many people had left and there was not much content being produced...especially with VX.  Static Morphs caught speed mainly because towards the final years of MG it was @Smoke that was single handedly making the only add-ons with morphs...and outside of pull me panties, people really started to see how nice they can be.

Back then released a pose that specifically made use of dynamic morphs but it didn't get much love.  Personally i think the most important morphs you can have on any clothing are adjustment morphs, then dress options, then dynamic morphs.  I too have slimmed down the mount of PE morphs for clothing just because I find dress options more useful most of the time