Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Backburner] Errors with conditionalDefaultParts #1744

Open
DrprofLuigi opened this issue Dec 16, 2023 · 1 comment
Open

[Backburner] Errors with conditionalDefaultParts #1744

DrprofLuigi opened this issue Dec 16, 2023 · 1 comment
Labels
bug Code broke, fix yes? needscvs

Comments

@DrprofLuigi
Copy link
Contributor

DrprofLuigi commented Dec 16, 2023

These errors are present in MTS V22.12.0

Note: Both of these issues are somewhat minor as I have made workarounds for both, so this is more of a 'it would be cleaner' sort of suggestions.

Issue 1

When I place a vehicle that spawns with a bed, which itself spawns with a spare wheel, that spare wheel spawns as the wrong color:

2023-12-16_10 16 23

Here are the relevant json snippets:

UNU Mule (base vehicle)

		{
			"name" : "§3UNU Mule §7[ZF-174-MCG]",
			"subName" : "_forrest",
			"partTones": ["_forrest", "_saddle", "_blackthorne", "_forrest"],
			"constants": ["axle_budd", "axle_double", "wheel_truck_budd_forrest", "truckbed_cargo"],
			"extraMaterials" : ["minecraft:dye:0:1", "minecraft:dye:2:3"]
		}
		{
			"pos": [0, 0.5, -0.65625],
			"types": ["generic_bodypart_unu_truckbed_heavy_double", "generic_bodypart_unu_truckbed_mule_double"],
			"conditionalDefaultParts": {
				"truckbed_cargo"="unumilitary:unumilitary_bodypart_unu_truckbed_mule_cargo_desert"
			},
			"toneIndex": 4,
			"minValue": 0,
			"maxValue": 3,
			"interactableVariables": [["!part_present_38"], ["!part_present_39"], ["part_present_35"]],
			"applyAfter": "$FrameBed"
		}

Cargobed (part):

		{
			"name" : "§3UNU Mule Cargo Bed",
			"subName" : "_desert",
			"partTones": ["_desert", "_saddle", "_blackthorne"],
			"extraMaterials" : ["minecraft:dye:0:1", "minecraft:dye:11:3"]
		}
		{
			"pos": [0.9375, -0.1875, 1.125],
			"rot": [0, 0, 115],
			"allowParentRemoval": true,
			"isSpare": true,
			"types": ["ground_wheel_budd"],
			"defaultPart": "unuparts:unuparts_part_unu_wheel_truck_budd",
			"conditionalDefaultParts": {
				"wheel_truck_budd_desert"="unuparts:unuparts_part_unu_wheel_truck_budd_desert",
				"wheel_truck_budd_forrest"="unuparts:unuparts_part_unu_wheel_truck_budd_forrest",
				"wheel_truck_budd_winter"="unuparts:unuparts_part_unu_wheel_truck_budd_winter"
			},
			//"toneIndex": 1,
			"minValue": 0.625,
			"maxValue": 1.25
		}

Note: I tried using partTones, but it had the same result.

When I change the conditionalDefaultParts bed to the winter variant, the problem goes away.

Explanation:
When the bed spawns, it first spawns as the Desert variant, setting the desert variable, THEN the bed switches to the appropriate color, but the spare tire does not. This is because the winter variable gets set, but the desert/forrest variable is ALSO true, so it spawns whichever comes first, which is the correct color.

2023-12-16_10 08 09

Issue 2

A vehicle will spawn with this second axle present, even though it shouldn't:

2023-12-16_10 17 52

Here are the relevent json snippets:

		{
			"name": "§3UNU Camel Firetruck (Red) §7[TB-313-MCC]",
			"subName": "firetruck_red",
			"textureName": "unucivil_vehicle_unu_camel_red",
			"partTones": ["", "_saddle", "_blackthorne", "_red"],
			"secondaryTextColors": ["#CF9E4F", "#FEFEF0", "#FEFEF0"],
			"constants": ["axle_budd", "truckbed_firetruck", "gyrophare_l_blue", "gyrophare_r_blue"],
			"extraMaterials": ["minecraft:dye:1:5"]
		}
		{
			"pos": [0, 0, -1.3125],
			"types": ["generic_suspension_unu_leaf_heavy_back", "generic_bodypart_unu_suspension_camel_back"],
			"conditionalDefaultParts": {
				"!axle_double"="",
				"axle_budd"="unuparts:unuparts_suspension_unu_leaf_heavy_back_budd",
				"axle_dayton"="unuparts:unuparts_suspension_unu_leaf_heavy_back_dayton"
			},
			"minValue": 0,
			"maxValue": 1,
			"interactableVariables": [["!part_present_18"]],
			//"lockingVariables": [["!part_present_22"]],
			"applyAfter": "$FrameBed",
			"constantValues": {
				"frame_axleIsSecondary": 1,
				"frame_driveshaft_x": 0.001,
				"frame_driveshaft_y": 0.001,
				"frame_driveshaft_z": 1.15625
			}
		}

The first entry is "!axle_double"="", so the part slot should be empty if axle_double is zero. Similar logic works with my standard wheels to prevent a hubcap from spawning on spare tires:

2023-12-16_10 18 03

			"conditionalDefaultParts": {
				"spare_hubcap_moon"="unuparts:unuparts_part_unu_hubcap_standard_moon",
				"spare_hubcap_dish"="unuparts:unuparts_part_unu_hubcap_standard_dish",
				"spare_hubcap_deluxe"="unuparts:unuparts_part_unu_hubcap_standard_deluxe",
				"spare_hubcap_turbine"="unuparts:unuparts_part_unu_hubcap_standard_turbine",
				"part_isspare"="",
				"hubcap_moon"="unuparts:unuparts_part_unu_hubcap_standard_moon",
				"hubcap_dish"="unuparts:unuparts_part_unu_hubcap_standard_dish",
				"hubcap_deluxe"="unuparts:unuparts_part_unu_hubcap_standard_deluxe",
				"hubcap_turbine"="unuparts:unuparts_part_unu_hubcap_standard_turbine"
			}

My guess is that ! is not recognized in conditionalDefaultParts.

@DonBruce64
Copy link
Owner

My guess is that ! is not recognized in conditionalDefaultParts.

Yes, and that's yet another thing that should be fixed with CVs...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Code broke, fix yes? needscvs
Projects
None yet
Development

No branches or pull requests

2 participants