Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert all suitable settings to CBA Settings #36

Closed
wants to merge 5 commits into from
Closed

Conversation

jonpas
Copy link
Member

@jonpas jonpas commented Sep 11, 2016

When merged this pull request will:

  • Convert difficulty and basic mission settings to CBA settings.
  • Add ACRE_DEPRECATED macro.
  • Deprecate and hide "Difficulty Settings" and "Basic Mission Setup" modules (still usable, just not visible if not already placed, to be removed in 2.4.0).
  • Update "Basic Mission Setup" module to call new helper functions (for seamless "run once" handling).
  • Add acre_api_fnc_getAllRadios function (with caching) that returns all radios in CfgAcreRadios in format [ ["class1", "class2",], ["name1", "name"] ] (can easily be expanded for more information.
  • Move CBA settings to API component.
  • Remove unused disableSignalLoss function.

Requires #33 due to CBA settings preparation being there!

"Name Channels" module was not converted as it's designed so multiple of them can be placed to configure each side. That can be moved to Eden attributes one day when we have a nice framework for that maybe.

@NouberNou
Copy link
Member

This sounds like it is moving along. Keep me posted on testing.

@jonpas
Copy link
Member Author

jonpas commented Sep 13, 2016

This has nothing to do with C++ side, the commits show up because it's based on #33. Not sure if this is viable yet, will decide once this is fully tested.

Copy link
Member

@Sniperhid Sniperhid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't scope away the modules for now.

class GVAR(basicMissionSetup) : Module_F {
scope = 2;
scope = 1;
Copy link
Member

@Sniperhid Sniperhid Sep 14, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would disagree with hiding the modules for now. As they are pretty intuitive for most mission makers

class GVAR(DifficultySettings) : Module_F {
scope = 2;
scope = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing again with hiding the module

@NouberNou
Copy link
Member

What is the decision here moving forward with modules? Should we get a dev build out soon and testing these things?

Also backwards compatibility is big, so we gotta make sure that this isn't going to break old missions that use or rely on modules for core functionality.

@PabstMirror
Copy link
Collaborator

PabstMirror commented Sep 17, 2016

CBA 3.1 will have some new events that were designed to help with backwards compatibility for ace modules/settings which will be going through the same transition problems.

Ref CBATeam/CBA_A3#437

Modules should be able to add event handler for CBA_beforeSettingsInitialized
And inside that call event CBA_settings_setSettingMission with [_setting, _value, _true]
Actual 3den cba settings will be loaded first and take priority

@Sniperhid
Copy link
Member

From what I understand Jonpas is planning to do some further experimentation here, Modules that effect the mission settings would a nice method.

@Sniperhid Sniperhid added the WIP label Sep 17, 2016
@jonpas
Copy link
Member Author

jonpas commented Sep 17, 2016

Yes, no point discussing anything until I do more work on that.

@jonpas
Copy link
Member Author

jonpas commented Sep 20, 2016

I will extract all fixes and improvements from this PR into a separate one.

@jonpas jonpas mentioned this pull request Sep 29, 2016
@jonpas jonpas removed this from the 2.3.0 milestone Sep 29, 2016