Jump to content
Sign in to follow this  
sickboy

CBA: Community Base Addons public release!

Recommended Posts

I'm using Kegetys ArmA2 Launcher, have @CBA as one of the entries and it's checked. It also resides in the ArmA2 directory. Funny thing is if I disable

it (uncheck it) in the launcher, I get the same message. So basically I can't play the game at the moment. Thanks for your reply though......very much

appreciated.

Share this post


Link to post
Share on other sites

Sickboy,

This updates fixes the problems I detailed in the Domination thread. Both the CTF side missions and the flags on enemy bases work again.

Many thanks!

Share this post


Link to post
Share on other sites
Sickboy,

This updates fixes the problems I detailed in the Domination thread. Both the CTF side missions and the flags on enemy bases work again.

Many thanks!

NP! Glad to have resolved the issue!

Share this post


Link to post
Share on other sites

yeah, tried that. tried everything i could think of. guess i'm going to

re-install arma2 *sigh*

damn, even if you're real careful about the mods you install, you still

get stuff like this that's just "unfixable". i guess back up, back up

and back up is the mantra.

Share this post


Link to post
Share on other sites

Hi,

I'm having a few issues with CBA and a mission I'm working on. Basically the mission init.sqf runs a loop and calls createUnit about 500 times (battalion sized force). Vanilla ARMA2, no problems (near-instant generation). ARMA2 + CBA 0.3.1, loop stops roughly halfway, and after about 10-15 seconds I see the rest of the units appear one by one.

Right now I'm thinking it might be the event handlers kicking in at some point and slowing things down, but I really don't know. Any thoughts would be really appreciated!

Share this post


Link to post
Share on other sites
Hi,

I'm having a few issues with CBA and a mission I'm working on. Basically the mission init.sqf runs a loop and calls createUnit about 500 times (battalion sized force). Vanilla ARMA2, no problems (near-instant generation). ARMA2 + CBA 0.3.1, loop stops roughly halfway, and after about 10-15 seconds I see the rest of the units appear one by one.

Right now I'm thinking it might be the event handlers kicking in at some point and slowing things down, but I really don't know. Any thoughts would be really appreciated!

Maybe you're affected by the same issue as this bug report details: Bug #9590?

In that bug report, Sickboy has attached a variant of the addon "extended_eventhandlers.pbo". Replace the current one you're using and try the one in that bug report and see if it helps.

If it doesn't help, we'd like a copy of the troublesome mission that exhibits the problem you're seeing. If you register at DevHeaven, you can create a new bug report in the CBA project page and attach a mission that shows the problem.

Share this post


Link to post
Share on other sites

Sorry for the late reply, but it seems CBA just exposed a flaw in my original mission :) Thanks for the help though!!

Share this post


Link to post
Share on other sites

Hi,

How implement cba/csm sounds in a mission without creating problems like :

- 6 tasks shown in the briefing instead of 3

- AI are blocked during the mission

Does someone got the same problem like me before ?

(note : cba was updated yesterday)

Share this post


Link to post
Share on other sites

XEH doesnt seem to be triggering (INIT EH) for my addon

- I've checked the launch short cut.

- No errors on entering ArmAII

- checked the script works manually, it does.

Ideas?

Config

class CfgPatches
{
class Coaler
{
	units[] = {RKTCoalerS,RKTCoalerI,RKTCoalerD,RKTCoalerR};
	requiredVersion = 1.01;
	requiredAddons[]={"Extended_Eventhandlers"};
};
};
...
...
..

class CfgVehicles
{
class Plane;
class RKTCoalerS : Plane
{
....
....
	class EventHandlers
	{};
};

class Extended_Init_EventHandlers {
class RKTCoalerS {
	RKTCoalerS_init = "[_this select 0] exec ""\rktcoaler\scr\common_init.sqs"";_scr = _this execVM ""\ca\Data\ParticleEffects\SCRIPTS\init.sqf"";";
};
class RKTCoalerI {
	RKTCoalerI_init = "[_this select 0] exec ""\rktcoaler\scr\common_init.sqs"";_scr = _this execVM ""\ca\Data\ParticleEffects\SCRIPTS\init.sqf"";";
};
class RKTCoalerD {
	RKTCoalerD_init = "[_this select 0] exec ""\rktcoaler\scr\common_init.sqs"";_scr = _this execVM ""\ca\Data\ParticleEffects\SCRIPTS\init.sqf"";";
};
class RKTCoalerR {
	RKTCoalerR_init = "[_this select 0] exec ""\rktcoaler\scr\common_init.sqs"";_scr = _this execVM ""\ca\Data\ParticleEffects\SCRIPTS\init.sqf"";";
};
};
....
.... other XEH ...

Share this post


Link to post
Share on other sites
Gnat;1619324']XEH doesnt seem to be triggering (INIT EH) for my addon

- I've checked the launch short cut.

- No errors on entering ArmAII

- checked the script works manually' date=' it does.

Ideas?

[/quote']Yep - inside your CfgVehicles::RktCoalerS class, you define an empty class EventHandlers. Don't do that. :)

(What happens then is that XEH can't do it's magic on RktCoalerS and descendants thereof, since you override (remove) the 'global' class EventHandlers that XEH applies to vehicles)

Share this post


Link to post
Share on other sites
Yep - inside your CfgVehicles::RktCoalerS class, you define an empty class EventHandlers. Don't do that. :)

(What happens then is that XEH can't do it's magic on RktCoalerS and descendants thereof, since you override (remove) the 'global' class EventHandlers that XEH applies to vehicles)

lol ... typical, after a bunch of hours pulling my hair out, I find the answer at the same time you posted the answer.

Thanks Killswitch.

Share this post


Link to post
Share on other sites

Hey guy's,

sorry, but i'm currently a bit confused about all the nice additional classes we can use with C.B.A.

I was looking for a X.E.H. class which will be initialized at the very first beginning.

First i have used:

class Extended_Init_Eventhandlers
{
class CAManBase
{
	class GL4_System
	{
		init = GL4_EH_System
	};
};
};

Now i have changed it to:

class Extended_PreInit_EventHandlers
{
class GL4_System
{
	init = GL4_EH_System
};
};

I thought the "Extended_PreInit_EventHandlers" will be executed way earlier like the "Extended_Init_Eventhandlers" but to me it looks like the "Extended_Init_Eventhandlers" are executed way earlier.

Is this correct?

So which X.E.H. class is the best to get a fast initialize of my stuff?

Share this post


Link to post
Share on other sites

Order of initialization:

  • PreInit (Init-Once)
  • Init (Init-per vehicle)
  • PostInit (Init-Once)
  • InitPost (Init-per vehicle)

In each initialization stage, components are initialized in the order they are available in the in-memory-config.

This order is decided by requiredAddons[]= setup in various CfgPatches.

Each init has 3 variations: just init, serverInit and clientInit (they are initialized in this order).

Example file: http://dev-heaven.net/projects/cca/repository/revisions/develop/entry/addons/common/CfgEventHandlers.hpp

Unpacking the addons and then looking at the configs will give you example without the macros :D

Tip: Don't use spawn or execVM (incl sleep) if you want to time your initializations, call is the only way to go here.

Edited by Sickboy

Share this post


Link to post
Share on other sites

Yeah exactly this way the way i was thinking it get's initialized.

Strange thing sometimes the "PreInit" will be executed 3 seconds after the mission was started? Guess this should be executed way earlier bevore the mission starts.

The "Init" always is executed very earlie like i need it so things are already initialized when the mission beginns.

Anyway thanks for the info Sickboy and i will do some more tests with it. ;)

Share this post


Link to post
Share on other sites

It should be impossible for PreInit to run after Init. Maybe you use execVM somewhere and therefore the timing is way later?

When called from within eventhandlers (or other such 'fields') sleeps should be completely impossible, not sure about waitUntil.

While loops end after 10.000 iterations (and should completely halt the processing until finished). So im not sure :)

However, the CBA diagnostic logging is set to run asynchronous, so if you are comparing direct diag_log usage in an "Init", while comparing with an asynchronous logged message by CBA, you really have to compare the diag_ticktime or other timestamps, not the order they are written into the log :)

Edited by Sickboy

Share this post


Link to post
Share on other sites

I've found any Extended_Init_EventHandlers that trigger SQS scripts to be extremely flaky.

Sometimes they work/trigger, sometimes not. Change the number of units in a mission or editor, and it changes again.

I even rolled back to an older CBA install, no difference.

Finally I only got it working by converting everything to SQF with tight code.

Is this normal ?

I'd have thought not.

Share this post


Link to post
Share on other sites

No idea, years on SQF here.

There should at least be no difference between BIS EH behaviour, or XEH EH behaviour.

Ya might wanna check out kju's SQS/SQF converters btw. Iirc it takes a second to process a script library :D

Share this post


Link to post
Share on other sites
There should at least be no difference between BIS EH behaviour, or XEH EH behaviour.

Yeh, I would have thought, but it worked in BIS EH, but not XEH EH.

Share this post


Link to post
Share on other sites
Gnat;1620934']Yeh' date=' I would have thought, but it worked in BIS EH, but not XEH EH.[/quote']

What version of ArmA are you running btw? There seem to be several reports about the last few beta's being problematic for scripts, im guessing sqs being more expensive, might suffer more under this?

Does the problem occur in conjunction with other mods like ACE or just simple XEH/CBA aswell?

Share this post


Link to post
Share on other sites

Last patch, not running betas.

Problem with NO mods except CBA, addon was stand-alone ( @Testing mod folder) on a vanilla ArmAII

To be honest, it looked like a timing problem. When you FIRST run an editor mission they usually triggered, but when you re-ran (previewed) the same mission in the editor (no changes), it failed.

I actually saw it as; The island (and addons) loading (lag) delay actually allowed the scripts to trigger, but once the island was loaded in the background, there was no significant load lag, and the XEH would fail.

Share this post


Link to post
Share on other sites

Quite odd! Thanks for the details.

I will try to make some time this week and look at it. Not that SQS is high prio, but rather the different behaviour is :)

Share this post


Link to post
Share on other sites

Just updated to 0.4.0.96

How can I disable the CBA loading screens? It's messing with some other UI addons.

And how can I disable the CBA entry within the briefing and the status messages in the ArmAII.rpt?

Thanks in advance :)

Edited by [GLT] Legislator

Share this post


Link to post
Share on other sites

The loading screen has a purpose (described here: http://dev-heaven.net/issues/7808#note-4), the image shown is a default existing one. And: http://dev-heaven.net/projects/cca/wiki/Author_and_Credits_system

Some related notes on loading screens: http://forums.bistudio.com/showthread.php?p=1634002#post1634002

We could add means to configure which image(class) to show. (There wasn't any interest shown when proposed before).

What means exactly 'messing with other ui mods'? :)

The CBA entry cannot be disabled by configuration either atm, though you could override the init eventhandlers.

Edited by Sickboy

Share this post


Link to post
Share on other sites

BW Mod and Ike's Hud Mod both use custom loading screens. CBA is hammering between them so the images change very, very fast. It's a real pain for the eyes. I wish BW Mod would make their UI optional as well. :(

Uh well, but how can I disable the credits and author system in my mission? My briefings are loaded enough so I don't want any further unnecessary information.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×