Planck – User talk

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


Do you still have the Elite scripting command list?
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)
I have and can paste it where. how would u like to handle it?
<hr>
This is the list I have for Elite:


actionKeys
: 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)


actionKeysImages
:: 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)


actionKeysNames
::: 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.


activateAddons
:::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.


activateKey
:::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.


addLiveStats
:::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>.


addWaypoint
:::Sorry about the excessive text... but this is meat-and-veg logic isn't it? -- [[User:Sy|Sy]] 06:42, 26 September 2008 (CEST)


assignTeam
::::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)


camSetFocus
== 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".)


camUseNVG
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'''''.


clearRadio
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)


commandGetOut
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)


composeText
::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)
createCenter
:::Righto ... that's all good, then. --[[User:BenTrem|BenTrem]]
 
createGroup
 
createGuardedPoint
 
createMarker
 
createMine
 
createSoundSource
 
createTrigger
 
createVehicleLocal
 
 
deleteCenter
 
deleteGroup
 
deleteMarker
 
deleteWaypoint
 
dissolveTeam
 
doGetOut
 
 
enableAI
 
 
fadeRadio
 
finishMissionInit
 
formatText
 
 
getPosASL
 
glanceAt
 
 
intersect
 
isKeyActive
 
isKindOf
 
isMarkedForCollection
 
 
keyImage
 
keyName
 
 
lightAttachObject
 
lightDetachObject
 
lineBreak
 
lookAt
 
 
moveTo
 
moveToCompleted
 
 
onPlayerConnected
 
onPlayerDisconnected
 
 
parseText
 
playMission
 
playerSide
 
preloadCamera
 
preloadObject
 
preloadSound
 
preloadTitleObj
 
preloadTitleRsc
 
preprocessFileLineNumbers
 
processInitCommands
 
 
radioVolume
 
respawnVehicle
 
runInitScript
 
 
scriptDone
 
selectLeader
 
selectPlayer
 
sendSimpleCommand
 
setAttributes
 
setCameraEffect
 
setCameraInterest
 
setDate
 
setDropInterval
 
setEffectCondition
 
setFriend
 
setLightBrightness
 
setLightAmbient
 
setLightColor
 
setMarkerBrush
 
setMarkerDir
 
setMarkerShape
 
setMarkerText
 
setMusicEffect
 
setParticleCircle
 
setParticleParams
 
setParticleRandom
 
setPosASL
 
setSoundEffect
 
setTargetAge
 
setTitleEffect
 
setTriggerActivation
 
setTriggerArea
 
setTriggerStatements
 
setTriggerText
 
setTriggerTimeout
 
setTriggerType
 
setUnitAbility
 
setUnitRank
 
setVectorDir
 
setVectorUp
 
setVehicleAmmo
 
setVehicleArmor
 
setVehicleId
 
setVehicleInit
 
setVehicleLock
 
setVehiclePosition
 
setVehicleVarName
 
setWaypointBehaviour
 
setWaypointCombatMode
 
setWaypointDescription
 
setWaypointFormation
 
setWaypointHousePosition
 
setWaypointPosition
 
setWaypointScript
 
setWaypointSpeed
 
setWaypointStatements
 
setWaypointTimeout
 
setWaypointType
 
showWaypoint
 
spawn
 
surfaceIsWater
 
surfaceType
 
synchronizeWaypoint
 
 
terminate
 
triggerAttachObject
 
triggerAttachVehicle
 
 
unassignTeam
 
 
vectorDir
 
vectorUp
 
 
waypointAttachObject
 
waypointAttachVehicle
 
weaponDirection
 
 
[[User:Planck|Planck]] 16:47, 27 April 2006 (CEST)

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