CaiusN

Shorter version of questions: https://www.reddit.com/r/xdev/comments/47488x/soldier_class_ranks_framework_prerelease_questions/ My framework provides an easy-access location for players to alter their rank lists without scrolling through their .int/etc file, but also allows classes and subclasses to specify a rank list to use. Think of it like Psi Ops or Long War EW officer ranks. In vanilla, only the "PsiOperative" class template triggers a different rank list. There are two remaining issues: I'm unsure how to manage the subclasses variable(s) included in the core framework, and I need to specify some guidelines so mods that use this framework don't override one another accidentally. A mod author only need include a rank list specifier (text file) in their mod and the UI will pull the correct ranks to go with their class template. I allow this by adding optional variables to GetRankName/GetShortName functions from X2ExperienceConfig.uc and overriding about 20 UI calls. There's slightly more complexity to it but that's the gist. For example, I use both the Long War Leader Pack mod (5 ranks) and a full Officer Class mod (7) ranks. As a subclass takes a bit more configuring, I have the Leader pack using a standard "OfficerNames" list beginning at rank 3. Please tell me: What naming convention should I suggest for rank lists attached to a specific template? ______Names[#]/_____ShortNames[#] by soldier-class template is simple but in the case of Officers or other name conflicts may cause issue. It also may even be "not my problem" but I aim to be user-friendly and maximize compatibility. What conventions should I suggest for subclass rank lists? Should they always use unique lists with a rank pulled from their attached .uc compatibility patch At present this is just the Leader Pack compatibility patch I made for the framework and uses the mod's OfficerRank to set a separate OfficerClassRank variable at OfficerRank+2. Should I include a subclass rank variable? Is it my place to when PsiRank is already in the game? It would be ideal if all subclasses like Leader or EU's Psionic abilities shared a singular subclass rank variable but I'd be effectively forcing them to be exclusive. To avoid buggy gameplay I'd need to explicitly make them exclusive (which would require more design time). Though I prefer that gameplay-wise it may be over-reaching for a framework and resource. Especially as most subclasses have no real reason to overwrite ranks (such as Psion or Cyborg for example). Alternatively, a subclass framework that attaches itself on top of this release may be ideal but involves setting standards that I'd like to come from consensus. If such a framework were rushed it would probably owe far more to reverse-engineering the Leader Pack than is fair without explicit permission. (JLump, Amineri, you'd need to give me a thumbs-up.)The framework should be released on Nexus and Steam "very soon", with a couple default ranklist versions. At launch I'll have compatibility options for at least the Leader Pack and let other Psi classes specify the PsiNames ranks. Any further potential releases will be separated in the Steam release to preserve user config/.int files.

In response to post #27527609. #27527849, #27527994, #27528224, #27528879, #27528919, #27529224, #27529299, #27529544, #27529909, #27530019, #27530539, #27530744, #27531059, #27532069, #27532379, #27532479, #27532774, #27534654, #27536949, #27537029, #27537364, #27537434, #27537699, #27537784, #27538114, #27539284, #27542064, #27542384 are all replies on the same post. I agree with Taerie that for me, it's somewhat off-putting to have few to no male front page mods to balance the female ones. I don't mind the skimpy clothing per se, but without male stuff to match it certainly gives me the impression this is a bit of a boy's club. It's not like the system cheats for this either, guys and gals often prefer to play dress-up with female characters. This is more a concern for managing people's first, second, and third impressions so they stick around to share and develop their talents. So, thinking productively: "hide adult mods" is pretty narrow, but having a '-skimpy' tag setting as the public default for front page views would be a good test to see if it pulls more repeat users. Better tag integration would allow me to search for armor with meshes for both genders, but without avoiding skimpy. Well I guess I'd better start contributing the sort of things I like in any case. That's the beauty of mods.

It's useful to compare Skyrim with the pillar of the paid 'mod' scene, which is Flight Simulators. Above and beyond the base game, flight sim addons are an industry unto themselves where most paid addons run in Microsoft Flight Simulator 2010 (MSX) as well as its derivitives/competitors. This isn't a perfect metaphor because the sim industry is financially anchored by people who want realism over 'game-design' philosophies. The flight sim market is almost wholly independent of the studios thus far, which has reduced the incentive for creating new versions of the simulators for mass market. There's a reason the last useable Microsoft Sim was 2010. I'm not endorsing Steam by any means and seem to agree with Dark0ne, but flight sims illustrate both the goal of Valve's model and how taking profit out of it discourages even a successful release from being updated or having a sequel. For all its profit potential, Skyrim is the experiment here. The addition of MSX to the workshop by a studio that acquired the rights, with a new version slated for November, brings an a certainty of large profit for Valve from a large and proven community--a community that is often willing to pay dozens of dollars or euro for a single professionally modeled aircraft, a heightmap of a country, or scenery. Skyrim is not MSX, a game is not a simulation, and the communities are wholly different particularly when MSX-derived professional simulators are considered. This doesn't detract from the fact that a large flow of money in amateur and even professional aviation is suddenly right in front of Valve, and they need to have a marketplace installed and tested without risking the community backlash Skyrim was expected to (and is) generating. I can't find statistics on it, but the flight sim market has enough revenue to support the competition of many companies catering to hobbyists. Skyrim is not much different from this as a market, though the average paid-addon-user could be expected to spend less than a simmer. Monetizing (or perhaps never regulating) has created a competitive drive that has made a huge variety of quality addons for sale that took actual investment to make happen, without ending free releases. I can't claim Skyrim will likewise make enough for mod authors to provide customer support as a business would, but incentivising creative output is the same in theory. On the flip side of it, free addons are more than enough if all you want to do is handle an F-22 or Typhoon. Likewise, Skyrim shouldn't get to the point where you're entirely missing something that there's demand for for free--and if I'm wrong, upload it to the Nexus. After this settles down we'll either still have free Skyrim mods on the Nexus, or at worst a high demand for a Skyrim alternative that doesn't make us sick to the stomach to buy addons for. The strong feelings (including the unwarranted anger) at modders making money shows how much this community loves this game. I won't delude myself into thinking that Valve's current model is unsustainable or won't decrease the amount of new free content for a game I love. It very well could. Likewise rather than be neutral about modders getting paid I'm excited for it. Steam, not so much. No matter what, this will likely result in more modder-friendly engines in the future for sandbox rpgs that expect to sell mods, Elder Scrolls or not, and the more broad and accessible the sandbox the more addons will be made for it for sale and for free. I doubt the developers of Long War mod for XCOM: Enemy Within on the Nexus would be able to consider tackling the tremendous effort to make an original alien invasion game after their mod if it was to be (like the mod) free. As with mods goes for games: money incentivizes approaching a market in a way free never can. So I'm off to donate to Long War as soon as I've posted. Valve/Bethesda's approach has major drawbacks, in particular the possibility of paying for free content and thus deincentivizing free resources. For now, I won't pay for a mod on Steam. The best thing the community can do to get more free content is pay for it anyway, including paying for Premium on the Nexus. It takes a bit more thinking than a flat rate purchase, not to mention is harder to track and budget than a subscription, but I'll be donating to modders more now and I encourage you to do the same.