Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Compatibility: changes that affect unmodded game
#4
(12.09.2008, 21:18:45)DCoder Wrote: 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 Bang head against wall" 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.
[Image: jsfml.png]
Reply


Messages In This Thread
RE: Compatibility: changes that affect unmodded game - by pd - 13.09.2008, 08:16:00



Users browsing this thread: 1 Guest(s)