Patching extra functionality into <gamemd.exe>

[DCoder]

Daeda, that's a great idea. Think you can get Fen to come here?

[Marshall]

AI could have a big debate on it.
I think we should follow the principle of the UMP for this patch, which is "it is not a mod". Whilst there are things which clearly need better thought in YR, I think that's better left to the modders.
An AI-only mod is a fine thing but I think it should be up to the user whose AI mod they choose.
In conclusion, I do not think we should modify the AI in this proposed patch.

Regarding names, I think YR Unofficial 1.002 Community Patch [1.002 UCP] has a nice ring to it.
Regarding versions, I believe it should always remain "1.002" and patches could be made available to update it to "1.002, version 2/3/4/etc"
I'll get to work on a shell for a possible installer soon and look into the XWIS server stuff first. (the users can choose which server to connect to - XWIS or EA)

[Renegade]

Hm...I guess that A.I.-thing is a matter of personal preference. About the name though, I don't like the word "Unofficial" there. I think it's kinda included in "Community" - i.e. if it's a community-patch, it's obvious it's not from Westwood. Even more, the name sounds like there was an Official Community Patch as well.

Perhaps we should leave out the YR-version at all? Like, name what is displayed as "1.002" the "YR Community Patch #1" or similar, with "1.003" being the "YR Community Patch #2". Or modifications of your suggestion - the "Unofficial YR 1.002 Patch" or "YR 1.002 Community Patch".

Thinking about it, I don't like the term "Unofficial" in it at all. Not only because it's redundant when "Community" is there, but also because it kinda degrades it. EA abandoned RA2 and YR. There will never be another "real" patch released. So why should ours be the "unofficial" 1.002? As if there'd ever be an official 1.002! I'm therefore suggesting to use the term "Community" in favor of "Unofficial", as it makes equally clear that it's not from WW/EA, but leaves it to the user's opinion whether to take it as the "true" 1.002, or just a cool mod.

About the numbering...I don't see why we shouldn't go up to 1.003. If we make something worth being called the next step after 1.002, why only make it a sub-version of 2? Yet, that's really a minor issue - and, more than everything, something we can think about after we made a 1.002.

EDIT: One more thing: After we're done, we need to run a diff to compare the 1.001 rules with the 1.002 ones and release it along with the patch, so those of us who already have a mod in the works can apply the necessary changes manually. Similar to the UMP's developer kit (or whatever it's called), but also including the new countries, for example, and whatever else we'll have to add.

[Daedalus]

Maybe not everyone wants all new AI, but it was just a suggestion, seeing we could try to fix all.. But maybe AI is indeed just a mod option. However, if this gets to work properly, you can count on me to revive revolution, or atleast its coding.

[~Guest~]

Perhaps we should leave out the YR-version at all? Like, name what is displayed as "1.002" the "YR Community Patch #1" or similar, with "1.003" being the "YR Community Patch #2". Or modifications of your suggestion - the "Unofficial YR 1.002 Patch" or "YR 1.002 Community Patch".

Examples:
"YR Community Patch v0.4" or "YR:CP v0.4"
"YR Community Patch v1.0" or "YR:CP v1.0"
"YR Community Patch v1.1" or "YR:CP v1.1"
"YR Community Patch v1.6" or "YR:CP v1.6"
"YR Community Patch v2.0" or "YR:CP v2.0"
"YR Community Patch v3.0" or "YR:CP v3.0"
"YR Community Patch v4.1" or "YR:CP v4.1"
... etc etc etc... (or only "CP +version")
No new AI, no new maps, no new graphics... only hacked things (mores sides & the full list of things of the "YR 1.001pd Wishlist") & the modders will do the rest of things on mods.

[Renegade]

Actually, I was thinking more along the lines of
"YR Community Patch #1" (CP1)
"YR Community Patch #2" (CP2)
"YR Community Patch #3" (CP3)
...and so forth.

[Blade]

Okay, lets just think about what is needed to put togther an open source collaborative project and what we would want and not want to include in 'Community Patch #1: YR v1.002'.

Whats needed:

Some kind of version control, someone who is going to maintain the master build of the working patch in progress.

A file repository, probably an FTP with various levels of access. Need at least 2 levels, one that provides read only access to all individual files needed to build the patch as approved by content moderators and one that provides a place to upload modified files for approval. This lets people wanting to contribute or improve one aspect of the patch download only the files that pertain to that aspect and not have to pick the patch apart.

Moderators to look over and approve submissions of assets (UMP is likely to have majority of needed code changes initially), make sure they are of comparable quality to WW assets.

What should be included:

Patches to the exe that fix bugs or re-activate/add logic not normally in the game.

Art assets and code that demonstrate new features working, even if they are not active in the actual patch itself (kind of like leftover code and assets that WW left in there).

Support for assault game mode

A few new maps to show of any re-enabled terrain logic (conversions of TS maps maybe?)

TX terrain pack maybe??

What should be left out:

The assault map packs themselves (leave them as an optional addon).

Any tinkering with the AI beyond fixing a few known bugs. Certainly not implementing any of the AI's that use fake units/buildings to improve the AI's savvy.

New content beyond demo stuff that isn't normally available...leave that to other mods to provide.


Edit:
Also, I think discussion of a patch using any future modified exe should be moved to another discussion and leave this for discussing the actual exe mods themselves. Also, its probably not worth worrying about starting to get this together until there has been a lot more added to the exe to actually make stuff to use.

[Marshall]

I agree. We need a new thread for the CP - I've made one in this same subforum [ra2/yr editing]
Seeing as I'm already posting here anyway, I think "YR 1.002 Community Patch version X.X" works well, "YRCP" for short.

[pd]

*news fanfare*
BREAKING NEWS:

I finally managed to expand the exe file by adding a code section which can be called by the other code section and which can have references to the data!!
Of course, I tested it.
The game runs like normal and the new code section (called ".pd" ) is fully functional.
The exe's now 4.65MB and gives me 64 Kilobytes room for new code (more than 20,000 instructions!!!

I also had a short look on the InfDeaths again... I think I know how to do it.
I didn't do that last night because I was quite tired when I was ready with the expanding stuff...

That Community Patch is a great idea and gives me some motivation I think.
I never did anything for the community although I'm modding RA2 and YR for about 4 years now... and now it's time to do something.

[Renegade]

Dude...I love you. Seriously. You give me a reason to mod again.

[Blade]

*news fanfare*
BREAKING NEWS:

I finally managed to expand the exe file by adding a code section which can be called by the other code section and which can have references to the data!!
Of course, I tested it.
The game runs like normal and the new code section (called ".pd" ) is fully functional.
The exe's now 4.65MB and gives me 64 Kilobytes room for new code (more than 20,000 instructions!!!)

I also had a short look on the InfDeaths again... I think I know how to do it.
I didn't do that last night because I was quite tired when I was ready with the expanding stuff...

That Community Patch is a great idea and gives me some motivation I think.
I never did anything for the community although I'm modding RA2 and YR for about 4 years now... and now it's time to do something.

PD, I've just had a thought about when you asked if you needed to get FireStorm expansion to TS as well as TS itself...you don't need to, the last patch for TS added all the firestorm logic into the same executable, you just need to merge the firestrm.ini into the normal rules.ini and have the expand01.mix from FireStorm. It won't let you play the missions, but it will let you use all the new stuff in skirmish to see what all the additional logic is about.

[pd]

OK I'll get TS soon
Then I'll play it awhile and then I'll continue working.

Maybe I manage to do the InfDeahts before I get it, that'd be cool.

I've been thinking of a new side...
Well... I got enough graphics (my collection ) for buildings, units etc, but what's about the GUI and especially the EVA? :o

I know there's one @ YR Argentina but it sucks :unsure:

[Marshall]

If I may briefly go back to the 'new countries' patch, I think it might be a good idea to just include 2 new generic country slots that replace GDI and Nod

[NewCountry1]
...

[NewCountry2]
...

That way, it's simple for modders to see and use, and avoids breaking of any sp campaign triggers - making it very useful for the CP that won't add any new countries and wants to keep the sp campaigns in tact. Unless you can add the new countries to the end of the list (and leave GDI and Nod alone). Blade would know more about what should be done.


With regard to InfDeaths, how many do you plan to add?

Again, I think something along the lines of
InfantryNewDeath11=...
InfantryNewDeath12=...
InfantryNewDeath13=...
InfantryNewDeath14=...
and so on

[pd]

So modders decide if they activate them?
Then I'd have to make a [General]-entry "PlayableCountries=<number>" with a specific maximum, because when starting a Skirmish game, the new countries would be picked by random maybe, even if they aren't used by the modders.
A new rulesmd tag would fix that...

InfDeaths look like this:

InfantryNuked=NUKEDIE
NewInfDeath1=...
NewInfDeath2=...
...

Just very similar to your thought

[Marshall]

Multiplay=no on, say, [Russia] prevents Russia from appearing in the choose-your-country list and prevents it from being picked at random.

As such, I would suggest a basic set of country data for [NewCountryX] with Multiplay=no and let modders know what they need to do to activate the new country(s).


For InfDeaths, it doesn't make much difference, but the only reason I suggested '11/12/13/14' rather than '1/2/3/4' is that the number corresponds to the InfDeath index number. Like I said it's pretty obvious to even the most simple modder, regardless of how you name the tags.