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

Address faction bloat #309

Open
darkChozo opened this issue Jul 21, 2020 · 8 comments
Open

Address faction bloat #309

darkChozo opened this issue Jul 21, 2020 · 8 comments
Assignees
Labels
S0:Needs Discussion Ideas, Proposals and other issues that need to be discussed. S2:Work-in-Progress T:Idea

Comments

@darkChozo
Copy link
Collaborator

Spiltting off from #307. We have added a ton of factions to F3 over the years, and with GM we're going to add even more. This is bloating filesize and starting to cause usability issues for missionmaking, particularly in assignGear. We should investigate changes that make working with factions less painful, particularly if they're simpler than totally redesigning a component.

I have two main things in mind here:

First, we should organize assignGear faction files into folders so they're easier to manage/delete without accidentally deleting files that you want to keep. There are a couple of ways to do this: you could just put each faction into a folder, or you could have a folder with all the factions separate from the main assignGear folder.

Second, should we get rid of the light assignGear files? These almost double assignGear's file size, and make assignGear harder to work with, and I don't think I've ever seen them used.

Other things we might want to look at is consolidating the assignGear files back into one, and seeing if there's a way to work around the #include crashing issue.

Any other ideas? Doesn't have to be assignGear, though that's obviously the big one.

@shadow-fa
Copy link
Collaborator

I'm not sure the organizing into folders thing helps.
But I think it's a good idea to remove the light files

@shadow-fa shadow-fa added S0:Needs Discussion Ideas, Proposals and other issues that need to be discussed. T:Idea labels Jul 21, 2020
@darkChozo
Copy link
Collaborator Author

The folders thing is mostly to make deleting spare factions easier. Basically right now you need to avoid deleting something like 15 files out of a list of like 40, whereas if they were folders separate from the core files you'd only need to avoid a folder or two. Conceptually, I also think it's cleaner to separate the gear files from the core files, and the factions from each other (though I'm realizing now that it could cause some weirdness with factions that share files, aka the nato and csat variants).

@SamLex
Copy link
Member

SamLex commented Jul 22, 2020

If something simple can be done in the short term to re-organise assignGear to make it easier for missionmakers to slim down by removing factions they don't need then I think that is something we should do. I also like the idea of removing the light files, assuming they are not regularly being used.

I think ultimately the long term solution is #94, either that solution being designed to be easy to slim down or ideally it being light enough that it doesn't need slimmed down.

@Aqarius90
Copy link
Collaborator

Aqarius90 commented Jul 22, 2020

As a quick fix, move the factions to folders, add something like

#define blu_f
#define blu_t_f
#define blu_w_f

to the top of fn_assignGear.sqf, and then "catch" the includes as

if (_faction in ["blu_f","nato"]) then {
	#ifdef blu_f
	#include "f_assignGear_nato.sqf"
	#else
	#include "f_assignGear_noFile.sqf"
};

And then just delete the factions at the top of the file you're not using, and their folders

And also, yeah, we don't really switch loadouts anymore, the "light" can go.

@shadow-fa
Copy link
Collaborator

shadow-fa commented Jul 22, 2020

regarding " the #include crashing issue", I think, if we remove light, we can also remove the includes that included the light/standard files.
And also, we can remove all of the ramining includes if we just do a calls instead (and transform the files to take the necessary parameters).

(Also we should probably wait for all of the open PRs - that are related to assignGear - to be merged into dev, before we change anything)

@costno
Copy link
Collaborator

costno commented Feb 28, 2021

The #include issue should be the next priority here. Removing the light loadouts is a good step for cutting down that awful folder size. I think I would prefer we just not include the pacific/woodland files by default, have them commented out in fn_assignGear as they already are and then have all sub faction things in the check as (_faction in ["blu_f","nato","blu_t_f","natopacific","blu_w_f","natowoodland"]).

In the rare case where you need more that one climate of a faction, you can add another if/then and split those as needed.

@darkChozo
Copy link
Collaborator Author

IMO the pacific files are worth keeping, but they don't really need their own standard/light files. They can just reference the main assignGear_nato/cast_standard files (tbh I thought they already did).

@darkChozo
Copy link
Collaborator Author

Don't think this should be closed, I'd still like to folderize assignGear at some point.

@darkChozo darkChozo reopened this Apr 27, 2021
@NikkoJT NikkoJT modified the milestones: 3.5.5, 3.5.X Apr 27, 2021
@CSDGC CSDGC self-assigned this Dec 7, 2022
@SamLex SamLex removed this from the 3.5.X milestone Apr 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S0:Needs Discussion Ideas, Proposals and other issues that need to be discussed. S2:Work-in-Progress T:Idea
Projects
None yet
Development

No branches or pull requests

7 participants