ModEnc talk:Migration to structured data and forms

ModEnc:Migration_to_structured_data_and_forms#Possible_Solutions

• I personally support writing version migration information in the main text. The form in the template is not convenient for handling this function. For example, Deliver.Buildups was added in Ares version 0.2 but removed in version 0.C. The obsolete tag is not convenient for fully conveying this information. According to my editing habits, I would use |extver=<i>0.2-0.B</i>.

ModEnc:Migration_to_structured_data_and_forms#Multiple_Definitions_of_the_Same_Flag

• I am slightly interested in the first option, but how to design the navigation scheme for flags with the same name still needs discussion, and it will bring a huge workload, especially since other references outside ModEnc are likely unable to be changed by us, and it has a very broad impact on all content using the existing linking method. However, if we choose this approach, I have some ideas about the page structure for flags:
  • We can use an unordered list like the one on the Tiberium page on the main flag page(/Image), and then one of the entries links to /Image/On_Animations_and_other_objects_in_art(md).ini and move the content of that section into this page.
    • This way, some old internal links can simply replace the # in the original text with / to point to the new page. Generally, links that point to such polysemous flags and use # to point to specific sections are segmented by usage under different categories, which exactly matches our method of splitting pages by category.
  • And if we want, we can still use the syntax like {{:Image/On_Animations_and_other_objects_in_art(md).ini}} on /Image to display that content on /Image, but editing them would need to be done on the pages storing these wikitexts, which are precisely the pages dedicated to specific categories. This way, we can maintain compatibility with old query habits and link jumping methods without any processing from the linking end.
    • Perhaps we can directly think about the page splitting issue based on the {{:<pagename>}} function? It can coordinate well with Form: when splitting by category.
• If we choose the third option, then perhaps we can add a marker or automatic detection to prevent these pages from enabling Edit with form and prompt as unavailable when Form: is filled with the page name.

ModEnc:Migration_to_structured_data_and_forms#Released_Games

• MaxDamage was an error, and now it has been corrected. Unload is not a flag, but rather the name of a Mission, used as a fixed section name in the ini file. It actually should not have a page to serve as a flag description.

ModEnc:Migration_to_structured_data_and_forms#Open_Source_Games_and_Clones

• For this kind of late-stage open-source situation, I think maintaining different information for different forks is a very difficult task, and we cannot avoid the situation where two different forks use the same name flag for different features, which has already occurred in the Ares-clones mentioned below. Of course, if it's just about adding extensions to the original RA flags in subsequent projects, and having a documentation website maintained by those forks themselves (generally, if it's publicly released, it's unlikely not to have one) for us to link to, then this is achievable.

ModEnc:Migration_to_structured_data_and_forms#Mods

• I don't understand why we, as a Modding Encyclopedia, need to record too much information about mod works. If it's a patch-style mod like UMP or YRStandard-INI that can be used by any beginner after getting started, based on them instead of vanilla for subsequent work, then of course it's acceptable, and in fact, I might be more inclined to view them as modding development tools that can be independently released as mods. But for already released, complete works directly aimed at end players, perhaps only a list of more famous, overall excellent, or particularly outstanding in some aspect mods and their links is needed to provide a learning reference. However, as long as such data is organized, there will inevitably be controversial issues regarding ranking, and overall, I think recording this information is not very necessary.
• Additionally, there aren't many LaunchBase users anymore, most mods use the XNA CNCNet Client, and many mods don't have their own website but may simply create a page on ModDB to place information, and if wanting to complete the file localization steps required for download, it requires both the downloader and the publisher to adhere to the same standard, which might be somewhat difficult in practice.

Then again...are there enough people left who play more than one mod?

• As time passes, overall, the community seems to be continuously shrinking, although I hope this is just my personal illusion. However, even if someone plays multiple mods simultaneously, due to differences in clients and custom extensions among different mods, especially since modern mods are often large in size, they are no longer as easy to organize as the predecessor works from the era of RockPatch making -MOD command lines, and players usually still choose to install mods in multiple directories using different Yuri's Revenge copies and play the game.

---

~ DeathFish (talk) 12:43, 23 September 2025 (UTC)

As usual, it seems to be just the two of us.

As this is all there is in feedback after two months, let's figure it out between us and then move forward:

Version association: Going with "obsolete" was the idea because the current flag template contains the XXobsolete parameters. Having obsolete as a parameter would make it simple to convert existing markers of ra2obsolete=yes to the new system.

I personally don't mind having a pair of AvailableFrom/AvailableUntil or FirstVersion/LastVersion parameters, but that is not a good fit for the use case of ra2obsolete=yes - the concept of "parsed, but not used" cannot be expressed by a version range.

Fundamentally, there's nothing stopping us from having three fields, but I'm wondering if it would work to just change obsolete from a Boolean to a Version: For the case of ra2obsolete=yes, you would set RA2|Version=1.000|Obsolete=1.000, and for your example of Deliver.Buildups, you would set Ares|Version=0.2|Obsolete=0.B. We could then do a tiny check and either display a range ("Available in Ares from version 0.2 to version 0.B") or, if Version equals Obsolete, mark the flag as obsolete as before ("This flag is parsed in RA2 version 1.000 but obsolete.").

What do you think?

(If we have cases where this happened, we could even add a Deprecated parameter if any flags were softly phased out.)

Multiflags: When I wrote the proposal, I imagined Wikipedia-style disambiguation pages (similar to Tiberium), but transclusion is absolutely a workable solution to maintain the previous page structure and keep links working as expected. The only change I propose is using proper pages: Image (art.ini) should stand independently next to Image (rules.ini) and Image (Tiberiums), as each of these incarnations of Image is a flag on its own right and deserves to have an independent page.

Truthfully, though, I don't know how the structured data storage will react to a transclusion of the templates. We'll have to test that out.

FOSS game documentation: I think "difficult" is relative here. Fundamentally, it's no more difficult than the situations where we currently have "In Tiberian Sun" and "In Red Alert 2/Yuri's Revenge" sections on flag pages. Or, as outlined above, possible future pages like "Foo (Ares)" and "Foo (HyperPatch)". The difficulty is mostly a volume-of-work thing, imo. It's more a question of whether we want to open ModEnc to the possibility of adding such documentation, and not one of "should we actively go and try to document everything ourselves?".

Mod listings: I do think it is reasonable for a modding encyclopedia to have information about mods. ;) And as pointed out, we have always had entries for mods. The proposed change is not listing mods for the first time, the proposed change is to create a more complete list of relevant/active mods based on what's left. The idea being that the concerns that we both brought up are valid, but much less likely to become a problem in a community where it's only the two of us dealing with the listing.

To put it differently: In order for there to be a huge controversy about who's listed on ModEnc and who is not, there would first have to be enough active mods to have to cut some from the list, then there would have to be enough active mod users to even notice the mod isn't listed here, then there would have to be enough fanatics to even interact with ModEnc about it, and then, honestly: If they're active enough to maintain the page here, I wouldn't mind it being here. I'd rather have an actively maintained page for a small mod than an unmaintained one for a big mod.

To put it differently differently: The lethargic general populace of the community won't even notice, and enthusiastic users coming here and actively maintaining mod pages would be an improvement.

So...yes, those concerns exist in theory, but: Is there enough community left that controversy is even probable?

I mean...two months. I have this page linked on the front page. And you're the only one who reacted.

People keep pretending that there's this large, super-enthusiastic ModEnc shadow community, but the reality is: It's you, me, and Testid in his talk page prison.

Who's going to start giant controversies about which mods we dedicate three lines of text to?

~ Renegade (SysOp) 18:52, 18 November 2025 (UTC)

Availability and Existence

You mentioned "parsed, but not used", which I think actually reveals another issue: the current Flag Template has a blurry distinction between existence and availability. Since Deliver.Buildups is only an Ares-added flag, let me give a new example. For Paranoid, which is considered no longer effective in Red Alert 2 version 1.004 (assuming all the current page content is correct for now), since it still exists in gamemd.exe, I would mark it as yr=yes. Then contradictory issues arise:

1. Is it effective in Red Alert 2? Yes, at least in the earlier versions → so it should not have ra2obsolete=yes;
2. Is it in Ares? Because Ares is an extension of Yuri's Revenge, and this flag exists in Yuri's Revenge, regardless of whether it is effective → so it has ares=yes;
3. What about the obsolete information? It is placed in the Bugs section of the main text.

Ultimately, people need to read to the very bottom of the page to realize: Ah! This flag has been non-functional since Red Alert 2 version 1.004! Yet they can see it has the yr=yes and ares=yes mark in the Flag Template :/

Therefore, for the new editing approach, I think we need a solution that clearly expresses "availability" and "existence".

• For "existence": the original part is already good, but do we have any necessity to retain tags like ares=yes and hpflag=yes? For Ares-added flags, having a dedicated aresflag=yes that adds a prominent banner. As for other flags, I only feel that ares=yes has the purpose of conveying to users that "Ares restored this logic" for some flags that existed from Tiberian Sun to Red Alert 2 but were removed in Yuri's Revenge and then Ares readded them. However, I think describing this in the References section of the main text and linking to Ares documentation is sufficient.
• For "availability", it might be in the form of <game(from)> <version(from)> - <game(to)> <version(to)>? This seems cleaner and easier to edit and read, but before implementation, we need to confirm the feasibility:
  1. At least for the main part we work on, except for the fork between Firestorm and Red Alert 2, the engine of this series is basically continuously evolving;
  2. For extensions like Ares, using the form "Ares 0.2 - Ares 0.B" is also supported;
  3. And this matches the format you mentioned: "this flag is available in X as of version Y";
  • However, it is still uncertain whether there are special cases in the gap between the time nodes Tiberian Sun→Red Alert 2 and Tiberian Sun→Firestorm, I need to specifically investigate this.

However, there might be some technical implementation issues? Can the wiki-bot retrieve tags like tsobsolete, ra2obsolete and convert them to the above form? How to handle two forms in parallel? If Vinifera and Ares add the same flags, how to handle that? It would be great if you can confirm that these are not problems. :)

Multiflags

It sounds like it's just a naming issue for the included pages. /Image/On_Animations_and_other_objects_in_art(md).ini is not a good example; it is indeed too ugly. However, I see that you seem to have another layer of meaning. Are you inclined to have each usage of the Image page use an independent main page, rather than the subpage form like Image/Tiberiums? I propose this method because it automatically adds a link to the parent page Image (the main page, which includes all usages) in the upper left corner of the page, and in search results, it can clearly show the parallel relationship between these pages (Since it is a subpage, there is no need to constantly remember to keep the same prefix when creating a separate page—it naturally possesses it). Which one do you think is better?

Additionally, my original intention was to distinguish based on the type of flag used, but you mentioned that Image/rules.ini and Image/art.ini are indeed reasonable. For example, for TechnoType, the uses of the Image flag in rules and art are indeed different. That is to say, there are indeed a few pages that have differences across different INI files and also have differences for different types of users. Do you have any good suggestions? Although since such cases are few, even if they are broken down into more numerous pieces, it is acceptable.

Regarding structured data, the usage I mentioned is to use structured data on each included page, while the main page itself will only reference other pages or add some overview content. Therefore, the main page itself will not use structured data, and correspondingly, it should allow being prohibited from Edit with form through some marker. As for the structured data on subpages, they are still stored via wikitext in the end, so being included and displayed on the main page should theoretically not cause problems, unless multiple templates containing structured data are placed side by side on the same page and interfere with each other.

FOSS game documentation

Hmmm... I don't think I understand what kind of page you want to create and what function it should serve. In my opinion, each project has its own documentation, and for further extensions of CC1/RA, it would be more convenient to view them directly in the Forks network of EA's official GitHub repository. Can you elaborate on that?

Mod listings

This is just risk management. Although there are very few people willing to participate and contribute (even Testid123 is addicted to his prison life and unwilling to come out), we definitely still have some traffic, right? Just like when Testid123 vandalized the page, very few people came here to maintain or protest, but his deeds have long been spread (but this also shows that most people prefer to leave the problems there and watch rather than participate, whether it's contributing knowledge or other things).

Skipping that question, what kind of page should we create? Previously, I mentioned that we could make a table of known completed mods, but according to the content on the main page, what you plan seems to be just listing mods.

1. Is it similar to the old way where each mod is created as a separate page?
   • I see that they are currently organized through Category:Mods and Patches (but this is obviously not a dedicated mod content integration page, at least it also includes Patches content).
   • Or do you want to create a page for Ares-based mods similar to List of mods using Rock Patch?
2. Additionally, does 'what's left' refer to the mods that are currently not listed?

Some quite exquisite mods have only internal testing or external promotion so far, but years or even over a decade have passed without official release (yet we know the works are still in development), such as Global Crisis and EnemyAtTheGates V, should we deal with them?

~ DeathFish (talk) 18:00, 20 November 2025 (UTC)