Talk:Types/BoundingBox: Difference between revisions

From Official Factorio Wiki
Jump to navigation Jump to search
(Initial question on edit in revision history)
 
 
Line 7: Line 7:


:What is "The expanded form does not exist in the data stage" {{Special:Permanentlink/189365}} supposed to mean? It doesn't work in an upcoming version? [[User:Honktown|Honktown]] ([[User talk:Honktown|talk]]) 23:18, 27 June 2022 (UTC)
:What is "The expanded form does not exist in the data stage" {{Special:Permanentlink/189365}} supposed to mean? It doesn't work in an upcoming version? [[User:Honktown|Honktown]] ([[User talk:Honktown|talk]]) 23:18, 27 June 2022 (UTC)
:: Hey, your example works because the keys are simply ignored. If you have the right_bottom line first, that value will be assumed to mean left top and you will encounter the following error "Collision box has to contain the [0,0] point." because the corners are reversed from the point of view of the game. Another way to test this is to add an entry before the two expected entries:
    data.raw.furnace["stone-furnace"].collision_box = {
      foo = {-4, -4},
      left_top = {-3, -3},
      right_bottom = {3, 3}
  }
:: As the page states, the first member is assumed to be left top, second is assumed right bottom and third is assumed float orientation. So, this will error with "Error while loading entity prototype "stone-furnace" (furnace): Value must be a number in property tree at ROOT.furnace.stone-furnace.collision_box.right_bottom". This confirms that the key names are ignored. Internally during the data stage nothing reads the keys. Only the position of the values in the table is respected.
:: If the keys worked like other keyed types or prototypes, the definition order should not matter and the error in the second example should be impossible. So, documenting the full format would be misleading.
:: Another example of keys being ignored is [[Prototype/Lab#inputs]], I think you might be familiar with that. I hope that clears things up. -- [[User:Bilka|Bilka]] ([[User talk:Bilka|talk]]) - <span style="color:#FF0000">Admin</span> 10:31, 18 July 2022 (UTC)

Latest revision as of 10:31, 18 July 2022

"full description" IS valid

In version 1.1.61, this works:
   data.raw.furnace["stone-furnace"].collision_box = {
       left_top = {-3, -3},
       right_bottom = {3, 3}
   }
What is "The expanded form does not exist in the data stage" Special:Permanentlink/189365 supposed to mean? It doesn't work in an upcoming version? Honktown (talk) 23:18, 27 June 2022 (UTC)
Hey, your example works because the keys are simply ignored. If you have the right_bottom line first, that value will be assumed to mean left top and you will encounter the following error "Collision box has to contain the [0,0] point." because the corners are reversed from the point of view of the game. Another way to test this is to add an entry before the two expected entries:
   data.raw.furnace["stone-furnace"].collision_box = {
      foo = {-4, -4},
      left_top = {-3, -3},
      right_bottom = {3, 3}
  }
As the page states, the first member is assumed to be left top, second is assumed right bottom and third is assumed float orientation. So, this will error with "Error while loading entity prototype "stone-furnace" (furnace): Value must be a number in property tree at ROOT.furnace.stone-furnace.collision_box.right_bottom". This confirms that the key names are ignored. Internally during the data stage nothing reads the keys. Only the position of the values in the table is respected.
If the keys worked like other keyed types or prototypes, the definition order should not matter and the error in the second example should be impossible. So, documenting the full format would be misleading.
Another example of keys being ignored is Prototype/Lab#inputs, I think you might be familiar with that. I hope that clears things up. -- Bilka (talk) - Admin 10:31, 18 July 2022 (UTC)