-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
I'm not sure the organizing into folders thing helps. |
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). |
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 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. |
As a quick fix, move the factions to folders, add something like
to the top of fn_assignGear.sqf, and then "catch" the includes as
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. |
regarding " the #include crashing issue", I think, if we remove light, we can also remove the includes that included the light/standard files. (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) |
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. |
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). |
Don't think this should be closed, I'd still like to folderize assignGear at some point. |
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.
The text was updated successfully, but these errors were encountered: