Planck – User talk

From Bohemia Interactive Community
Jump to navigation Jump to search
No edit summary
m (Text replacement - "Position2D" to "Position2D")
 
(41 intermediate revisions by 12 users not shown)
Line 1: Line 1:
Already changed
== Position Types ==


Main scripting page now refers to 1.96
We don't really need to specify that a position type is an array, since that is already in the type's definition page (e.g. [[Position#Introduction|Position2D]]). There may be a few older pages left where we still have these overlapping definitions, but that's really obsolete, and we should rather trim them down to the exact position type definition. --[[User:Kronzky|Kronzky]] 21:01, 24 September 2008 (CEST)


[[:Category:Scripting Commands OFP 1.96|Scripting Commands for OFP Version 1.96]]
: Hi Planck, what you said on Kronzky's page makes no sense in some situations, as it is important what kind of array the command requires or returns, for example whether it is PositionAGL or ASL. --[[User:Raedor|raedor]] 14:43, 25 September 2008 (CEST)


:: I'm not quite sure why it's so "utterly ridiculous" to use ''NAMES'' for some common type of arrays.
::Yes, they're not unique data types, but when I use [[Position#PositionAGL|PositionAGL]] or [[Color]] everybody knows right away what kind of array to expect (number of elements, range of values), as well as their meaning. It makes easier reading for anybody familiar with scripting, and those see those the first time have to look it up anyway.
::I've never heard of anybody being confused by [[Color]] not actually being it's own data type, but rather only a specific array ''usage'', so I'm not quite sure what's so wrong about using names for common types of arrays. We use names in daily life all the time - you don't say "dog [animal]", but just "dog", assuming that the other person knows what you're talking about. Why ''shouldn't'' we use some common conventions on the Wiki? --[[User:Kronzky|Kronzky]] 19:34, 25 September 2008 (CEST)


::: Sorry to butt-in... Planck's assertions regarding array and array format's etc. is perfect in every sense.
:::Color, Position2D etc. are all array datatypes... it's just that BIS dev's have attributed certain common language constructs to denote a prerequistie format for some array's that are parsed to and from certain functions/methods. And, there's nothing wrong with that either... although I concur with Planck that this should be denoted in this biki.


I don't know why, but the 1.97 category is still linked [[Special:Categories|here]].
:::For example, take the 'getPos' function...
:::First and foremost the return type of this function is an Array datatype.
:::Secondly, the array returned is in a specific format.
:::Everywhere in this biki where an array is used in or out of a function and that array should be in a specific format this common language construct format should be noted.
:::Position2D IS an array, AND it has a format of [x,y].
:::For, clarity's sake I'd prefer to see Array as the return datatype with (of the format blah, blah) in brackets where applicable.
:::Kronzky, it's not that it's wrong to use a 'common format' name to denote an arrays layout but it is wrong to indicate that it is a datatype... no matter what someone may tell you to the contrary.
:::It's really not a big deal, I don't see a problem with saying 'the return type is an array of the format x' or similarly 'the parameter required is an array of the format x' - with this definition there is no ambiguity.


--[[User:Raedor|Raedor]] 20:45, 1 June 2006 (CEST)
:::Within the last year I haven't been doing that much scripting myself and when I see what appears to be a datatype of 'Position2D' I have had cause to actually think to myself wtf is a Position2D.. oh that's right it's an array that looks like [x,y]. So, why not just say that the parameter is 'an array of the format [x,y]' and if you want to attribute some common name to it such as 'Position2D' then tag it on the end.


Ah, maybe it's because there are still pages linking on that category... we'll see when we changed all scripting command pages.
:::To use your analogy regarding a dog... language is contextual & audience specific... If you have knowledge of breeds of dogs and I know this fact then I can quite happily say to you 'Planck has a Labrador.' and you'd probably know exactly what I was talking about. However, if you have no knowledge of breeds of dogs and I said the above, probably your thoughts would go along the lines of 'Planck has a what?', 'Planck has a dog.', 'Oh, really? What sort of dog.', 'A Labrador.', 'Ah, So Planck has a Labrador dog' - Planck has a <format> <datatype> - Planck has a <Position2D> <Array>.


--[[User:Raedor|Raedor]] 20:47, 1 June 2006 (CEST)
:::Sorry about the excessive text... but this is meat-and-veg logic isn't it? -- [[User:Sy|Sy]] 06:42, 26 September 2008 (CEST)
 
::::Okay, I see, good point. --[[User:Raedor|raedor]] 12:04, 26 September 2008 (CEST)
 
hey Planck, thanks for you hard work also on the BIKI! --[[User:WGL.Q|PROPER Q]] 11:29, 22 January 2009 (CET)
 
== Vehicle Base Types ==
Hi - There's a good chance that I'm totally off-base on this, but in RecentChanges I saw you'd worked on [[ArmA_2:_CfgVehicles]] and while skimming over that page I spotted something that seemed, to me, to be inconsistent. (I do tech_docs ... fast reviews are part of the skill set, but they often produce something like "false positives".)
 
Here's my point, under '''Land Class Vehicles''' we have AllVehicles o Land + LandVehicle; under which there is such as Car and Truck. Under those we find, typically, such as '''Kamaz_Base''' and '''UAZ_Base''', under which there are more specific case.<br />But I noticed that ''Ural_Base'' appears as a sub-class of '''''Ural_Base_withTurret'''''.
 
That may be perfectly correct. But I see that it differs from the others. And since I no way have the expertise to "correct it", I'm doing what I can by reporting it to someone who knows!  (Not easy being a n00b WikiGnome.) So apologies if this is random noise.<br /> --[[User:BenTrem|BenTrem]] 04:14, 4 January 2010 (CET)
 
This is correct, because the definition of Ural_Base is:
class Ural_Base: Ural_Base_withTurret
{
  class Turrets{};
};
--[[User:T D|T_D]] 14:40, 4 January 2010 (CET)
 
::Aye, well I can only put in what I find in the game configs and that is the way it is, as pointed to by T_D, Basically his example means that Ural_Base inherits everything from Ural_Base_withTurret ... except for the turret (class Turrets{};)
::[[User:Planck|Planck]] 16:12, 4 January 2010 (CET)
:::Righto ... that's all good, then. --[[User:BenTrem|BenTrem]]

Latest revision as of 17:55, 5 January 2022

Position Types

We don't really need to specify that a position type is an array, since that is already in the type's definition page (e.g. Position2D). There may be a few older pages left where we still have these overlapping definitions, but that's really obsolete, and we should rather trim them down to the exact position type definition. --Kronzky 21:01, 24 September 2008 (CEST)

Hi Planck, what you said on Kronzky's page makes no sense in some situations, as it is important what kind of array the command requires or returns, for example whether it is PositionAGL or ASL. --raedor 14:43, 25 September 2008 (CEST)
I'm not quite sure why it's so "utterly ridiculous" to use NAMES for some common type of arrays.
Yes, they're not unique data types, but when I use PositionAGL or Color everybody knows right away what kind of array to expect (number of elements, range of values), as well as their meaning. It makes easier reading for anybody familiar with scripting, and those see those the first time have to look it up anyway.
I've never heard of anybody being confused by Color not actually being it's own data type, but rather only a specific array usage, so I'm not quite sure what's so wrong about using names for common types of arrays. We use names in daily life all the time - you don't say "dog [animal]", but just "dog", assuming that the other person knows what you're talking about. Why shouldn't we use some common conventions on the Wiki? --Kronzky 19:34, 25 September 2008 (CEST)
Sorry to butt-in... Planck's assertions regarding array and array format's etc. is perfect in every sense.
Color, Position2D etc. are all array datatypes... it's just that BIS dev's have attributed certain common language constructs to denote a prerequistie format for some array's that are parsed to and from certain functions/methods. And, there's nothing wrong with that either... although I concur with Planck that this should be denoted in this biki.
For example, take the 'getPos' function...
First and foremost the return type of this function is an Array datatype.
Secondly, the array returned is in a specific format.
Everywhere in this biki where an array is used in or out of a function and that array should be in a specific format this common language construct format should be noted.
Position2D IS an array, AND it has a format of [x,y].
For, clarity's sake I'd prefer to see Array as the return datatype with (of the format blah, blah) in brackets where applicable.
Kronzky, it's not that it's wrong to use a 'common format' name to denote an arrays layout but it is wrong to indicate that it is a datatype... no matter what someone may tell you to the contrary.
It's really not a big deal, I don't see a problem with saying 'the return type is an array of the format x' or similarly 'the parameter required is an array of the format x' - with this definition there is no ambiguity.
Within the last year I haven't been doing that much scripting myself and when I see what appears to be a datatype of 'Position2D' I have had cause to actually think to myself wtf is a Position2D.. oh that's right it's an array that looks like [x,y]. So, why not just say that the parameter is 'an array of the format [x,y]' and if you want to attribute some common name to it such as 'Position2D' then tag it on the end.
To use your analogy regarding a dog... language is contextual & audience specific... If you have knowledge of breeds of dogs and I know this fact then I can quite happily say to you 'Planck has a Labrador.' and you'd probably know exactly what I was talking about. However, if you have no knowledge of breeds of dogs and I said the above, probably your thoughts would go along the lines of 'Planck has a what?', 'Planck has a dog.', 'Oh, really? What sort of dog.', 'A Labrador.', 'Ah, So Planck has a Labrador dog' - Planck has a <format> <datatype> - Planck has a <Position2D> <Array>.
Sorry about the excessive text... but this is meat-and-veg logic isn't it? -- Sy 06:42, 26 September 2008 (CEST)
Okay, I see, good point. --raedor 12:04, 26 September 2008 (CEST)

hey Planck, thanks for you hard work also on the BIKI! --PROPER Q 11:29, 22 January 2009 (CET)

Vehicle Base Types

Hi - There's a good chance that I'm totally off-base on this, but in RecentChanges I saw you'd worked on ArmA_2:_CfgVehicles and while skimming over that page I spotted something that seemed, to me, to be inconsistent. (I do tech_docs ... fast reviews are part of the skill set, but they often produce something like "false positives".)

Here's my point, under Land Class Vehicles we have AllVehicles o Land + LandVehicle; under which there is such as Car and Truck. Under those we find, typically, such as Kamaz_Base and UAZ_Base, under which there are more specific case.
But I noticed that Ural_Base appears as a sub-class of Ural_Base_withTurret.

That may be perfectly correct. But I see that it differs from the others. And since I no way have the expertise to "correct it", I'm doing what I can by reporting it to someone who knows! (Not easy being a n00b WikiGnome.) So apologies if this is random noise.
--BenTrem 04:14, 4 January 2010 (CET)

This is correct, because the definition of Ural_Base is:

class Ural_Base: Ural_Base_withTurret
{
 class Turrets{};
};

--T_D 14:40, 4 January 2010 (CET)

Aye, well I can only put in what I find in the game configs and that is the way it is, as pointed to by T_D, Basically his example means that Ural_Base inherits everything from Ural_Base_withTurret ... except for the turret (class Turrets{};)
Planck 16:12, 4 January 2010 (CET)
Righto ... that's all good, then. --BenTrem