BAS f

[raedor]

edit: On a completely off-topic subject has BAS considered revisiting JAM for ArmA?

Just to answer this: JAM is now in the hands of Combat!/G85, they're working on it.

[Pillage]

JAM is now in the hands of Combat!/G85, they're working on it.

Oh hell yeah! raedor, I kid you not that is the best news I've had all week. A uniform magazine standard across the addon making community is what I've hope for from the beginning of ArmA. Although JAM was huge in OFP it came after hundreds of weapon packs had already been released.

[raedor]

CBT! is part of G85, as well as many other mods.

But please back on topic!

[Fer]

Question: Is it possible in the next release to modify the authorized crew check to be based on unit class rather than editor defined names?

Nice idea! I believe this could be done for unit classes such as crew and pilot. Adding it to the list of ideas for the next major release.

Suggestion: Is it possible in the next release to add a timeskip script having 24hrs game time pass in 1hr real time? I think Evolution contains such a script but can't think how to implement it.

We can look into it ....

edit: On a completely off-topic subject has BAS considered revisiting JAM for ArmA?

Like Raedor says, JAM has gone to another team, who I'm sure will be making good progress. Remember to support standards!

BTW, sorry it took me so long to reply - something must have gone wrong with my topic-watch settings, as I never got an email telling me of new posts in this thread.

[Fer]

<span style='color:red'>NEW RELEASE</span>

BAS f v0-0-31 Beta

Introduction
This is the fifth beta release of the BAS f mission framework for ArmA, which includes <span style='color:red'>26</span> core and optional components (some of which have been developed with premier gaming community, ShackTactical), and a 53-page illustrated manual which is available in English, German and Russian translations. All text strings used in this version have been translated into Czech, German, Polish, Russian, Spanish and French.

<span style='color:red'>What&#39;s New?
New in this release:

- Authorised Crew Type Check (restrict AFVs to crewmen, aircraft to pilots etc.)
- ShackTactical: Fireteam Markers (showing location, orientation and name of fireteam buddies)
- Updated Casualties Cap component (now more accurate and robust)
- Minor corrections to the manual and stringtable.csv files</span>

For more information and download links, please check the top post in this thread, here:

http://www.flashpoint1985.com/cgi-bin....t=59444

[Fer]

Question: Is it possible in the next release to modify the authorized crew check to be based on unit class rather than editor defined names?

Done. Check out the Authorised Crew Type component in the latest build, v0-0-31 Beta (see top post in this thread for download links).

Hope this is what you meant&#33;

[Terox]

Hi, just a couple of thoughts to throw into the couldron, for future design discussion

1) Dead body removal
This could be done more efficiently, by having the killed event, add the unit to the end of an array, count the elements in the array and then delete the first element if the count was greater than DeadBodyCountLimit
The number of dead units local to a player could use a different cap limit than the server and there would be no need to synch the arrays across the network. What you would accomplish is reducing for instance 30 dead ai units running a "sleep" routine for 20 minutes, that will reduce cpu requirements somewhat, especially on larger scale missions

2) I see some arrays that need to be manually edited, these arrays tend to be group names or units etc, would it not be better to script create local triggers to do this automatically. This woulkd reduce the number of "systems", or lines of code that need to be editied by a would be mission maker

3) It may also be better to simply have a Settings.sqf, Description.ext and the briefing template for editing purposes.

It has been my experience that the less a mission maker has to edit, as in searching through files and folder, the more likely he is to succeed in his first attempt and then use, for instance a template or "framework" again

for debugging purposes, this is also easier, because there would be less locations where a user error could occur.

These are just a few thoughts which may help you improve on your existing framwork

[Fer]

1) Dead body removal
This could be done more efficiently, by having the killed event, add the unit to the end of an array, count the elements in the array and then delete the first element if the count was greater than DeadBodyCountLimit. The number of dead units local to a player could use a different cap limit than the server and there would be no need to synch the arrays across the network. What you would accomplish is reducing for instance 30 dead ai units running a "sleep" routine for 20 minutes, that will reduce cpu requirements somewhat, especially on larger scale missions

That sounds like an interesting approach, and anything that might make help reduce the burden on server and / or client is worth investigating. If you have the time, would you be able to work up a new version of the component?

2) I see some arrays that need to be manually edited, these arrays tend to be group names or units etc, would it not be better to script create local triggers to do this automatically. This woulkd reduce the number of "systems", or lines of code that need to be editied by a would be mission maker

Usually, when an array needs to be edited it is because the mission designer requires precise control over which units or groups are affected by the component. For example, the vehicle and units which are covered by an instance of the Authorised Crew Check component need to be named specifically.

Alternatively, wherever possible there is already fairly extensive use of your suggested trigger method. For example, both AI Skill components use arrays of all groups in the mission, which are automatically generated using the BAS f Common Variables component.

Nevertheless, you raise a really important point. It&#39;s tricky getting the balance between configurability and ease-of-use, but I do think we try to save time for the mission designer whenever possible. Of course, I won&#39;t claim we have a perfect solution&#33;

3) It may also be better to simply have a Settings.sqf, Description.ext and the briefing template for editing purposes.

It has been my experience that the less a mission maker has to edit, as in searching through files and folder, the more likely he is to succeed in his first attempt and then use, for instance a template or "framework" again for debugging purposes, this is also easier, because there would be less locations where a user error could occur.

I totally agree - and it has been the aim to try and minimise the number of files which must be touched directly by the mission designer. At present, 95% of all configuration happens in the init.sqf file, description.ext (and of course the briefing.html and mission.sqm files). There are exceptions - the MP Ending Controller and Kegetys&#39; Spectator Script do require other files to be edited, so things are not as &#39;clean&#39; as the ideal.

These are just a few thoughts which may help you improve on your existing framwork

Thanks&#33; I&#39;m grateful that you took the time to look over the code and post. This kind of detailed feedback is gold.

[Tankbuster]

I like this. A lot.
I&#39;m lucky in that BAS f is aimed directly at me. I have some knowledge of the editor; I can use waypoints, triggers and logic and I&#39;m making real progress using BAS f. It&#39;s like you&#39;ve been looking over my shoulder and said "Let&#39;s make something for HIM&#33;"

One question - I took the plunge and installed at version 0-0-31. What am I likely to need to do as subsequent versions come out? Will any missions I&#39;m working on now get broken by future versions?

Cheers&#33;

Tanky -Paul-

[MCPXXL]

I got no shack markers after the first respawn