Zodiacs gone, new fields appear in mission

#1 Looks like you've discovered a bug with one of the newest features in the AFX for TGEA 1.7.1 Beta, which is good. We'll be moving forward on the final release over the next couple of weeks and it will be nice to have this one fixed.

First, here's what's going on... The latest revision of AFX adds a number of features to help manage how Zodiacs appear on Interiors and polysoup-enabled TSStatic objects. One feature is the use of a gradient range to filter Zodiac rendering based on the normal of Interior and polysoup polygons.

Much of this in done with settings associated with the Zodiac structures, but we also added a few fields to InteriorInstance and TSStatic, which are the ones you noted:

ignoreZodiacs -- This is a boolean field. Setting it to true will prevent any Zodiac rendering from happening on this Interior.

gradientRange -- This specifies the range of gradient angles (0-180 degrees) which a polygon normal must fall in before a Zodiac is rendered on it.

invertGradientRange -- This is a boolean field. Setting it to true will invert the interpretation of the specified gradientRange and Zodiacs outside rather than inside the range will be rendered.

Zodiacs also have the gradientRange and invertGradientRange fields but if the Zodiac's preferDestinationGradients field is true, and an interior has gradient settings, the interior's gradient settings will override the Zodiac's.

Torque doesn't have a mechanism for preventing fields from being written out, it always writes out all of them, even if the field values are set to their defaults. This is normally not a big problem, but in this case there is a problem with the default settings for gradientRange.

The code is actually trying to be clever and detect if gradientRange has been set to anything, so internally the gradientRange defaults to an out-of-bounds value. But apparently, the process of saving a mission causes the unintended side-effect of assigning an interior's gradientRange to the legal but useless value of "0.985 0.985" and that's the value that gets saved. Also, preferDestinationGradients is defaulting to true, so the end result is that many interior Zodiacs are filtered against the bad gradient and essentially culled.

I think the official fix for this will be to add a useGradientRange field to InteriorInstance and TSStatic that must explicitly be set to true for the other gradient settings to be considered.

Meanwhile, a quicker workaround will be to set preferDestinationGradients to false on all Zodiacs or just change its default to false in the C++ code, as indicated here at line 91 of source/afx/ce/afxZodiac.cpp:

afxZodiacData::afxZodiacData()
{
  txr_name = ST_NULLSTRING;
  radius_xy = 1;
  vert_range.set(0.0f, 0.0f);
  start_ang = 0;
  ang_per_sec = 0;
  color.set(1,1,1,1);
  grow_in_time = 0.0f; 
  shrink_out_time = 0.0f;
  growth_rate = 0.0f;
  blend_flags = BLEND_NORMAL;
  terrain_ok = true;
  interiors_ok = true;
  reflected_ok = false;
  non_reflected_ok = true;
  respect_ori_cons = false;
  scale_vert_range = true;

  interior_h_only = false;
  interior_v_ignore = false;
  interior_back_ignore = false;
  interior_opaque_ignore = false;
  interior_transp_ignore = true;

  altitude_max = 0.0f;
  altitude_falloff = 0.0f;
  altitude_shrinks = false;
  altitude_fades = false;

  distance_max = 120.0f;
  distance_falloff = 45.0f;

  use_grade_range = false;
  [b][i]prefer_dest_grade = false;  // <<< CODE CHANGED  HERE[/i][/b] 
  grade_range.set(0.7f, 1.0f);
  inv_grade_range = false;
}

#2 Many thanks, Jeff! I'm loving AFX, it's cut months off my development time!