Question for BIS (Issues with Combined Ops versus OA Standalone clients)

Basic Issue

If a standalone Arrowhead client connects to a Combined Ops server that is running ArmA2 content, he will be able to connect, load and play the mission but will not be able to see the ArmA2 content.

This invisible ArmA content will still be able to kill the client player

If this same mission is run on a standalone Arrowhead server, the ArmA2 content will not exist, but the only notification of this error can be seen in the server.rpt

Testing done with with mission that has

"BMP2_CDF" x 1 (ArmA2 content)

"US_Delta_Force_Undercover_Takistani06_EP1" x 3 playable slots(OA Content)

No scripts, waypoints, triggers, just a basic mission.sqm

We have been trying to set up our community server so that we can cater to both standalone Arrowhead clients and Combined Ops clients

To do this we need our mission developers to create missions that only use Arrowhead content.

To allow them to do this, they ideally need to load standalone Arrowhead. However they are unable to do this with a combined ops installation.

On the other hand, if they were to install Arrowhead as standalone, without workarounds, they cannot then play on Combined Ops servers.

There are also issues with the server set up and how the two different clients will show the servers in the in-game MP browser.

You'll see a red circle with a question mark unless the client is running exactly the same set of mods as the server. A CO

client will show servers that lists "ca;expansion" with a green circle. A standalone Arrowhead client on the other hand, will list

servers that have "expansion" in their list of mods as green and OK.

The ideal solution for the Combined Ops client would be to allow deselecting ArmA2 from the checkboxes listed under the expansions tab thus loading standalone Arrowhead.

It should then behave just like a standalone Arrowhead client in terms of content available for mission editing and MP server list "negotiations" (mod lists and

green/red indicators).

The ideal situation for the server executable would perhaps be to add an additional command line parameter to make a Combined Ops server act as a standalone OA server.

One could say we're looking for a way to "un-combine" a Combined Ops installation.

Terox post is sort of what we really expected in our game organization. We thought that OA would supplement Arma 2 much in the same way the original Flashpoint Games supplemented and improved on each other.

If mission has requiredAddons "CAblabla", how can a pure OA client connect to it?

If mission has requiredAddons "CAblabla", how can a pure OA client connect to it?

Yeah that shouldn't work. The client should be kicked off.

Terox, are you sure you didn't edit the mission.sqm in a text editor instead of the in game editor? When you save the mission out with the regular editor, it should see what external dependencies are required and write them out to addOns[]={} in the mission.sqm.

In other words, OA-only clients should not be able to connect to servers running maps that use A2 addons, they should be kicked off. There shouldn't be invisible objects, that should only happen if:

• The mission.sqm was edited by hand, and the dependencies were not added to addOns[].
  
• A unit is created by the scripting engine, and that unit's class is not listed in mission.sqm:addOns[]
  
• Some bug?
  

This whole thing is a big mess because:

• The mods and modfolders the server started up with may have NO IMPACT if a client will be able to join or not. For example, a server can have some server-side utility addons loaded, like armaLib or DAC which have zero impact on clients.
  
• Because of the above, no silly indicator should be showing anything of the sort, its misleading to clients. It's harking back to the OFP -equalmodrequired days.
  
• What does matter, is if the server is using classes on the map currently being played. If a client does not have those classes, he should be kicked. (and this is how it normally works) But instead of BIS adding a gamespy query variable that lists the addons currently in use by the mission, they list the addons that the server started up with (which is meaningless, as explained above).
  

We've been doing this for a lot of years lads, this is why the question was aimed at BIS. Please re -read the initial post.

Terox post is sort of what we really expected in our game organization. We thought that OA would supplement Arma 2 much in the same way the original Flashpoint Games supplemented and improved on each other.

OA is advertiused as standalone, niot an addon pack lilke OFP resistance

Try recreating the mission, it is not hard, 3 playable units one cdf BMP and host it on a dedicated standalone and a dedicated combined arms and test with 2 clients, 1 standalone OA, one Combined ops.

@Oktane, the initial post clearly states that no scripts were used.

You are correct, when you say the whole this has issues and gamespy is misleading to some clients.

Mission was created in the mission editor and as stated does not use ANY scripts NONE nor was it manually edited.

This is the mission.sqm

version=11;
class Mission
{
addOns[]=
{
	"cacharacters_e",
	"CATracked",
	"desert_e"
};
addOnsAuto[]=
{
	"cacharacters_e",
	"CATracked",
	"desert_e"
};
randomSeed=1180125;
class Intel
{
	startWeather=0.30000001;
	forecastWeather=0.30000001;
	year=2012;
	month=6;
	day=24;
};
class Groups
{
	items=1;
	class Item0
	{
		side="WEST";
		class Vehicles
		{
			items=3;
			class Item0
			{
				position[]={1317.4917,42.760551,1333.3591};
				special="NONE";
				id=0;
				side="WEST";
				vehicle="US_Delta_Force_Undercover_Takistani06_EP1";
				player="PLAYER COMMANDER";
				leader=1;
				skill=0.60000002;
			};
			class Item1
			{
				position[]={1331.366,42.573521,1336.8037};
				special="NONE";
				id=1;
				side="WEST";
				vehicle="US_Delta_Force_Undercover_Takistani06_EP1";
				player="PLAY CDG";
				skill=0.60000002;
			};
			class Item2
			{
				position[]={1341.4628,42.746643,1333.8442};
				special="NONE";
				id=2;
				side="WEST";
				vehicle="US_Delta_Force_Undercover_Takistani06_EP1";
				player="PLAY CDG";
				skill=0.60000002;
			};
		};
	};
};
class Vehicles
{
	items=1;
	class Item0
	{
		position[]={1329.1509,42.152397,1352.0128};
		azimut=250;
		id=3;
		side="EMPTY";
		vehicle="BMP2_CDF";
		skill=0.60000002;
	};
};
};
class Intro
{
addOns[]=
{
	"desert_e"
};
addOnsAuto[]=
{
	"desert_e"
};
randomSeed=7125972;
class Intel
{
	startWeather=0.30000001;
	forecastWeather=0.30000001;
	year=2012;
	month=6;
	day=24;
};
};
class OutroWin
{
addOns[]=
{
	"desert_e"
};
addOnsAuto[]=
{
	"desert_e"
};
randomSeed=8225385;
class Intel
{
	startWeather=0.30000001;
	forecastWeather=0.30000001;
	year=2012;
	month=6;
	day=24;
};
};
class OutroLoose
{
addOns[]=
{
	"desert_e"
};
addOnsAuto[]=
{
	"desert_e"
};
randomSeed=12187450;
class Intel
{
	startWeather=0.30000001;
	forecastWeather=0.30000001;
	year=2012;
	month=6;
	day=24;
};
};

Our serverside install was done using the following procedure.

1) Install OA as standalone and patch it to 1.52

2) Make a copy of the install and use that copy for the standalone test server

3) Uninstall OA

4) Reinstall OA as a combined ops install to the armA2 root

5) Use copies of this master install as the combined ops server.

If you want to try and reproduce this, make sure it is vanilla. The new CBA/CBA_OA used for standalone installs adds some classnames that are ArmA2 based and therefore some classes from ArmA2 can be present in the OA standalone, this by pure chance also includes the cdf bmp.

Take NOTE, once we discovered this we shut dowen the cba mod folders and reproduced the problem described above in a vanilla OA server

class Mission
{
addOns[]=
{
[...]		"CATracked",
[...]	};

CATracked should kick out any pure OA client, unless they also use CBA & CBA_OA.

The reason is that there may be some pbos that are being shared. Having installed as stands alone and CO, would you mind checking how many of the A2 pbos are used with OA.

In A2 folder, there should be a folder called "common". Check how many of these are in the OA_standalone install.

I did not imply you were using a script, I just mentioned that that is an avenue that can create non addOns=[] sanitychecked objects that would be invisible to clients that didn't have it. (they should get a popup error once however)

While not ideal to create OA-only suited missions with a A2+OA dev enviroment (ie your map editor), it does serve to demonstrate a big issue if the game is no longer kicking players based on certain missing content. That may be a huge problem. I think it is due to the config overrides as others have mentioned. I am guessing the common folder contains updated data for the old units in A2, via partial classes which inherit the original A2 addons and override them with the new features. In Common\tracked.pbo, there exists a class patch for CATracked which has no units in it:

D:\Arma2\!Configs\OA_Common_Extracted\tracked\config.cpp

00416: class CfgPatches

00417: {

00418: class CATracked

00419: {

00420: units[] = {};

00421: weapons[] = {};

00422: requiredVersion = 1.02;

00423: requiredAddons[] = {"CAData","CACharacters","CACharacters2","CAWeapons","CASounds"};

Which may explain why OA-Only clients are able to get in without errors, but then have invisible objects? More knowledgeable people would know if that's relevant. (but a lot don't visit the BIF anymore) There are no CATracked classes in OA proper, they are all appended with CATracked_E_Classname. There are no references to BMP2_CDF in OA or Common at all, it only exists in stock ArmA2 addons.

In any case, since you've been around so long you should know the BIF is not the place for serious bugs amidst all the noise, that's what the CIT is for. You can wait and if by chance a BIS dev sees this, he'll likely tell you the same.. suggest to make a CIT bug for it. :) (doubt? do an advanced search Keyword(s): CIT ; Posts Made By: Dwarden) If it is a reproducible bug from a sanity checked environment, it will likely be taken care of by BIS very quickly and the result contained within the upcoming beta patches if possible. http://dev-heaven.net/projects/cis/wiki

It sounds pretty serious at least.

Cheers

Hi all

The major problem this causes is the inability to create Vanilla OA mission content without resorting to hacky crapy shit.

A lot of us wanted to just create missions to welcome in new players as it stands we have to leap through hacking loops to do it, for new ArmA players how the heck are they going to be able to do so?

Sadly walker

In A2 folder, there should be a folder called "common". Check how many of these are in the OA_standalone install.

C:\Program Files (x86)\Bohemia Interactive\ArmA 2 Operation Arrowhead

Common

Expansion

I made a folder with just Expansion, Common, and the client and server exe, and ran a server and client just fine on PC that already had Combined Operations install. I was able to launch just standalone OA that way. Hope that info helps...

EDIT - That is a OA standalone intall from Sprocket. It had not been patched yet when I did this. I'll edit it after I patch it (if I feel like using an activation on this).

EDIT - Here's what I did...

1. On computer 2 I have OA Standalone (patched, no Arma 2) installed. I ran server from there with -exThreads=1 and config=server.cfg only. (with beta you don't need exThreads=1)

2. On computer 1, I have combined operations installed, but I ran AO client only from my separate standalone folder I made (Common, Expansion, arma2ao.exe). I created MP mission in this standalone mode.

3. I put MP mission on computer 2 standalone server and connected with standalone from computer 1 and ran it fine.

4. I also connected to computer 2 standalone server with computer 1 combined operations client and ran same mission.

Result - You can make AO only missions with CO install by just creating folder with stuff I said above and running standalone AO client. AO standalone and CO clients can play these missions. Also you can run just standalone AO server this way.

There's another thread discussing the same thing more or less, so if I'm confusing the two, sorry... And maybe there's an easier way, but I didn't want to start renaming stuff and fucking with my CO install. It was easier to just make a new folder...

Having installed as stands alone and CO, would you mind checking how many of the A2 pbos are used with OA.

In A2 folder, there should be a folder called "common". Check how many of these are in the OA_standalone install.

Both installs contain the same 35 addons

In any case, since you've been around so long you should know the BIF is not the place for serious bugs amidst all the noise, that's what the CIT is for. You can wait and if by chance a BIS dev sees this, he'll likely tell you the same.. suggest to make a CIT bug for it. :) (doubt? do an advanced search Keyword(s): CIT ; Posts Made By: Dwarden) If it is a reproducible bug from a sanity checked environment, it will likely be taken care of by BIS very quickly and the result contained within the upcoming beta patches if possible. http://dev-heaven.net/projects/cis/wiki

It sounds pretty serious at least.

Cheers

I intended to do just that last night, but it was getting late and that would be the obvious next step. It would be nice if somebody else could confirm all this too.

@Mosh,

I think you will find, that your standalone, if it were a server will still, as far as gamespy is concerned show mods running as ca;expansion, even though probably CA content isnt installed.

We tried disabling, removing, renaming addons folder, dta folder and the arma2 exe's from our CO install to try and get a standalone OA server, however, the -mod startup showed ca;expansion, so somewhere in the background I would assume it loads a dummy CA mod folder as sort of a BIS hack. Now although there probably wasn't any A2 content loaded, the problem that then occurs is a standalone client sees the server on gamespy with a red circle and a question mark in it, instead of a green circle.

I also think the fact that the ArmA2 mod folder is called CA and the expansion tab shows ArmA2 would also be confusing to a newcomer to BIS games

So even if we were to hack some startup param, loading -mod folders, the poor unsuspecting newcomer, who already has problems with 3rd party content in ArmA2 is going to have a nightmare now at a vanilla level if he has a standalone OA client

@Mosh,

I think you will find, that your standalone, if it were a server will still, as far as gamespy is concerned show mods running as ca;expansion, even though probably CA content isnt installed.

Yes I see that now.

Dev Heaven Issue submitted >> http://dev-heaven.net/issues/11759

What would happen if you were to include content that the two versions don't have in common (pun intended). For example CAUtes?

This doesn't address the issue of what happens at run-time but in response to this thread I've just created a tool which you can, at least, use to tell you which pbos on your server are likely to be problematic for users. See this thread.

Both installs contain the same 35 addons

There goes the reason why you cant control a player to make an "OA only" mission with CO editor.

One has to use OA Only installation to create OA Only mission, to be sure.

"required addons" control is not enough due to the common pbos. So OAOnly player can join the server & launch the mission but will probably have problems & horrendous errors in rpt if not crashed.

"required addons" control is not enough due to the common pbos. So OAOnly player can join the server & launch the mission but will probably have problems & horrendous errors in rpt if not crashed.

Compounded even further if scripts, triggers are running on that content.

Update on Dev Heaven, its been noted and assigned. In the meantime SbSMac's tool will allow filtering of missions for a standalone OA server. Thx for that.

You can easily make your Combined Operations installation into Operation Arrowhead by using Deadfast's Combined Operations Disabler: http://forums.bistudio.com/showthread.php?t=102380