Solving the Loadgame AI Bug - A suggested approach

[Sundjata Keita]

This is way over my head but if someone can pull it off I will not only be impressed but dissapointed that some of the great modders here have not thought of it already Good luck to anyone who trys.

[The_Mark]

Sounds good, and doable if one knows what he's doing. I don't, that's for sure.

Just how resource-consuming is the operation? [SPECULATION] Could it be used, for example, in the battle mode without (serious) slowdowns? If it could be used then, couldn't someone make a proggy that'll use the "hibernate file" and based on that it'd construct new orders to AI according to the situation in battle. We could have a proper AI with this.[/SPECULATION]

At least the siege bug could be addressed with this, dunno about battle AI.

[The_Mark]

some of the great modders here have not thought of it already

I (well, I'm not a great modder, but) actually suggested something like that, but for the battle AI and without meddling with RAM.

[Kull]

OK, I've spent pretty much the whole day googling, and am only slightly smarter for the effort. But it does appear the "RAM Save Game" option can be implemented in 4 different ways:

1) Basic Windows Hibernation: As discussed above, this can be implemented easily - and it works - but the downside is you can NEVER shut down RTR. Just doesn't seem to be a realistic solution.

2) Application Hibernation: Imagine being able to hibernate only the RTR Application? That sounded like a great idea, but others have considered the issue and consider it to be extremely difficult (perhaps even impossible) to implement in the Windows environment. See this link for details (the techno-speak is truly impressive, if borderline unintelligible for the average non-geek):
http://blogs.msdn.com/oldnewthing/ar...20/116749.aspx

3) Specialized RTR RAM Copy/Load Application: My original idea, but someone would have to code this from scratch. May be doable, but the magnitude and quantity of the unknowns are.....unknown.

4) Modified Windows Hibernation: Every time you hibernate, Windows creates a file called "hiberfil.sys" in the root directory of the C: drive. When you restart windows, it automatically launches this file. So far so good. But we need additional custom capability:
a) The ability to boot up from a hibernation file at any time (the absolute, bar none, super critical, MUST HAVE!)
b) Create the hibernation file without shutting down (nice to have)
c) Create multiple hibernation copies of the hibernation file and boot up the one you choose (nice to have)

Item 4a is the current focus of my research, and so far it's been "no joy". Here's why it's important. Windows only launches from the hibernation file if that was the method used to close down Windows. I can't seem to find any way to launch from the hibernation file if Windows experienced any other form of shutdown. Which means we can't launch RTR "hibernation saves" at our discretion. Which is the whole point!

So, if anyone can find a way to do this, PLEASE pass it along!

**********************************************

And shortly after making this post, I may have found the answer - it's called "Hibernate Once, Resume Many", or HORM for short. Here's a link which provides more details:

http://blogs.msdn.com/astebner/archi...01/273462.aspx

and the research continues.......

**********************************************

My enthusiasm may have been premature. HORM is pretty complicated, and doesn't seem to specifically address our need. So the net is cast a little wider......

[Sundjata Keita]

Very good work Kull but to be honest I can't see hibernation working, did you understand any of the site about application hibernation? Hibernation is basically just a way of closing and restoring a program, this would be near impossible to modify the restore. Also hibernation leads to bugs, serious bugs and it will not work on all systems. I think our best bet would be with option 3 or some other option if there is one. Anyway good luck with it, if you can get this to work it will be a great feat.

[Crandaeolon]

In theory, you could use Virtual PC on a WinXP Pro host to create a "guest" operating system (for example, XP Home that is used only to play RTW) that you could hibernate / restore without affecting the host OS. It would, of course, be limited to playing a single campaign, effectively running RTW "all the time", but with the convenience of shutting it down when needed.

You could even create multiple virtual operating systems for playing several campaigns at once, but that'd take a corresponding increase in configuration work and hard drive space for multiple installations of OSes and Rome.

This would be a very hardcore approach, costing a lot of $$, time and HD space... and it would probably have its own problems, such as affecting performance. But... you could eliminate the bug! ...maybe.

Edit: I'll stress once more that this is just speculation. I have no real idea if it would work or not, and most likely it wouldn't be worth the expenses, time, and grief.

Edit 2: Dug this up from Micro$oft.

Users switch between operating systems as easily as they switch between applications. They simply click the window containing the virtual machine. They can pause individual virtual machines so they stop using CPU cycles on the physical computer. They can also save virtual machines to disk and restore them at a later time. The restoration process normally takes a few seconds—much faster than restarting the guest operating system.

Sounds like it would work, then. Who has the money?

Edit 3 (last edit, I promise ): Link to the product overview.

http://www.microsoft.com/windows/vir...rview2004.mspx

[Kull]

Edit Comment: I'll keep the post intact, but the Item#1 "Good News" has turned out to be unworkable - at least for now (details in the subsequent post). Likewise with the "my work here is done" comments at the bottom. Sadly no.....the search continues......

***********************************

Some updates to report....first the good news!

1) A solution that will work! - At this point I am prepared to say that there is one "workable" solution that doesn't necessarily involve added cost. It is complicated, and thus most folks will probably opt out, but it IS the solution I'll be implementing, since my personal frustration with this bug had caused me to abandon RTW. And the answer is?

Dual Boot O/S - I can see the wincing from here! The idea is to establish a dual boot system, the second of which is ultra-clean and dedicated purely to RTW. In essence, this is the "Option #1" hibernate solution, but it's now workable since the second O/S is used only for RTW, and all entry into and out of your game is achieved entirely by hibernation. For everything else you do, stick with your primary O/S, and the existence of the additional O/S costs you nothing more than hard disk space and the time to set it up.

2) Modified Windows Hibernation is Dead (or at least on life support) - Sadly, there seem to be some major impediments to "Option #4". I posted this issue on a Tech board, and received several responses from senior guys who truly seemed to know what they were talking about. Two were just flat out horrified, using phrases like "severe trauma" and "potentially extremely dangerous". In a nutshell, here's the problem: The hibernation file contains all the program data that was loaded into RAM at one point in time - and as we all know, things change. You can install a patch, reset the clock for daylight savings time, move a folder or two, etc. And that's fine, but if you boot up a hibernation file created BEFORE those changes occurred......well, {screetch}, {ca-RASHH}!! One guy did like the concept, and provided links to two commercial programs that will allow you to perform a COMPLETE system restore, so potentially this concept is still workable. But given the relative ease of the dual-boot option, I can't imagine going any further down this road. If you're interested in the two programs (Deep Freeze and Clean Slate), or simply want to check out my "taken to the woodshed" experience, here's the Tech Forum link:
http://forums.techguy.org/showthread...27#post2503527

3) The Virtual Machine: Many thanks to Crandaelon for adding this possibility to the list. I did some footwork, and discovered an additional program that does the same thing (VMware), and - better yet - found an article that independently evaluates them, one against the other:
http://arstechnica.com/reviews/apps/vm.ars/1

For those who may be interested in this option, here are some things to keep in mind:
- Virtual Machines share the same resources with your primary O/S. That means you're probably going to need a LOT of RAM!
- The programs aren't cheap. The article listed Virtual PC at $149 and VMware at $189.
- As Crandaelon noted, there's no guarantee that RTW will perform in this environment. The product testers in the above article tried to run two DOS games, and both wouldn't function. Maybe that's just DOS, but the caution flag is hereby raised.

So....where does that leave us? My personal quest for a solution to the Loadgame AI bug has - at least for now - come to a "successful conclusion" (the proof, of course, is in the pudding!) The dual-boot hibernation concept seems like an effective option, and so I'll give that a go.

That said, I would hope others will continue the search for additional solutions, and certainly I encourage serious coders to take a hard look at whether it's possible to build a RAM Save application for RTW.