Difference between revisions of "MSCO07"

From SWGANH Wiki
Jump to: navigation, search
(→‎BaseLine Struct)
 
Line 566: Line 566:
 
|}
 
|}
 
|}
 
|}
 +
 +
===Xenos' Notes===
 +
----
 +
 +
<pre>
 +
ObjOpperandCount = 21
 +
 +
SlotName:
 +
The name of the ingredient slot in the schematic. This does not appear to be displayed
 +
as that is done by the DraftSlots(0x1BF) ObjectController. However it may be used
 +
to tie the slots together.
 +
 +
SlotContents:
 +
This is a bitmask used to flag the contents of the slot once it contains something.
 +
4 = resource
 +
2 = component_item
 +
1 = ??
 +
0 = nothing
 +
 +
IngridientList:
 +
each element of this array contains an array of objectIDs for the ingredients.
 +
Resources use the GlobalID of the resource in the slot (NOT THE CONTAINER)
 +
Items use the objectID of the item object in the slot. For multiple components
 +
per slot, each objectID is mentioned. The first objectID is the model that will
 +
be displayed inside the slot.
 +
 +
QuantityList:
 +
each element of this array contains an array of integers describing the quantity
 +
of the elements in the IngredientList arrays (theres a 1 to 1 correlation).
 +
Resources will simply have the quantity of the resource.
 +
Items, because each objectID has to be used, contain a list of 1's.
 +
IE. 3 objects in the slot.
 +
IngedientList = [object1][object2][object3]
 +
Quantitylist = [1][1][1], meaning 1 of each item.
 +
The client will SUM this up and use it as the total.
 +
 +
SlotQuality:
 +
This float does not do ANYTHING to the slot. I am ASSUMING the following:
 +
before resource quality was automatically computed by the client, the server
 +
would use this to show how much of the quality bar to fill AFTER an ingredient was
 +
added. However people complained and SOE had this bar now show when highlighting
 +
a resource to use. Because of the automation this variable was removed from use,
 +
but not from packets. (lazy bastards).
 +
 +
CleanSlot:
 +
This integer seems to only be able to break the display when not set to 0.
 +
On Baseline, the list is set to -1 for each element. Once something has been
 +
added, the server sets it to 0. On remove, it remains 0. and readding keeps it at 0.
 +
Using anything else while it is occupied causes it to incorrectly display everything.
 +
It may be used as an offset for the SlotIndex because sometimes I was able to get it
 +
to change the quantity of slot2 using an update to slot1 and this with a value of 1.
 +
However it still just screws things up. Initialize and leave to 0 and just dont use it.
 +
(Note: Its safe to set it back to -1 on removeslot, but on addslot it MUST BE 0).
 +
 +
SlotIndex:
 +
On Baseline this array is set to have each element describe its index in the array,
 +
possibly using it as the overall slot index reference that all the following packets
 +
use to describe which slot they are affecting. Start from 0 and count up by 1 for each
 +
slot.
 +
IE. 3 slots
 +
SlotIndexList = [0][1][2]
 +
 +
IngredientsCounter:
 +
This is like an update counter for any change to the slot. Each time a slot is modified
 +
this increments by 4 per slot. Since initialization is considered a modification, it
 +
should on baseline be set as 4*slots.
 +
IE. 3 slots = 0x0C, or 12.
 +
 +
ExperimentationName:
 +
The name of the experimentation pools this schematic has. Each pool name is displayed
 +
in order as experimentable during the experimentation phase.
 +
 +
CurrentExperimentationValue:
 +
This is considered as the "QUALITY" the item has for each area of experimentation.
 +
This value is a percentage (decimal from 0->1) and is displayed as the initial
 +
assembly quality as well as the current quality each step of experimentation.
 +
 +
ExperimentationOffset:
 +
each element in this array offsets the ExperimentationValue with the formula:
 +
DisplayValue = ExperimentationValue - Offset
 +
So far all schematics just set this to 0 because there really is no point in
 +
penalizing the player. This may be used for experimentation failures, however
 +
the server can just modify the current value and reduce it. I can't think
 +
of any optimization this could give a server either, so set to 0 and leave alone.
 +
 +
BlueBarSize:
 +
the elements of this array are initialized to 1 in the baseline. Ive yet to
 +
capture a packet that causes this to change otherwise. From experimenting
 +
I found this is a percentage (decimal 0->1) that affects the size of the
 +
blue bar pointed to by the arrow for each experimentation pool. It may
 +
potentially be modified by failures, however I never even noticed this
 +
blue par from all my time of play. So I deem it useless. set to 1 and move on.
 +
 +
MaxExperimentation:
 +
This is the maximum possible experimentation for each pool. It is solely based
 +
on the resource quality calculated with the average resource weight of each pool.
 +
For example, ARW = 740 makes this .74 or 74% maximum. Experimentation can not
 +
exceed this quality. This is also a percentage (decimal from 0->1).
 +
 +
CustomizationName:
 +
This is the name of the customization variables for the given schematic.
 +
So far only things I've seen are:
 +
"private/index_color_1"
 +
"private/index_color_2"
 +
for items that can have 2 different pallete colors modified. These can
 +
be found inside the .IFF files so look there when building schematicDB.
 +
 +
PalleteSelection:
 +
This is the default and selected value for pallete customization. The
 +
server initializes it to the default colors, and then changes it after
 +
the client sends a CraftCustomization packet. It then can use this
 +
value to build the CustomizationString for MSCO6.
 +
 +
PalleteStartIndex:
 +
Much like how slots and experimentation had a variable that SEEMED to
 +
screw around with the index/starting place of each display.. customization
 +
has this. This variable selects which pallete color to START from when
 +
displaying the available options. The number of options is given by:
 +
Options = PalleteEndIndex - PalleteStartIndex
 +
The server only seems to ever set this to 0. It was also noticed that
 +
regardless of the color displayed on the left. When sampling options
 +
the item model DOES NOT factor in this variable. So if you set this to 1
 +
and the colors are white gray black red and you choose red. It will
 +
DISPLAY black with the item (red is 3, 3-1 is 2, 2 is black).
 +
In conclusion: set to 0 and use PalleteEndIndex.
 +
 +
PalleteEndIndex:
 +
the element in this array determines how many pallete options will be
 +
available for customization. Starting from index PalleteStartIndex (should be 0),
 +
PalleteEndIndex number of options will be available. The most pallete options
 +
so far seen are palletes with 255 options. So for that pallete you would set this
 +
to 255 to have all of them, or a smaller number to only display the first of those
 +
options. (It also explains why the latter pallete colors are more exotic than
 +
the first ones ! ).
 +
 +
CustomizationCounter:
 +
Just like the IngedientsCounter, this is an update counter for the Customization.
 +
However, since customization only applies once, it is initialized to the number
 +
of customization palletes, and incremented by the number of customization palletes,
 +
and this happens only once.
 +
 +
RiskFactor:
 +
This value is used to compute the risk assessed with experimentation. It is based
 +
on the Average Mallability of the Resources used along with your Experimentation Skill
 +
and how many Experimentation Points you use, as well as how many Additional Pools
 +
you are modifying.
 +
The formulas are as follows:
 +
RiskFactor = (AverageMallability - 500)/40 + ExperimentationSkill
 +
Risk = (50 - RiskFactor + 5*PointsUsed)/ 100
 +
If negative, set to 0. Then Add for additional pools.
 +
Risk += (5*AdditionalPools)/100
 +
 +
Note: PointsUsed is the maximum of the number of points put into ANY ONE POOL during
 +
that experimentation roll. So if you add 5 points to pool1 and 3 points into pool2,
 +
you only use 5 for the PointsUsed value and 1 for the AdditionalPools value.
 +
It has also been observed regardless of how much experimentation skill you have
 +
the 5% is added per additional pool used and it is always added.
 +
Lesson: Just modify 1 pool at a time and go for multiple experimentation rolls. lol
 +
 +
ObjectTemplateCustomization:
 +
Some customization allows for the changing of the model itself.
 +
Examples: Fountain, Gungan Head, Streetlamps, oh.. and Lightsabers!
 +
To add this option, put a list of the objectTemplateIFF path into this array.
 +
This includes the directory and extension ie. "object/wearables/whatever.iff"
 +
This then becomes a drop down list in customization and this option gets set
 +
in the MSCO6 afterwards, and then applied to the prototype as the new ObjectCRC.
 +
 +
ReadyFlag:
 +
Set to 1 if the schematic is ready
 +
Set to 0 if the schematic isn't.
 +
Just set to 1 on initialization and leave it be!
 +
</pre>
  
 
===Sample Packet===
 
===Sample Packet===

Latest revision as of 20:32, 15 June 2008

Baseline - MSCO 07

SWGANH Wiki is a repository of Star Wars Galaxies Developer information. This site is only meant to be used by SWGANH Developer team.

MSCO Packet Type QuickNav
MSCO03 - MSCO06 - MSCO07 - MSCO08 - MSCO09


BaseLine Struct

Few bytes left to figure out on this one. 

SHORT:		ObjOpperandCount
INT:		SlotNameList
INT:		UpdateCounter
{
  ASTRING:	SlotNameTable
  INT:		NotUsed
  ASTRING:	SlotName
}
INT:		SlotContentsList
INT:		UpdateCounter
{
    INT:	SlotContentType
}
INT:		IngridientList
INT:		UpdateCounter
{
    INT:	Counter
    {
      LONG:	IngredientID
    }
}
INT:		QuantityList
INT:		UpdateCounter
{
    INT:	Counter
    {
      INT:	IngredientQuantity
    }
}
INT:		SlotQualityList
INT:		UpdateCounter
{
    FLOAT:	Quality  
}
INT:		CleanSlotList 
INT:		UpdateCounter
{
    INT:	Value 
}
INT:		SlotIndexList
INT:		UpdateCounter
{
    INT:	SlotIndex
}
BYTE:		IngredientsCounter
INT:		ExperimentationNameList
INT:		UpdateCounter
{
  ASTRING:	ExperimentationTable
  INT:		NotUsed
  ASTRING:	ExperimentationName
}
INT:		CurrentExperimentationValueList 
INT:		UpdateCounter
{
    FLOAT:	CurrentExperimentationValue
}
INT:		ExperimentationOffsetList
INT:		UpdateCounter 
{
    FLOAT:	ExperimentationValueOffset
}
INT:		BlueBarSizeList
INT:		UpdateCounter
{
    FLOAT:	Size
}
INT:		MaxExperimentationList
INT:		UpdateCounter
{
    FLOAT:	MaxExperimentationValue
}
INT:		CustomizationNameList
INT:		UpdateCounter
{
  ASTRING:	CustomizationName
}
INT:		PalleteSelectionList
INT:		UpdateCounter
{
    INT:	PalleteSelection
}
INT:		PalleteStartIndexList
INT:		UpdateCounter
{
    INT:	PalleteStartIndex
}
INT:		PalleteEndIndexList
INT:		UpdateCounter
{
    INT:	PalleteEndIndex 
}
BYTE:		CustomizationCounter
FLOAT:		RiskFactor
INT:		ObjectTemplateCustomizationList
INT:		UpdateCounter
{
  ASTRING:	ObjectTemplateIFF
}
BYTE:		ReadyFlag

Deltas Struct

I've written the deltas part numbers in the baseline above. This Packet is to huge that one could make sense of it without structure. Thus the Delta parts themselves are further divided into - lets call them - slotspots.

For every slot there is a 3 Byte slotspot in the Deltapart, save part 7, where the byte stale flag (??) is. So that every slotspot can be modified on its own and the monster gets more palateable the slotspots must be inserted. Think of it as a kind of FlowControl.

So to set the amount of resource that got filled into the first slot : 

SHORT:			UpdateCount
SHORT:			UpdateType
{
  00:
    INT:		SlotNameList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          ASTRING:	SlotNameTable
          INT:		NotUsed
          ASTRING:	SlotName 
        02:(change)
          SHORT:	Index
          ASTRING:	SlotNameTable
          INT:		NotUsed
          ASTRING:	SlotName 
        03:(resetall)
          SHORT:	NewListSize
          {
            ASTRING:	SlotNameTable
            INT:	NotUsed
            ASTRING:	SlotName 
          }
        04:(clear)
      }
    }
  01:
    INT:		SlotContentsList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          INT:		SlotContentType
        02:(change)
          SHORT:	Index
          INT:		SlotContentType
        03:(resetall)
          SHORT:	NewListSize
          {
            INT:	SlotContentType
          }
        04:(clear)
      }
    }
  02:
    INT:		IngridientList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:
        01:(add)
          SHORT:	Index
          INT:		Counter
          {
            LONG:	IngredientID
          }
        02:(change)
          SHORT:	Index
          INT:		Counter
          {
            LONG:	IngredientID
          }
        03:(resetall)
          SHORT:	NewListSize
          {
            INT:	Counter
            {
              LONG:	IngredientID
            }
          }
        04:(clear)
      }
    }
  03:
    INT:		QuantityList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          INT:		Counter
          {
            INT:	IngredientQuantity
          }
        02:(change)
          SHORT:	Index
          INT:		Counter
          {
            INT:	IngredientQuantity
          }
        03:(resetall)
          SHORT:	NewListSize
          {
            INT:	Counter
            {
              INT:	IngredientQuantity
            }
          }
        04:(clear)
      }
    }
  04:
    INT:		SlotQualityList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          FLOAT:	Quality  
        02:(change)
          SHORT:	Index
          FLOAT:	Quality  
        03:(resetall)
          SHORT:	NewListSize
          {
            FLOAT:	Quality  
          }
        04:(clear)
      }
    }
  05:
    INT:		CleanSlotList 
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          INT:		Value 
        02:(change)
          SHORT:	Index
          INT:		Value 
        03:(resetall)
          SHORT:	NewListSize
          {
            INT:	Value  
          }
        04:(clear)
      }
    }
  06:
    INT:		SlotIndexList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          INT:		SlotIndex
        02:(change)
          SHORT:	Index
          INT:		SlotIndex
        03:(resetall)
          SHORT:	NewListSize
          {
            INT:	SlotIndex
          }
        04:(clear)
      }
    }
  07:
    BYTE:		IngredientsCounter
  08:
    INT:		ExperimentationNameList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          ASTRING:	ExperimentationTable
          INT:		NotUsed
          ASTRING:	ExperimentationName
        02:(change)
          SHORT:	Index
          ASTRING:	ExperimentationTable
          INT:		NotUsed
          ASTRING:	ExperimentationName
        03:(resetall)
          SHORT:	NewListSize
          {
            ASTRING:	ExperimentationTable
            INT:	NotUsed
            ASTRING:	ExperimentationName
          }
        04:(clear)
      }
    }
  09:
    INT:		CurrentExperimentationValueList 
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          FLOAT:	CurrentExperimentationValue
        02:(change)
          SHORT:	Index
          FLOAT:	CurrentExperimentationValue
        03:(resetall)
          SHORT:	NewListSize
          {
            FLOAT:	CurrentExperimentationValue
          }
        04:(clear)
      }
    }
  0A:
    INT:		ExperimentationOffsetList
    INT:		UpdateCounter 
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          FLOAT:	ExperimentationValueOffset
        02:(change)
          SHORT:	Index
          FLOAT:	ExperimentationValueOffset
        03:(resetall)
          SHORT:	NewListSize
          {
            FLOAT:	ExperimentationValueOffset
          }
        04:(clear)
      }
    }
  0B:
    INT:		BlueBarSizeList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          FLOAT:	Size
        02:(change)
          SHORT:	Index
          FLOAT:	Size
        03:(resetall)
          SHORT:	NewListSize
          {
            FLOAT:	Size
          }
        04:(clear)
      }
    }
  0C:
    INT:		MaxExperimentationList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          FLOAT:	MaxExperimentationValue
        02:(change)
          SHORT:	Index
          FLOAT:	MaxExperimentationValue
        03:(resetall)
          SHORT:	NewListSize
          {
            FLOAT:	MaxExperimentationValue
          }
        04:(clear)
      }
    }
  0D:
    INT:		CustomizationNameList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          ASTRING:	CustomizationName
        02:(change)
          SHORT:	Index
          ASTRING:	CustomizationName
        03:(resetall)
          SHORT:	NewListSize
          {
            ASTRING:	CustomizationName 
          }
        04:(clear)
      }
    }
  0E:
    INT:		PalleteSelectionList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          INT:		PalleteSelection
        02:(change)
          SHORT:	Index
          INT:		PalleteSelection
        03:(resetall)
          SHORT:	NewListSize
          {
            INT:	PalleteSelection
          }
        04:(clear)
      }
    }
  0F:
    INT:		PalleteStartIndexList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          INT:    	PalleteStartIndex
        02:(change)
          SHORT:	Index
          INT:		PalleteStartIndex 
        03:(resetall)
          SHORT:	NewListSize
          {
            INT:	PalleteStartIndex
          }
        04:(clear)
      }
    }
  10:
    INT:		PalleteEndIndexList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          INT:		PalleteEndIndex
        02:(change)
          SHORT:	Index
          INT:		PalleteEndIndex
        03:(resetall)
          SHORT:	NewListSize
          {
            INT:	PalleteEndIndex
          }
        04:(clear)
      }
    }
  11:
    BYTE:		CustomizationCounter
  12:
    FLOAT:		RiskFactor
  13:
    INT:		ObjectTemplateCustomizationList
    INT:		UpdateCounter
    {
      BYTE:		SubType
      {
        00:(remove)
          SHORT:	Index
        01:(add)
          SHORT:	Index
          ASTRING:	ObjectTemplateIFF 
        02:(change)
          SHORT:	Index
          ASTRING:	ObjectTemplateIFF
        03:(resetall)
          SHORT:	NewListSize
          {
            ASTRING:	ObjectTemplateIFF
          }
        04:(clear)
      }
    }
  14:
    BYTE:		ReadyFlag
}

Variable Descriptions

Obj_OperandCount =

Tags

75% This packet has been partially reversed.

S→C This packet originates on the server.

Xenos' Notes

ObjOpperandCount = 21

SlotName:
The name of the ingredient slot in the schematic. This does not appear to be displayed
as that is done by the DraftSlots(0x1BF) ObjectController. However it may be used
to tie the slots together.

SlotContents:
This is a bitmask used to flag the contents of the slot once it contains something.
4 = resource
2 = component_item
1 = ??
0 = nothing

IngridientList:
each element of this array contains an array of objectIDs for the ingredients.
Resources use the GlobalID of the resource in the slot (NOT THE CONTAINER)
Items use the objectID of the item object in the slot. For multiple components
per slot, each objectID is mentioned. The first objectID is the model that will
be displayed inside the slot.

QuantityList:
each element of this array contains an array of integers describing the quantity
of the elements in the IngredientList arrays (theres a 1 to 1 correlation).
Resources will simply have the quantity of the resource.
Items, because each objectID has to be used, contain a list of 1's.
IE. 3 objects in the slot.
IngedientList = [object1][object2][object3]
Quantitylist = [1][1][1], meaning 1 of each item.
The client will SUM this up and use it as the total.

SlotQuality:
This float does not do ANYTHING to the slot. I am ASSUMING the following:
before resource quality was automatically computed by the client, the server
would use this to show how much of the quality bar to fill AFTER an ingredient was
added. However people complained and SOE had this bar now show when highlighting
a resource to use. Because of the automation this variable was removed from use,
but not from packets. (lazy bastards).

CleanSlot:
This integer seems to only be able to break the display when not set to 0.
On Baseline, the list is set to -1 for each element. Once something has been
added, the server sets it to 0. On remove, it remains 0. and readding keeps it at 0.
Using anything else while it is occupied causes it to incorrectly display everything.
It may be used as an offset for the SlotIndex because sometimes I was able to get it
to change the quantity of slot2 using an update to slot1 and this with a value of 1.
However it still just screws things up. Initialize and leave to 0 and just dont use it.
(Note: Its safe to set it back to -1 on removeslot, but on addslot it MUST BE 0).

SlotIndex:
On Baseline this array is set to have each element describe its index in the array,
possibly using it as the overall slot index reference that all the following packets
use to describe which slot they are affecting. Start from 0 and count up by 1 for each
slot.
IE. 3 slots
SlotIndexList = [0][1][2]

IngredientsCounter:
This is like an update counter for any change to the slot. Each time a slot is modified
this increments by 4 per slot. Since initialization is considered a modification, it 
should on baseline be set as 4*slots.
IE. 3 slots = 0x0C, or 12.

ExperimentationName:
The name of the experimentation pools this schematic has. Each pool name is displayed
in order as experimentable during the experimentation phase.

CurrentExperimentationValue:
This is considered as the "QUALITY" the item has for each area of experimentation.
This value is a percentage (decimal from 0->1) and is displayed as the initial
assembly quality as well as the current quality each step of experimentation.

ExperimentationOffset:
each element in this array offsets the ExperimentationValue with the formula:
DisplayValue = ExperimentationValue - Offset
So far all schematics just set this to 0 because there really is no point in
penalizing the player. This may be used for experimentation failures, however
the server can just modify the current value and reduce it. I can't think
of any optimization this could give a server either, so set to 0 and leave alone.

BlueBarSize:
the elements of this array are initialized to 1 in the baseline. Ive yet to
capture a packet that causes this to change otherwise. From experimenting
I found this is a percentage (decimal 0->1) that affects the size of the 
blue bar pointed to by the arrow for each experimentation pool. It may
potentially be modified by failures, however I never even noticed this
blue par from all my time of play. So I deem it useless. set to 1 and move on.

MaxExperimentation:
This is the maximum possible experimentation for each pool. It is solely based
on the resource quality calculated with the average resource weight of each pool.
For example, ARW = 740 makes this .74 or 74% maximum. Experimentation can not
exceed this quality. This is also a percentage (decimal from 0->1).

CustomizationName:
This is the name of the customization variables for the given schematic.
So far only things I've seen are:
"private/index_color_1"
"private/index_color_2"
for items that can have 2 different pallete colors modified. These can
be found inside the .IFF files so look there when building schematicDB.

PalleteSelection:
This is the default and selected value for pallete customization. The
server initializes it to the default colors, and then changes it after
the client sends a CraftCustomization packet. It then can use this
value to build the CustomizationString for MSCO6.

PalleteStartIndex:
Much like how slots and experimentation had a variable that SEEMED to
screw around with the index/starting place of each display.. customization
has this. This variable selects which pallete color to START from when
displaying the available options. The number of options is given by:
Options = PalleteEndIndex - PalleteStartIndex
The server only seems to ever set this to 0. It was also noticed that
regardless of the color displayed on the left. When sampling options
the item model DOES NOT factor in this variable. So if you set this to 1
and the colors are white gray black red and you choose red. It will
DISPLAY black with the item (red is 3, 3-1 is 2, 2 is black).
In conclusion: set to 0 and use PalleteEndIndex.

PalleteEndIndex:
the element in this array determines how many pallete options will be
available for customization. Starting from index PalleteStartIndex (should be 0),
PalleteEndIndex number of options will be available. The most pallete options
so far seen are palletes with 255 options. So for that pallete you would set this
to 255 to have all of them, or a smaller number to only display the first of those
options. (It also explains why the latter pallete colors are more exotic than
the first ones ! ).

CustomizationCounter:
Just like the IngedientsCounter, this is an update counter for the Customization.
However, since customization only applies once, it is initialized to the number
of customization palletes, and incremented by the number of customization palletes,
and this happens only once.

RiskFactor:
This value is used to compute the risk assessed with experimentation. It is based
on the Average Mallability of the Resources used along with your Experimentation Skill
and how many Experimentation Points you use, as well as how many Additional Pools 
you are modifying.
The formulas are as follows:
RiskFactor = (AverageMallability - 500)/40 + ExperimentationSkill
Risk = (50 - RiskFactor + 5*PointsUsed)/ 100
If negative, set to 0. Then Add for additional pools.
Risk += (5*AdditionalPools)/100

Note: PointsUsed is the maximum of the number of points put into ANY ONE POOL during
that experimentation roll. So if you add 5 points to pool1 and 3 points into pool2,
you only use 5 for the PointsUsed value and 1 for the AdditionalPools value.
It has also been observed regardless of how much experimentation skill you have
the 5% is added per additional pool used and it is always added.
Lesson: Just modify 1 pool at a time and go for multiple experimentation rolls. lol

ObjectTemplateCustomization:
Some customization allows for the changing of the model itself.
Examples: Fountain, Gungan Head, Streetlamps, oh.. and Lightsabers!
To add this option, put a list of the objectTemplateIFF path into this array.
This includes the directory and extension ie. "object/wearables/whatever.iff"
This then becomes a drop down list in customization and this option gets set
in the MSCO6 afterwards, and then applied to the prototype as the new ObjectCRC.

ReadyFlag:
Set to 1 if the schematic is ready
Set to 0 if the schematic isn't.
Just set to 1 on initialization and leave it be!

Sample Packet










Retrieved from "https://wiki.swganh.org/index.php?title=MSCO07&oldid=38815"