CBA: Community Base Addons public release!

[AnimalMother92 10]

I gotta agree, the post init loading screen is quite annoying. It's not so much that I mind the extra loading time, it's that you can see the actual game for a brief second -- and then you get whacked with a loading image again. It's just odd looking going to the main menu or starting a mission with a cutscene.

[sickboy 13]

Well the loading screen as described in the links above is crucial to a fast initialization of all scheduled scripts. This is a small price to be paid due to how the things work since arma 2. (This counts for all scripted systems, though we could possibly improve by moving some PostInits to PreInit.)

If not applied, it will mean it could take 10's of seconds into the mission before certain systems are initialized etc. (So it seems it is a delay, but in fact you save a lot :) and on top of that, we've given it another function; the random display of author credits (usable by anyone))

The loading screen during beginning of mission should only occur in SP. As in MP it is before or during briefing.

Maybe we can find out which loading screen is the one displayed by default, so it won't 'switch'.

Maybe disabling it for the main menu, as there the delayed initializations might mean less, still rather not :)

Edited May 23, 2010 by Sickboy

[cleggy 297]

Can someone enlighten me here?

I have a simple addon that uses the default BIS eventhandlers 'init' and 'fired'.

Running CBA/ACE everything works as expected.

Why do I need to config it to be 'extended event handler' compatible?

Don't get me wrong I'm quite happy to give it a go if it makes my addon more user friendly - I like nothing better than tweaking a config!

I just don't see what it would bring to the party - so to speak.:confused:

Sorry if it's a dumb question but the stuff you guys are doing is light years ahead of where I'm at.

[sickboy 13]

Heya. When using BIS default eventhandlers, only 1 eventhandler of each type can be active at once.

This means for instance, only your eventhandlers, or only someone else's.

This means systems cannot be used together, because only one can be active at a time.

The Extended Eventhandlers, originally created by Solus back in arma1, make it possible for any number of eventhandlers to be attached, complimenting eachother as opposed to overruling eachother.

Using XEH in your addon will make it more compatible with others.

While also providing additional functionality on top of the standard eventhandlers, like pre/post init (for init-once scripts e.g function compilation, global variable initialization, etc), and the ability to attach handlers on just clients, or servers, or both (default).

(Post init happens after all objects are initialized, at the briefing in MP, ensuring the player object readyness on clients)

Please see http://dev-heaven.net/projects/cca/wiki/Extended_Eventhandlers for more info.

ace_sys_eject example: http://www.pastie.org/975198

Edited May 24, 2010 by Sickboy

[cleggy 297]

Thanks for the reply SB - I even understood the first part:)

Applied XEH to my config. 'init' works but 'killed' does not.

Here is the relevant bit:

class Extended_Init_EventHandlers { 
   class BLX_FV432_base { 
       BLX_FV432_base_init = "_scr = _this execVM ""\ca\Data\ParticleEffects\SCRIPTS\init.sqf""; _scr1 = _this execVM ""\BLX_FV432_base\init.sqf""; "; 
   }; 

}; 


class Extended_Killed_EventHandlers
{
         class BLX_FV432_base
         {
               BLX_FV432_base_Killed = "_scr = _this execVM ""\BLX_FV432_base\killed.sqf"";";
         };
};

Could someone tell me what i'm missing from the 'killed' eventhandler?

[sickboy 13]

Thanks for the reply SB - I even understood the first part:)

Applied XEH to my config. 'init' works but 'killed' does not.

...

Could someone tell me what i'm missing from the 'killed' eventhandler?

NP. :)

Please try:

class Extended_Killed_EventHandlers
{
         class BLX_FV432_base
         {
              class BLX_FV432
              {
                    killed = "_scr = _this execVM ""\BLX_FV432_base\killed.sqf"";";
              };
         };
};

Also make sure to add "Extended_Eventhandlers" to your CfgPatches, requiredAddons[].

It's also possible you have another addon in use that possibly overrides XEH eventhandlers (killed) on the same class, or higher up in of the inherited classes.

[konrad1 10]

i HAVE AN question to the userconfig so.

i have to acc. in ARMA 2 and so play with both is there any way i can do that i play with acc.1 it sould use the userconfig 1 and if i play with he 2nd it should use usercf. 2 ??

beacuse i always have to overwrite the userconfig .

PLS HELP

[killswitch 19]

i HAVE AN question to the userconfig so.

i have to acc. in ARMA 2 and so play with both is there any way i can do that i play with acc.1 it sould use the userconfig 1 and if i play with he 2nd it should use usercf. 2 ??

beacuse i always have to overwrite the userconfig .

PLS HELP

CBA doesn't have a "userconfig". You'll have to take this problem up with the authors of the specific mod/addon you're using.

(Phrased otherwise: this is not a CBA problem)

Having said that, there's no easy way of doing what you want to do, since the "userconfig" folder will be shared between those two Windows accounts, since the "userconfig" folder exists in the ArmA II installation folder.

Edited June 6, 2010 by Killswitch

[Big Dawg KS 6]

Do you guys know if I could force an XEH fired EH to be called before any other fired eventhandlers are called (specifically BIS's)? I have an addon that is currently just adding eventhandlers with addEventHandler from a script called on the object's init. This seems to ensure they are called before any other fired eventhandlers, but it would be nice to make use of XEH fired eventhandlers if possible.

Also, I couldn't seem to get preInit stuff to work. I have an init script that must be called to compile stuff being called by the fired EH's, and the example I followed didn't seem to work.

[sickboy 13]

The execution order is based on the config load order, which is largely based on the requiredAddons[] (part of CfgPatches) chain. This works in reverse to what you want though: You can make sure your addon loads after other addons, by requiring them in your requiredAddons.

I suppose if you'd create a seperate addon name starting with A, A_some_addon, without any requiredAddons it'd load first.

In any case, the BI EH's are added to XEH, in XEH itself, so not requiring XEH could put you first in line aswell.

Please show the example, hard to tell what you do wrong without it ;)

[Big Dawg KS 6]

I'll have to wait til I get back to my home PC to post code, but thanks for the response. So you're telling me there's no way to guarantee call order for the eventhandlers using XEH, or at least guaranteeing being called before others. I guess I'll stick with my method of using addEventHandler since that seems to work.

I'll get back to you on the preInit thing when I get home.

I have another question though, does XEH have a way of ensuring that an EH gets called on all clients in MP if only the server has the addon installed? MP and locality isn't really one of my areas of expertise and I haven't really examined the documentation for XEH all to carefully.

[sickboy 13]

NP.

Yes, there's no method coming to mind how to get it to load earlier consequently, however since it is more related to the config load order, maybe there is a way, I just don't know it :)

I suppose it could be a new feature? Maybe something to consider for OA.

Edited June 7, 2010 by Sickboy

[11aTony 0]

I just installed CBA 0.4 and I see now there is extra CBA in notes in every mission. There is credits and some more details. There wasnt this in 0.3 so Im wondering, is this really necessary? Im sure everyone will still know who made CBA and appreciate it if you leave that in readme like before.

[Big Dawg KS 6]

NP.

Yes, there's no method coming to mind how to get it to load earlier consequently, however since it is more related to the config load order, maybe there is a way, I just don't know it :)

I suppose it could be a new feature? Maybe something to consider for OA.

Well I do have a method that works so it's not really an issue. It just would have been nice.

Do you have an answer to my question about MP?

---------- Post added at 01:53 PM ---------- Previous post was at 01:51 PM ----------

I just installed CBA 0.4 and I see now there is extra CBA in notes in every mission. There is credits and some more details. There wasnt this in 0.3 so Im wondering, is this really necessary? Im sure everyone will still know who made CBA and appreciate it if you leave that in readme like before.

Indeed this has also been sorta bothering me. Having nothing to do with the mission, it's just extra clutter that really doesn't need to be there.

[Inkompetent 0]

I just installed CBA 0.4 and I see now there is extra CBA in notes in every mission. There is credits and some more details. There wasnt this in 0.3 so Im wondering, is this really necessary? Im sure everyone will still know who made CBA and appreciate it if you leave that in readme like before.

The loading screen isn't there to look fancy and give credits. It is used for credits as a side effect, and any mission maker can make it display what they want it to display as far as I've understood. The loading screen is there because it freezes everything else in the game, so that CBA can initialize fully before stuff depending on CBA starts getting run.

[Big Dawg KS 6]

The loading screen isn't there to look fancy and give credits. It is used for credits as a side effect, and any mission maker can make it display what they want it to display as far as I've understood. The loading screen is there because it freezes everything else in the game, so that CBA can initialize fully before stuff depending on CBA starts getting run.

He's talking about the CBA entry in the breifing notes. If you open up the map ingame, you will see it along with mission breifing & notes. I don't see what purpose it serves, if any, and I'm wondering if it really has to be there.

[sickboy 13]

The Diary entry added with CBA is pretty functional, it contains a Keys overview, any addon making use of the userconfig keys system will be displayed there, ACE is an example.

The Credits page dynamically contains any addon with author information, this includes CBA, ACE, and there's many more that add the info to their CfgPatches entry.

Then there's also links to important documentation.

ATM the only way to override it is by overriding the XEH PostInit of CBA_help, I suppose I could add additional means if some are really bothered by it, however I believe it is a good endevour especially if more addons make use of it :)

Related docu:

http://dev-heaven.net/projects/cca/wiki/Author_and_Credits_system

http://dev-heaven.net/projects/cca/wiki/Help_System

http://dev-heaven.net/projects/cca/wiki/Versioning_System

@KS: Eventhandlers are attached on the machine where the code is executed, so clients and server will need XEH + the addons or mission that adds the eventhandlers. This behaviour is equal to config and script eventhandlers.

[Inkompetent 0]

He's talking about the CBA entry in the breifing notes. If you open up the map ingame, you will see it along with mission breifing & notes. I don't see what purpose it serves, if any, and I'm wondering if it really has to be there.

Oh, right. Total misread by me. Yeah, I wonder about the usefulness of that too. Although I can't say I find it in the way. It's just... there. At least some kind of direction for the casuals not frequenting the forums I guess.

[Big Dawg KS 6]

The Diary entry added with CBA is pretty functional, it contains a Keys overview, any addon making use of the userconfig keys system will be displayed there, ACE is an example.

The Credits page dynamically contains any addon with author information, this includes CBA, ACE, and there's many more that add the info to their CfgPatches entry.

Then there's also links to important documentation.

But does it have to be in the journal? Right now it just sort of... stands out to much. IMO it should be hidden in game unless you need it for some reason. It kind of kills imersion seeing addon related jibberish in your ingame journal.

@KS: Eventhandlers are attached on the machine where the code is executed, so clients and server will need XEH + the addons or mission that adds the eventhandlers. This behaviour is equal to config and script eventhandlers.

Well, the effects of my scripts are global (at least they should be). They need run only on the server I guess. I guess problems arise when the vehicle's the EH's are attached to are local to the clients. Guess I'll have to run a serverside script to find and attach EH's to each vehicle.

[sickboy 13]

Depends which eventhandlers you're using. Fired is global for instance, so attaching it on the server is fine if you only need it there, it will trigger regardless of the vehicle's locality.

It's documented on the BIKI EH overviews.

The Journal was convenient, maybe activation by key combination or otherwise in the pause UI, maybe alternatives? Any suggestions?

[Big Dawg KS 6]

Hmm... So here's what I might try.

In the script that is called by the fired EH, it should run only on the client local to the vehicle IF that client has the addon installed. If not, it will run on the server. The problem is, how does the server tell whether the client to whom the vehicle is local has the addon?

---------- Post added at 03:27 PM ---------- Previous post was at 03:26 PM ----------

The Journal was convenient, maybe activation by key combination or otherwise in the pause UI, maybe alternatives? Any suggestions?

Key combination is fine, or in pause UI. As long as it's hidden from regular gameplay interfaces.

[killswitch 19]

Hmm... So here's what I might try.

In the script that is called by the fired EH, it should run only on the client local to the vehicle IF that client has the addon installed. If not, it will run on the server. The problem is, how does the server tell whether the client to whom the vehicle is local has the addon?

Yeah, that's not easy to do. While CBA/XEH can help you with the fired EH itself, the functionality you require would need loads of "handshaking" between the server and clients.

What exactly is it that you want to achieve by having the server conditionally run an event handler only if a client doesn't have the addon?

[Big Dawg KS 6]

Yeah, that's not easy to do. While CBA/XEH can help you with the fired EH itself, the functionality you require would need loads of "handshaking" between the server and clients.

What exactly is it that you want to achieve by having the server conditionally run an event handler only if a client doesn't have the addon?

The eventhandler calls a function that adjusts the position of the projectile immediately after it's fired. Execution order is important, since the new position has to be used when the BIS particle FX kick in. If the code is executed exclusively on the server, then there's no guarantee that there won't be a (significant) delay between the server updating the position and the FX spawning on the client. Therefore, if at any time I can, I'd like to have the setPos function be executed on the client, and then not have the server interfere by setPosing it again (which might be noticable). I guess there's no perfect way to do this without modifying the BIS code though, since with multiple clients, only the one running it would see the effects immediately.

---------- Post added at 10:36 AM ---------- Previous post was at 09:00 AM ----------

Here's my proposed solution:

When the code initializes on the server, set a publicVariable that indicates the server has the addon running to true. In addition, initialize an empty public array.

When the eventhandler called code executes on the client, check this variable. If it's true, check the locality of the vehicle. If its local, insert the vehicle (if it's not already in) into the array and rebroadcasts it, and then calls the rest of the code.

When the server runs the EH called code, it checks if the vehicle is in the public array. If it isn't, run the code, otherwise do nothing (as it would have already been run on the client).

All of the mentioned code (except for the initialization) is being called, and not running in parallel with the engine, so any delay (desynchronization) will be due to the network.

Does this sound like a feasible solution? I guess it depends on how quickly and efficiently publicVariable works. It doesn't have to be updated every time the fire EH executes since once a vehicle is put into the array it does not need to be updated until a different vehicle is put in. This is assuming that vehicles can't change locality... (can they?).

[xeno 230]

This is assuming that vehicles can't change locality... (can they?).

They can.

Xeno

[Big Dawg KS 6]

Then I suppose I'll also need to find a way to update the array when the vehicle is no longer local to a client with the addon...

This is starting to get pretty complicated. :icon_neutral: