F2 Mission Development Framework (BAS f for ArmA 2)

[galzohar 31]

Are you still using the old assign gear method, meaning you execVM the script from the unit's init line and exit it if the unit is not local? I hope you do realize that it simply fails on occasion?

1. Unit may be not local to the server when the script runs on the server, yet not local on the client when the script runs on the client. This is easily solved by running the assign gear script only on the server and calling it with call compile preprocessFile rather than execVM so that it finishes running before anyone joins. Of course that also means all sleeps and waitUntils need to be removed from the script, but that shouldn't be a problem as long as you don't fill rucksacks with the script, but to be honest rucksacks would give you issues no matter what method you use due to how ACE implements them. This solution also allows you to see your gear during the mission briefing.

2. Players who JIP into an AI unit may on rare occasions reset the loadout. I think this happens because, on rare occasions, the unit becomes local to the client before the script executes, thus equipping him as if it was the mission start. This is obviously bad on missions without respawn as it can duplicate gear over and over again. The above fix of running the script only on the server solves this issue as well.

3. Units that don't exist at the start of the mission and are spawned by joining, while playing with disabledAI=1 with certain respawn settings (at least with BASE and GROUP), will cause all kinds of issues. The above solution doesn't solve this, obviously, as init lines on rare occasions simply don't run on those units.

The above problems are nothing common and aren't exactly something you can reproduce (at least not easily), but they do happen.

[fer 21]

Yep, it still runs that way. As you say, there are some rare issues with that approach, but as you also acknowledge, they are hard to reproduce. For the moment I think we'll stick with the current approach.

[subroc 4]

Will the F2 run on OA/OA+A2 installations?

[BelgarionNL 10]

yeah make a special version for OA if you can plz :)

some things don't quite seem to work in OA

[fer 21]

some things don't quite seem to work in OA

I'm in the process of downloading OA and will begin work on a port ASAP. However, if you have already found issues with the current build of F2 and OA it would be very helpful if you could share them in this thread.

[fer 21]

New Release: F2 v2-4-1 (for ArmA2 and OA)

About the new release

With the release of F2 v2-4-1 come two major changes:

1. F2 is now available in a number of different builds. Each build contains components required to create missions for a particular group or mod combination (e.g. ShackTactical, ACE2 etc.).

2. F2 now supports ArmA2: Operation Arrowhead (via new build: F2 OA Folk).

From the ReadMe.txt file:

2-4-1 | 11 JUN 2010

Added OA Briefing component.

Added OA Folk Platoons component.

Added OA Folk Assign Gear component.

Added OA Folk Group IDs component.

Added OA Folk Group Markers component.

Added OA Folk JIP Reinforcement Options component.

Updated F2 ReadMe.txt to reflect addition of support for Operation Arrowhead.

Updated manual: Various changes (EN and RU versions).

2-4-0 | Internal

Changed the structure of F2 to the new Foundation + Builds approach.

Updated manual: Various changes (EN and RU versions).

2-3-3 | Internal

Added Folk Platoons component.

Added Folk Assign Gear component.

Added Folk Group IDs component.

Added Folk Group Markers component.

Added Folk JIP Reinforcement Options component.

Updated manual: Various changes (EN and RU versions).

[call_911 10]

Sorry if this has been asked already. Looking through this it appears to the default faction is set to Takistani Locals. Is there a Blufor(US/Delta) planned or quick way to switch these too? Thanx. Also was waiting for this release much appreciated for mission maker noobs like me:yay: Is it possible to just switch the group to Blufor an copy paste the name an init info or will it break somthing?

[fer 21]

Is there a Blufor(US/Delta) planned or quick way to switch these too? ... Is it possible to just switch the group to Blufor an copy paste the name an init info or will it break somthing?

An OA build of F2 using the ShackTactical platoons (for all sides) is in the works. The OA Folk build may be expanded soon as well - we'll see what we can do for you!

[call_911 10]

An OA build of F2 using the ShackTactical platoons (for all sides) is in the works. The OA Folk build may be expanded soon as well - we'll see what we can do for you!

Sounds good, will keep an eye out for it. Thanx.

[daoarge 203]

Heyho,

I just built a mission using F2 2.4.1 (OA Folk). Everything is working perfectly, but only JIP players do not get objectives synced when they join.

Could anyone give me some advice on this? (JIP reinforcement selection option is disabled, let me know if you need further info)

Thnx!

DO

PS: Thanks a lot for this framework! :icon_eek:

[fer 21]

Hi DaOarge, glad you like the framework and find it useful. Afraid I can't tell you exactly how to synch your objectives (that will depend on what they are), but I can suggest a place to put the code you use to do that:

init_onPlayerRespawn.sqf

Despite the name, this init also runs when a player JIPs into the mission. You might want to write some code here which checks for certain variables and then sets objectives accordingly. Hope that helps.

:)

[dmitri 0]

We're having an issue which seems to be related to F2's Mission Conditions Selector.

There's always one or two clients that aren't synced with the time selected in the mission parameters. Selecting 'night' leaves some clients with daylight. It appears to be random and happens quite often.

This has happened both in ArmA 2 and OA on multiple missions using the framework.

I've double checked the setup and it all seems correct. Any ideas?

[galzohar 31]

If you installed everything properly I can't see why this wouldn't work at all for some players but work for others. One thing that you might have done that broke it though, is:

In init.sqf there should be a line:

f_processParamsArray = [] execVM "f\common\f_processParamsArray.sqf";

If you for some reason removed the f_processParamsArray = part, then on some occasions the conditions script will work and in some cases it won't.

And on a less related note, the F2 set conditions script is a bit messy. What it does is set the conditions for every JIP client on the moment of JIP back to the time that the mission is supposed to start at. So if you make a mission before sunrise with fog and overcast clear weather and then play for a while, players currently playing will see sun and clear weather while players JIPing at that time will see dark (before sunrise) and fog.

A solution to this is to do both the paramsArray processing and the conditions selection through a game logic that runs them using the call compile preprocessFile command, and only run the conditions script on the server. If you set the conditions at that point on the server, any client, JIP or not, will get the correct time/weather without needing any script to run on his machine. That is, as well as Arma 2 is capable of, that is, there are still issues with weather synchronization that have nothing to do with user-made scripts.

[daoarge 203]

Hi DaOarge, glad you like the framework and find it useful. Afraid I can't tell you exactly how to synch your objectives (that will depend on what they are), but I can suggest a place to put the code you use to do that:

init_onPlayerRespawn.sqf

Despite the name, this init also runs when a player JIPs into the mission. You might want to write some code here which checks for certain variables and then sets objectives accordingly. Hope that helps.

:)

I set the objectivestates by using triggers, where the corresponding variables are "publicVariable'd". According to this page: http://community.bistudio.com/wiki/6thSense.eu:EG#Join_in_Progress these variables should get synced to JIP players automagically - that would have fit me lazy guy :)

But thanks for the clue anyway, i think i can handle this issue via the above mentioned script!

cya,

DO

[fer 21]

We're having an issue which seems to be related to F2's Mission Conditions Selector ... I've double checked the setup and it all seems correct. Any ideas?

I'm not sure. The feature has been used pretty extensively with large groups like Shack Tactical, and I can't recall that issue arising more than once or twice in a few years. Is there anything particularly challenging about your sessions? For example, do you often suffer from high desynch / pings? In other words, is there a way to reproduce this issue?

And on a less related note, the F2 set conditions script is a bit messy. What it does is ... there are still issues with weather synchronization that have nothing to do with user-made scripts.

Galzohar, I'd be interested to see a proof-of-concept for what you suggest. Do you think you could build one, starting with the F2 OA Folk build of F2?

[galzohar 31]

Basically if you set weather on the server only before any clients even get to download/load the mission (aka by running/calling it from a game logic or a unit's init line), it'll be synched for everyone. Apparently when you don't use any scripts to change time/weather, anyone who connects will get time/weather from the server based on the current time/weather on the server. If you actually set time/weather before even the first player connects (again, possible by running/calling it from a game logic's init line), then clients don't have to run any time/weather-related scripts and they'll be synched with the server.

A similar idea works with weapon loadouts. If you run the gear scripts before any player even had the chance to load the missions, then all units will be local to the server and get their weapons before anyone even reaches the briefing screen, resulting in both a reliable script for missions where player units aren't created on-JIP, and with the weapons being visible when you look at your gear in the briefing screen. Of course any sleep/waituntil is not allowed in such a script, which can cause problems with ACE rucks since in order to fill them you have to wait for the ACE functions to become defined first, but it's not something that can't be worked around if you really want to use ACE rucks.

[galzohar 31]

Another note: You seem to have broken the spectator script for players who JIP straight into a seagull. You included f_waitforjip.sqf in both specta_init.sqf and specta.sqf. You shouldn't have done that. Removing the #include from both scripts makes it actually work for players who JIP into a seagull.

The playerSide command does need to wait for player to be initialized or else it always returns west, so if you want to limit sides that are spectate-able then you could be having an issue, but it's not like the current version is any better.

[vipermaul 246]

Another note: You seem to have broken the spectator script for players who JIP straight into a seagull. You included f_waitforjip.sqf in both specta_init.sqf and specta.sqf. You shouldn't have done that. Removing the #include from both scripts makes it actually work for players who JIP into a seagull.

Thanks for bringing this to our attention.

#include "f_waitForJIP.sqf"

Has been there forever and I don't remember having any problems in the Arma 2 days of using F2 Spectator such as this.

Can you please PM me a copy of your mission that demonstrates this issue? And we can make sure a fix is submitted.

[galzohar 31]

The issue happens in every mission. All you have to do is join into a slot that has its AI disabled in a mission with no respawn, so that the player will join the game straight into a seagull. The script has stuff that try to start it up in that situation, however the JIP check never ends so the script doesn't even get a chance to start.

Obviously for players that actually played and then died everything works fine as the f_waitForJIP.sqf doesn't get stuck for them. The issue is with players who JIP later into a seagull - They should be able to spectate as well, and removing the JIP check allows them to do so.

Edited August 4, 2010 by galzohar

[vipermaul 246]

The issue happens in every mission. All you have to do is join into a slot that has its AI disabled in a mission with no respawn, so that the player will join the game straight into a seagull. The script has stuff that try to start it up in that situation, however the JIP check never ends so the script doesn't even get a chance to start.

Obviously for players that actually played and then died everything works fine as the f_waitForJIP.sqf doesn't get stuck for them. The issue is with players who JIP later into a seagull - They should be able to spectate as well, and removing the JIP check allows them to do so.

Very well. Thanks. This will be fixed in the next release.

[fer 21]

Someone very kindly wrote to me the other day and asked me what the hell a folk platoon was/is. So I've added an explanation of the folk platoon concept to the F2 wiki. Hope this helps! Watch out for a new OA build of F2 very soon ...

[Cato Larsen 10]

I gotta ask.

Is there any reason why the camo net over mobile respawn vehicle and ammo box will not work??

The mobil respawn point works and the deploy and pack text is available and works, but the ammo crate and camo net will not be there.

Any help?

Cheers.

[fer 21]

Is there any reason why the camo net over mobile respawn vehicle and ammo box will not work??

The mobil respawn point works and the deploy and pack text is available and works, but the ammo crate and camo net will not be there.

Hi Cato, I assume you're talking about a feature within the Revive component, and if so you need to ask your question in this thread:

http://forums.bistudio.com/showthread.php?t=74396

Hope that helps! Thanks for using F2 :)

[Cato Larsen 10]

Ok, cheers Fer.

I was hoping it was a know answer to it :)

Anyway, thank for the F2 mate.

Good tool ones you get used to it.

Cheers.

cato.

[ArmAIIholic 10]

Hi F2,

what you lack in tips about COIN is how to increase funds for a player? For example, I want to increase "money" for the player that is constructing after he enters some trigger.

I suppose I would have to use getVariable, but since it is written:

call compile format ["_coin setvariable [""BIS_COIN_funds"",[""%1Var""]];",_str_coin];
call compile format ["%1Var = _coinFunds",_str_coin];

_coin is local....

So how can I get state of current funds for a player and then increase it for X amount. F2 script has only starting funds e.g. [MyCOIN,"MyEngineer",2,5000]