Compatibility: changes that affect unmodded game

[DCoder]

How should those changes be handled?

Examples of things I'm talking about:

• Snow.ini median fix back in RP1.
  
• Ticking Ivan Bomb image has 13 frames, the game was hardcoded to ignore the last one and only operate on the first dozen. When I made the image customizable (yep, works already), I didn't take that into account. I can rewrite the code to ignore the last frame, sure, but making sure that only happens to the default bombcurs.shp image and not to other ones is reaching to the "fixing idiotic bugs that are not my fault in the first place " territory...
  
• I just fixed a bug where all Rad Beams and Sonic/Magnetic Waves are drawn from PrimaryFireFLH regardless of which weapon slot actually fired them. It's a real bug, but fixing it revealed WW's laziness: Magnetron has no SecondaryFireFLH set! Meaning, with the fix, its secondary (anti-structure) wave gets drawn from a silly location.
  
• I don't yet know how the game decides which transport ejects its passengers on destruction and which doesn't. I have written code to conditionally eject/paradrop passengers as well as the pilot, but I don't know what default values to use for the "can eject passengers" flag.

Thoughts?

[Tempest]

The SecondaryFLH thingy works with Electric Bolts (I had a tank that fires a 135mm at ground enemies and an Electric bolt at air targets.. It fired them from the right FLHs..)

I think the Passenger ejection thingy should default to yes (coz a majority of aircraft and vehicles should be able to eject them)

You can put warnings in MDKs and Installers (if any) or the Download Pages so that whoever is about to play Ares will be aware of this.. A modder can easily change his files to be compatible with Ares, others should be able to download the files necessary for compatibility (unmodded files with just the necessary fixes)

[Marshall]

Ares is primarily to enhance the options available to mods - so any fixes like those you mentioned are welcome. If they affect the unmodded game then it doesn't matter because the mod author will correct as appropriate for their mod.

However, it is vital that such changes are documented, preferably in their own section for ease of reference.

[pd]

How should those changes be handled?

Examples of things I'm talking about:

• Snow.ini median fix back in RP1.
  
• Ticking Ivan Bomb image has 13 frames, the game was hardcoded to ignore the last one and only operate on the first dozen. When I made the image customizable (yep, works already), I didn't take that into account. I can rewrite the code to ignore the last frame, sure, but making sure that only happens to the default bombcurs.shp image and not to other ones is reaching to the "fixing idiotic bugs that are not my fault in the first place " territory...
  
• I just fixed a bug where all Rad Beams and Sonic/Magnetic Waves are drawn from PrimaryFireFLH regardless of which weapon slot actually fired them. It's a real bug, but fixing it revealed WW's laziness: Magnetron has no SecondaryFireFLH set! Meaning, with the fix, its secondary (anti-structure) wave gets drawn from a silly location.
  
• I don't yet know how the game decides which transport ejects its passengers on destruction and which doesn't. I have written code to conditionally eject/paradrop passengers as well as the pilot, but I don't know what default values to use for the "can eject passengers" flag.

Thoughts?

Additionally, there's the ParaDrop cursor that has 10 frames in the SHA but doesn't animate at all ingame.

I think we should include the new ini files in the release on which modders should build their mods, but document all changes we make, so already existing mods can simply add these modifications.

[Marshall]

I think we should include the new ini files in the release on which modders should build their mods, but document all changes we make, so already existing mods can simply add these modifications.

Sounds like a good idea, but bear in mind the UMP DevPack which also includes 'fixed' INIs. Can I request that Ares-fixed INIs are built on the existing UMP-fixed INIs?

The UMP could actually include a section on the Ares changes and the fixed Ares INIs alongside the plain UMP INIs, which would mean you wouldn't have to release a separate pack for Ares - the Ares documentation can remain as a single file and/or on ModEnc.

[Tempest]

Yeah.. We should do that.. (all of it )..

[DCoder]

Yea, providing improved INI files sounds like the best idea. Thanks for the input.

[Tempest]

Are INI files the only things that may need changing? I mean, like UMP, there may be a need for other files (such as SHP files) to be changed in order to work better with Ares (at least in the future). Or, is that out of the question?

[DCoder]

The Ivan Bomb image already needs fixing, so yes, I imagine more files will follow. I guess they will need to be tracked on SVN as well...

[Blade]

Isn't this getting more into the v1.002 patch territory that has been discussed a few times since rockpatch started? Not that I'm complaining if that is the situation, I was always for that, just an observation, thats all.

[Marshall]

Not quite, I think the difficulties that have been discussed before with deploying a combined community patch are too preventative.

I believe the UMP DevPack is the way to go for mod authors, and the UMP mod itself can have an Ares version that includes the neccessary files to support the Ares fixes.