Killzone Kid – User talk

From Bohemia Interactive Community
Revision as of 15:21, 19 October 2014 by Killzone Kid (talk | contribs)
Jump to navigation Jump to search

Not important, but nice to know

Hi. I'm just wondering (and Google didn't help) what "sqf" stands for; do you know? Fred Gandt (talk) 04:03, 23 March 2014 (CET)

[14:44] Karel Mořický: 
SeQuence Script
SeQuence Function

--KK

Thanks KK. My OCD is sated :-) Fred Gandt (talk) 01:28, 25 March 2014 (CET)

Sorry to butt in uninvited. My understanding is SQS = "Status Quo Sequence (or maybe Script?)" (SQS was originally only intended for controlling the camera during cutscenes), SQF = "Status Quo Function", SQM = "Status Quo Mission", SQC = "Status Quo Campaign". "Status Quo" was the original working title for "Operation Flashpoint", and like the game engine, the file types date back that far. I don't have any sources though. Cheers :) --Ceeeb (talk) 04:31, 25 March 2014 (CET)

I'm not sorry you butted in Ceeeb :-) I like information \o/ Legacy stuff can often seem to make little sense after some years have gone by. I have "Pictures of Matchstick Men" as an earworm now! Cheers! Fred Gandt (talk) 04:41, 25 March 2014 (CET)

Ceeeb makes a lot of sense, I'm sorry I haven't been with Arma since OFP but I believe him. I'd call Some Quality [insert a letter] if it was for me :) --KK

The first scripting language I learned was LSL which I came to wish was built better differently, and am now thinking of what those letters could have stood for on a rough day. I think "Lousy Sodding Language" would sum it up quite well, but in all honesty I owe that shoddy mess a great deal, as it introduced me to programming and development.
I can't help but think that Karel probably knows what he's talking about even though "Status Quo *" makes a lot of sense. In the long run, it doesn't really matter, but - it's nice to know :-) Fred Gandt (talk) 17:52, 25 March 2014 (CET)

Request for comment

At Village_Pump_(proposals)#Interlinking_via_.22See_Also.22  -- Fred Gandt (talk/contribs) 15:32, 11 April 2014 (CEST)

BIS_fnc_addDocumentation

Is there a reason beyond "because no one has done it yet" why the BIS_fnc_* funcs are not thoroughly documented here? -- Fred Gandt (talk/contribs) 02:11, 13 April 2014 (CEST)

My guess would be that each BIS_fnc_ contains header comment with function description and is available from debug console in game. --KK
The issue came to light in chat on the Skype group for scripting, regarding a "how to" question, which revealed the lack of documentation.
I'm assuming that since there's a list of available functions and a few have their own page's, that it would be considered an acceptable use of resources to document the rest for ease of access?
If for no other reason, interlinking would prove useful; all the documentation in one place.
Can you see any reason to not go ahead with adding the rest? I can add the task to my list of things to do (expanding rapidly) >.O -- Fred Gandt (talk/contribs) 22:34, 13 April 2014 (CEST)
I am nobody so you don't have to consult with me on what you want to add. --KK
You have made a lot of effort on this Wiki, YouTube, and your own site to help people understand and do more. You're not nobody :-)
I may not have to consult, but I'm new here, and I'd consider it impolite to just storm on in and shake things up. Collaboration requires a little humility.
That said, I have noted that {{Function}} exists and is in use already, so I guess it's there for a reason! I'll get on it as time allowed. Obviously being followed around will be appreciated. My main reason for being here is to learn, and although I'm keen on improving the Wiki, I know little about the Arma platform at this time, so lack a lot of technical knowledge about it.
BTW - I've got a fairly radical idea about how to improve the "See Also" sections around the Wiki, and if it works (demo to follow) it could save a lot of time and mess, but it is quite radical, and would change the way things are done and look.
It's exactly that sort of change I wouldn't feel good about trying to shoehorn in without community support. -- Fred Gandt (talk/contribs) 02:09, 14 April 2014 (CEST)

createUnit

Hiya!

Thanks for setting me straight about the units, you were right about them spawning at [0,0,0]. I still think it might be beneficial to include when the value does default to [0,0,0] in the article? I would happily remove the bit about no units spawning.

Thanks :) ZamboniBambino (talk) 20:25, 7 May 2014 (CEST)

Not sure this is related to the createUnit. position objNull is [0,0,0] and player on the server is objNull.
Perhaps not, but position is related to createUnit in some way. Would it be useful to add it somewhere ? Or would you consider it to be useless? ZamboniBambino (talk) 22:48, 7 May 2014 (CEST)
Not quite sure what you want to say, that position [0,0,0] will spawn unit in rhe water? I thought this was obvious. That position objNull is [0,0,0], then it is not like you *always* pass position as position player to the unit creation. If you really want to add something not quite relevant to createUnit page, it is generally accepted to use talk page https://community.bistudio.com/wiki/Talk:createUnit people read that stuff too.
Hmm, I don't think I'm getting anywhere. I only wanted to suggest that if a person passes objNull, the position is [0,0,0]. I didn't say that you would always pass that position, or the player's position to the createUnit function. I think in expectation of it being useless to most, i'll just leave it. ZamboniBambino (talk) 23:07, 7 May 2014 (CEST)
In this case this would be a relevant comment for either position or objNull page, if it does not already exist.

Arma_3_CfgWeapons_Weapons and "srifle_DMR_01_DMS_snds_F"

Hey, saw you had undone my change to Arma_3_CfgWeapons_Weapons. I've just tested the addWeapon command on both "srifle_DMR_01_DMS_snds_F" and "srifle_DMR_01_DMS_pointer_snds_F" and only the second produces a result for me. However the first doesn't throw any script error out.

I also manually used BIS_fnc_exportCfgWeapons with the "weapon" parameter and it still says that the class name is "srifle_DMR_01_DMS_snds_F". Were you testing on the dev branch or did you simply look for a script error? I'm quite puzzled as to where the discrepancy is here. SilentSpike (talk) 02:28, 12 June 2014 (CEST)

I tested on latest dev --KK
I just tested with isClass and it came back false. However I'm on stable, would you mind giving the below code a go? It seems like there could be an issue with BIS_fnc_exportCfgWeapons.
systemChat format ["%1",isClass (configfile >> "CfgWeapons" >> "srifle_DMR_01_DMS_snds_F")];
got true on todays dev build
Thanks! Confused as to why the function gives me a false class name on my build, but I'll just assume it's magic and hope the problem goes away in a future update for now.

I thought you might want to weigh in on my recent question over here since you've substantially contributed to the Description.ext page. --SilentSpike (talk) 13:06, 19 August 2014 (CEST)

DeleteVehicleCrew

https://community.bistudio.com/wiki?title=deleteVehicleCrew&curid=16578&diff=85271&oldid=83298

What kinda note is that? :P Don't really understand your point there since you're using a completely different command but then use the correct syntax of the actual command.-- Tryteyker-

Not sure why you are having problem with my note. You could delete crew with deleteVehicle, since forever. Did we need another command for it? I don't know. So I compared them. The difference I noticed is in that note.--KK
Not having a problem with it, just didn't see the point in it exactly. but yeah I guess having a more direct command is always good in a sense.--Tryteyker- (talk) 21:19, 13 October 2014 (CEST)

(in)valid commands inside a "count" loop

I hope you know that I wouldn't write something into the Wiki, which I haven't tested before. So I'd like to clearify this.

I'm running the latest "stable" version of ArmA 3, which is 1.32.127785 and I know you run the dev branch, so I don't know if that coincidently matters regarding this issue.

Just when I was formulating my addition to the "forEach vs count" section of the Code Optimisation article, I tested the following code in the debug console of the ingame editor:

_array = ["1", 2, 3, "4", "5", 6, "7", 8, 9, 10]; { _array deleteAt 2; // _array pushBack "11"; } count _array; hintSilent format ["%1", _array];

You may also uncomment the pushBack line and delete the deleteAt line, the result will be the same.

I just tried it once again as sort of the ultimate foolproof test, but nothing was different (obviously). It doesn't matter if I take "_array" or another array inside the "count _array" loop, the error message is the same:

Error in expression <2, 3, "4", "5", 6, "7", 8, 9, 10]; {{diag_log _x} count _array; } count _> Error position: <diag_log _x} count _array; } count _> Error Typ Zahl, erwartet Bool ... where "Typ Zahl, erwartet Bool" (German) means "Type Number, expected Bool", guess you figured that out. "Number" is whatever data type _x has, but "expected Bool" is what the compiler throws whenever I use an invalid command inside a "count" loop.

So I'd like you to tell me if the very same code I posted here works for you and if so, please tell me your startup parameters.

I'm starting my arma3.exe using a batch file to start it with high CPU priority. This is it: start /HIGH arma3.exe -noSplash -noPause -showScriptErrors -enableHT -maxMem=2047 -maxVRAM=2047 -window

Kind regards, Johnny

Perhaps this ticket will shed some light for you: http://feedback.arma3.com/view.php?id=21154 --KK
OK, I understand. But how far does that affect my assertion? Which applies to "pushBack" also applies to "count" as you can do the same thing there:
_array = ["1", 2, 3, "4", "5", 6, "7", 8, 9, 10]; {0 = {diag_log _x} count _array} count _array;
So where is the justification to say that a nested count loop does not work while pushBack and deleteAt do? --Johnny
I'm sorry, but I don't understand, what is the problem here. count expects boolean, you return number, hence the error -> bool expected but found number. You added to biki that pushback and deleteat therefore dont work. I removed it because they do work when you do it the right way, and that is you have to return boolean or nothing. --KK
As for nested business, I think this was a reference to safely nesting _x rather than not being able to tun loop inside loop. I rechecked it and _x behaves just like with foreach. I'm going to remove that. --KK