Jump to content
Sign in to follow this  
fer

F2 Mission Development Framework (BAS f for ArmA 2)

Recommended Posts

Hi Wolf I'm having trouble posting on the I44 forums at the moment so I'm posting questions here.

Finally getting to the ORBATS for I44 starting with US Army. I'm trying 12 man teams instead of 14 (default) as we discussed with the following structure:

A Lead - SL, Medic

A1 Recon - FTL, SMG

A2 FT - FTL, Rifle, Gren, Rifle/Bazooka/FT, SMG

A3 Support - FTL, AR, Assisstant

I think I like this layout better than evening out A2 and A3 with 4 per squad but am open to suggestions.

I am somewhat new to the assign gear stuff and the unit naming scheme so just working through that.. what is the convention for the actual unit names in the editor? IE: UnitUS_A1_AR ... say I wanted to name the SMG unit in Recon A1 would it be UnitUS_A1_SMG? Basically I use the assign gear 'label' as the unit name like (nul = ["smg",this] call f_fnc_assignGear)?

Also what are your thoughts on the other factions? Should I attempt to keep the same squad layouts as US Army or use more 'accurate' ones (especially for ze Germans)?

Edited by SavageCDN

Share this post


Link to post
Share on other sites

Hey Savage, I've got the some issue and was about to PM you here.

An option would be to have A1 and A3 with 3 each, as I don't know how much sense a 2-man fireteam makes gameplay-wise.

A1 could be all SMGs while A2 sports the rifles and A3 is the fire support. The naming suggestion sounds good. As long as they are coherent through the platoons it shouldn't be a problem.

I think the same layout should work for the British and Germans. Alternatively their MGs (BAR/MG42 or 34) could be removed from the squads themselves and the number of organic MG attachments increased by default.

Btw. I've uploaded a new version of F2-i44 to github, implementing some of the changes made in the regular F2 and further tweaking the loadouts (all backpacks and inventories should be full by default now).

Share this post


Link to post
Share on other sites

Roger that.. I think you are correct about the 2 man squad I will adjust.

When are you looking to wrap this up? Should I bear down this week and get it done?

Share this post


Link to post
Share on other sites

I'm travelling atm. and I'd wait for the release of 2-7-0, so there's no rush. I have a few ideas for the German factions (especially the SS and Paratroopers). Mind if we take it to the Folk Forum?There's already a thread in the dedicated F2 development subforum. No need to blow up the F2 thread here.

Edited by Wolfenswan

Share this post


Link to post
Share on other sites

You guys should make a lite version of F2 Framework, which would only include things that most mission makers use. After speaking with several people on our teamspeak, most don't use F2 because it's contains an overwhelming amount of trivial, un-needed/wanted functions. Unless you don't care about the size of your mission file, you're usually left to weed out the un-needed functions. Which, for a lot of people can be a daunting task, since certain files are required/linked to other files all over the place.

---------- Post added at 19:59 ---------- Previous post was at 18:34 ----------

How do I get Kegtys Spectating to work? I 've made sure that [] execVM "f\common\f_spect\specta_init.sqf"; is un-commented in the init.sqf and that #include "f\common\f_spect\spectating.hpp" is un-commented in the description.ext. I've tried with respawn set to both "BIRD" & "BASE". I've tried on preview and dedicated server. I've made sure a team mate (AI) was present. I've made sure any revive features are commented/disabled.

note: this is with an fresh F2_OA_Folk.Takistan example mission.

---------- Post added at 20:27 ---------- Previous post was at 19:59 ----------

foo = [player,player,"null"] execVM "f\common\f_spect\specta.sqf"; works with a radio trigger though... but I can't spectate upon death.

Edited by Iceman77

Share this post


Link to post
Share on other sites

Would you mind setting up a list of what you guys consider to be unnecessary?

The total of it sums up to about 1Mb for now, which seems reasonable. Norrin's revive has been removed for the latest versions, precisely in this optic. Now I know there's been talk amongst the devs to make it more modular, maybe based on optional config files, though this will probably be for a next version.

Regarding the spectator script, that's really strange indeed, as it should work as is. Note that if you test that alone won't work, because the mission will end anyway when all players are dead (meaning when you die).

Share this post


Link to post
Share on other sites

Well the only thing I can think of, is maybe because I was the only actual player...

---------- Post added at 06:11 ---------- Previous post was at 06:04 ----------

And yes they should revamp it so all you modify is one config file, containing all of the available options for a simple enable or disable via a bool value. If players want to dig deeper to tweak certain things to their liking that's fine to.

As far as a list for a lite version, I think most common things would be the mission conditions, spectator script, player markers (with names) and add in a very simple mobile respawn. That's what I'd want.

Share this post


Link to post
Share on other sites
they should revamp it so all you modify is one config file, containing all of the available options for a simple enable or disable via a bool value. If players want to dig deeper to tweak certain things to their liking that's fine to.

Well that's exactly how it is now, all you have to do is comment/uncomment lines in the init.sqf. Said config files would just remove the FOLK platoons from the main build, basically. At the moment, trying to use another Orbat is quite the bitch.

As far as a list for a lite version, I think most common things would be the mission conditions, spectator script, player markers (with names) and add in a very simple mobile respawn. That's what I'd want.

Although we don't use player markers because that would really mess up the map, it can be done quite easily by adapting the folk_localSpecialistMarker.sqf script.

Mobile respawn, I guess nobody thought about it because we don't use repawn. I guess this could be added, yet having that and the spectator script might be kinda counterproductive.

But as far as your list goes, those are more things to add than things to remove. I was asking about what you guys see as trivial, un-needed/wanted functions. I do have a few ideas myself (like, for instance, the COIN system, as I've never used it), but I'm pretty sure this kind of things does please some of the users, and I believe this is why they're still in there.

Share this post


Link to post
Share on other sites

Well it's not just one file you have to edit. Also, the instructions could be better on how to use the framework. While some topics are documented well, others are vague. For example the (F2) kegtys spectator wiki/guide I linked earlier, leaves out crucial information, such as how to use the spectator script. In the how to use section it jumps straight to how to enable/disable optional parameters. Instead of starting with the basics, like uncommenting which code, which type(s) of respawn the script works with (bird, base etc). Does it require more than one human to activate. Can it be used for missions with respawns? ie; 30sec respawn delay you get the spectator script during that time? Is it only for no respawns (bird)? While this may seem trivial, but it is after all supposed to be a guide on how to use the framework.

As far as trivial features go, imo the coin, kit & group picker are my initial thoughts. While a lite version still might not contain even some of the useful features. Your average editor wants mission conditions, player/squad markers, body delete & mobile respawn. Maybe a mission marker and task JIP feature of some kind.

Also as far as respawn goes, the majority of the community plays with respawns. The frameworks is aimed at the masses of the community no?

Share this post


Link to post
Share on other sites

I use F2 for pretty much every mission and I usually end up cutting out the files I'm not using (only to keep mission file size down). I think this would be a good idea (lite version). What I usually don't use:

Gear scripts

Group picker

COIN

Share this post


Link to post
Share on other sites
Also as far as respawn goes, the majority of the community plays with respawns. The frameworks is aimed at the masses of the community no?

It sure is. As I said, what probably happened is nobody thought about it because we don't use it. Honestly I have no idea what Fer thinks about this though, so I guess he is the one to answer that.

The spectator script, as stated in the wiki, replaces the default seagull mode. Means it works with respawn = 1 or 4; in your Description.ext.

So no, I don't think you can have the spectator mode between respawns (at least as is).

You don't have anything to do to activate it as it is activated by default.

Basically, I guess the philosophy behind all this is you're better off with too much stuff than with not enough. That being said, you're right, if you really need to be careful regarding mission file size, this might be an issue.

All the missions we play are designed using F2 and size from 800kb to 2.5Mb approximatively. This doesn't seem to be an issue with highest player counts at around 60 iirc.

You can, I swear, disable all unneeded components using the init.sqf only. (the only exception being the medical system, for which you need to delete the modules in the editor).

Although, if you really want a lighter version, what you could do is take some time to create your own build, by deleting the components you're sure you won't ever use. In which case I'd be happy to help.

Regarding mobile respawn, there's two major ways to go at it:

- first, create a respawn marker far way on the map and use the built in Respawn INIT to move the player to whatever position you want.

- Or, have another script move that marker around (e.g getpos setmarkerpos on an MHQ vehicle)

Share this post


Link to post
Share on other sites

I know it's a bit OT but what are the issues with large mission file-sizes? We usually have a player count in the 20-30 range but I've never really thought about the mission file being an issue.

Share this post


Link to post
Share on other sites

Well, not a real issue per se, just that the larger the mission file, the longer the download time. And if you get a high player count, all those dudes need to download it from the server at the same time, so it gets exponentially longer.

But you can run a large event with a 3.5Mb mission file without any problem actually. It's just going to take a bit longer to get everybody properly loaded in.

This is why the need for a lite version was never felt on our side anyway.

Share this post


Link to post
Share on other sites
It sure is. As I said, what probably happened is nobody thought about it because we don't use it. Honestly I have no idea what Fer thinks about this though, so I guess he is the one to answer that.

The spectator script, as stated in the wiki, replaces the default seagull mode. Means it works with respawn = 1 or 4; in your Description.ext.

So no, I don't think you can have the spectator mode between respawns (at least as is).

You don't have anything to do to activate it as it is activated by default.

Basically, I guess the philosophy behind all this is you're better off with too much stuff than with not enough. That being said, you're right, if you really need to be careful regarding mission file size, this might be an issue.

All the missions we play are designed using F2 and size from 800kb to 2.5Mb approximatively. This doesn't seem to be an issue with highest player counts at around 60 iirc.

You can, I swear, disable all unneeded components using the init.sqf only. (the only exception being the medical system, for which you need to delete the modules in the editor).

Although, if you really want a lighter version, what you could do is take some time to create your own build, by deleting the components you're sure you won't ever use. In which case I'd be happy to help.

Regarding mobile respawn, there's two major ways to go at it:

- first, create a respawn marker far way on the map and use the built in Respawn INIT to move the player to whatever position you want.

- Or, have another script move that marker around (e.g getpos setmarkerpos on an MHQ vehicle)

Well you have to edit the description ext to include/exclude some .hpps. At any rate this isn't a large issue, I know my way around the framework pretty well. Aside from the spectator problem, which I did infact find out you have to have more than one player present, which makes sense for seagull. I could sift through the framework and take out what I don't want, I just brought that up because some people would find that a daunting task and get frustrated. At first glance it seems like a huge mess to an average user. I've made single player MHQ scripts, I'm just not so good at MP scripting, regarding marker JIP for an MHQ. I'll defo have a look at this respawn INIT though.

@savage - Regarding file size, it's just a pet peeve of mine. Having ~50-75 unneeded files floating around in a mission folder makes me shudder =)

Anyhow, I just thought it be a nice thing for F2 to include a couple different official versions. Lite/normal etc etc.

Edited by Iceman77

Share this post


Link to post
Share on other sites

I've made single player MHQ scripts, I'm just not so good at MP scripting, regarding marker JIP for an MHQ. I'll defo have a look at this respawn INIT though.

Yeah this is usually the part that gets me.. the MP/JIP marker updating on a moving vehicle.

@savage - Regarding file size, it's just a pet peeve of mine. Having ~50-75 unneeded files floating around in a mission folder makes me shudder =)

Anyhow, I just thought it be a nice thing for F2 to include a couple different official versions. Lite/normal etc etc.

Yes I am built the same way. Sometimes I even go through the F2 files and delete the commented out stuff 'cause I'm crazy :p

Share this post


Link to post
Share on other sites

Markers and JIP have some strange bugs, you can just create them locally to avoid them and as long as you wait for variables to be defined before you try to use them you should be fine in both SP and MP.

Share this post


Link to post
Share on other sites

Thanks for the posts, all; apologies I have not been able to post my thoughts until now:

Reducing PBO file size: By far the easiest way to reduce the size of a PBO is to delete all files associated with Norrin's Revive, which will save on average 300kb (basic instructions are available on this F2 wiki page). The forthcoming v2-7-0 version of F2 will drop Norrin's entirely, because our version is out of date and there now exist a few viable alternatives that mission makers can easily include based on personal preference.

But does it really matter?: Probably far less than you'd imagine, or might have been the case 4-5 years ago when BAS f was first created (the ArmA precursor of F2) and domestic bandwidth was more scarce. Without Norrin's or custom scripting and music files, most of my own missions come in at or just below the 500kb mark. To put that figure in context, I just downloaded a pack of Domi files and see that many come in at or far above the 2Mb mark. Having successfully run 500k F2-based missions with upwards of 80 players on a regular basis, I'm confident that mission makers shouldn't worry about file-size bloat with F2 unless they intend to include a lot of music or image files over and above the framework.

Your time is precious: To put this another way, if you devote an hour into shaving 100kb off the PBO file size, nobody is likely to notice; which is a shame, because an hour spent crafting a really great, concise briefing will produce a much better return on your investment of time.

Disabling/enabling components: optional components are disabled by default, and IIRC all of them can be enabled by uncommenting (and sometimes editing) a line or block of lines in the init.sqf file. The inverse is generally true of core components, and all of these steps are usually captured in the how to enable/disable sections of the relevant F2 wiki page (see this example for Disable BIS Conversations).

You can (and should) make your own stubs: If you feel confident enough, taking a copy of F2 and customising it to create your own personal framework can be a pretty good way to speed up your mission making. It can be as simple as doing some basic configuration of core/optional components, or as complex as stripping out undesired files and/or integrating third party scripts. We don't release new builds of F2 very often these days, so this is a less risky prospect. What's more, if you are part of a community of players, consider sharing your stub(s) with others in your crowd. For example, within Folk, we often share pre-tailored stubs to help people write missions quickly (none are out now, but expect a few to appear with v2-7-0).

Kegetys Spectator Script documents is too light: I agree, and if you can dig out anything from the great man himself, I'll be very happy to link to it from the relevant F2 wiki page.

One man's trivial, is another man's vital: Making a lite version of F2 is more complex in practice than in theory, for the simple reason that different mission makers have different preferences. For example, I never use revive or respawn, and I never restrict vehicle crews because I write for a community where it's sufficient to ask players to leave the A-10s alone; but for someone writing missions for pubbie servers, none of those things may be true. This is why I strongly advocate the practice of making personal/community stubs if you intend to crank out a bunch of missions that share the same basic configuration.

F2 is not as modular as it once was: As the framework has become more ambitious, we have run into issues with the way ArmA2 mission files are structured. For example, the way certain mission configuration aspects are split across the description.ext and init.sqf files can be frustrating if you want to make things truly modular, and that's before you get into the sticky business of pre-placed units in mission.sqm. We've tried our best to achieve modularity in terms of enabling/disabling, but it's not always as neat as having single files/sub-folders you can simply delete in the file manager.

Mainting multiple builds is hard ... and we are few: The next step up from a personal/community stub is the 'build' - essentially different published versions of F2. For a while this was an approach we adopted, and you used to be able to get different builds for ShackTactical with/without ACE2 etc. (see the Downloads Archive page of the F2 wiki for more). The problem is that maintaining all these builds takes manpower that we don't have right now, so we have focused on supporting our primary communities, Folk and ARPS. It would be nice, for example, to offer an ACE2 version of F2, but that would require some new team members.

Anyway, sorry this is a bit of a brain-dump, but hopefully it will shed some light on the thinking behind F2's current form. Thoughts, suggestions etc. always welcome!

Share this post


Link to post
Share on other sites

Thanks for the reply fer. I have a request.

*It would be nice if the spectator script worked with respawns. ie; while you're waiting x seconds to respawn, you get to spectate. I realize you guys don't use respawn, but the majority of your users use respawn .So how about some spectating tweaks?

I realize you're not a 1 man army. Clearly kegetys is a hard guy to track down, so idk how or if you would adjust the spectator script to work with respawns. Just a suggestion.

Share this post


Link to post
Share on other sites

Hmm. Quick idea, though untested (imho, giving the ability to spectate then respawn gives a huge advantage to the player).

You could use a killed event handler to launch the spectator script (although you'll need something to simulate the seagull. A dog on the other side of the map does it pretty well). Then the respawn event handler to terminate it. Although I'm not too sure about how to do that, as I don't know when the respawn event fires.

Share this post


Link to post
Share on other sites

Yeah it would give some sort of edge during a tvt event, even though you can set viewable side etc. During a coop though I think it'd be pretty cool. Would be just another cool feature to have during missions. Along with a missions structure, snazzy features can make a good mission a little better. imo, it's the little things and details combined that make a good mission. Adding spectate ability to some coops couldn't hurt.

Nice ideas btw about how to do this. If you happen to make it work let me know :cool:

Share this post


Link to post
Share on other sites

F2_logo_135x135.gif

New Release: F2 v2-7-0 (for Combined Operations)

Highlights:

1. New Folk ARPS build supports all major ArmA2 and Operation Arrowhead factions.

2. Enable ACRE support with a mission parameter.

3. Join groups on-the-fly, place trip flares in-mission and more ...

From the ReadMe.txt file:

2-7-0 | 15 DEC 2012

Moved development to GitHub (see: https://github.com/ferstaberinde/F2).

Changed OA Folk build to CO Folk ARPS build.

Updated CO Folk ARPS Platoons (USMC, CDF, NAPA, Russian Army, ChDKZ).

Updated CO Folk ARPS Group IDs component.

Updated CO Folk ARPS Markers component.

Updated CO Folk ARPS Assign Gear Script component (supports new factions, backpacks default to ON, vehicle cargo presets for trucks and IFVs).

Added CO Folk ARPS Assign Gear Script component alternative files for: US Army, ACR.

Changed OA Briefing component to CO Briefing Template component (now supports ArmA2 factions).

Updated Casualties Cap component (commented-out lines for all platoons added).

Added ORBAT Notes component.

Added ACRE support component.

Added Join Group Action component.

Extended Trip Flare component (now also placeable in-game).

Removed Norrin's Revive Respawn component.

About F2

The F2 Mission Development Framework (F2) is the successor to the popular BAS f mission development framework for ArmA (discussed in this thread). The new framework contains many of the features you know from BAS f, updated to work with ArmA2 and ArmA2:OA, plus some new components which take advantage of the new game's special features.

For downloads and to find out more please see our online manual:

Huge thanks to current contributors: Harakka, Wolfenswan, DarkTatka, Black Mamba, Head and Mike and to all at Folk ARPS.

Edited by Fer

Share this post


Link to post
Share on other sites

Hi guys,

I am trying to put in some sound files into my mission but when I copy the code into the description.ext the result is a CTD or just no effect at all :confused: so I think its save to say that I just get the code wrong.... could one of you tell me how I get it to work?

This is the end of my des. where I would like to insert the sound part:

// ============================================================================================

// F2 - Gear Snippets
// Credits: Please see the F2 online manual ([url]http://www.ferstaberinde.com/f2/en/[/url])

// #include "f\common\f_gearSnippets.hpp"

// ============================================================================================

class RscTitles {

// ============================================================================================

// F2 - Name Tags
// Credits: Please see the F2 online manual ([url]http://www.ferstaberinde.com/f2/en/[/url])

#include "f\common\f_recog\recogOverlay.hpp"

// ============================================================================================

};

// ============================================================================================

This is the new part I would like to add:

//Sounds
class CfgSounds
{
	sounds[] = {};
	#include "LDL_ac130\CfgSounds.hpp"
};

I got the code from a different description.ext and it is working there perfectly so no idear why that dosent work :(

Share this post


Link to post
Share on other sites

Well the code itself is not wrong. There is no CfgSounds in the standard F2 description.ext, so the problem's not coming from there either.

Are you sure your CfgSounds.hpp is in the right folder?

Share this post


Link to post
Share on other sites

Yes the folder was ok, I think I put a few ; { ; } on the wrong place... never understood what they do :o

but it is working now so my problem is solved thank you for helping me out.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×