Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[GreatWyrmGold]

why can't you just put the rest of the world into fortress mode scale when using fortress mode? if it takes you a week to walk to the edge of a map it should take several months to travel to other forts or cities. so if you send out an army you could check travel reports while fiddling around with your fortress until they arrive.

Because that would essentially slow down the rest of the world. If caravans had to walk from the mountainhome to your fortress at the same speed as your dwarves, it might take decades or even centuries before they arrived.

Holy carp, why do you exaggerate? It takes my dwarves less than a day to cross the fortress. At that rate...assume 1.5 days per map tile to be nice to Silver...that's 24 per region tile...crossing a Pocket world would take only maybe a single year, and that's if you're far away and taking a liberal estimate of time. If you settled the opposite side of a big world, it might take a decade or two to get a caravan to you, but what are you expecting, and how long do you think it would have taken a bunch of heavily-laden wagons to travel from somewhere in Africa to China in the 1300s?

Whenever damage is done to a dwarf is a bad trigger too, because that means whatever enemy you have is already in the fort, giving you no time to prepare, as well as a series of other problems.

In any case, enemies entering the map would either move at fortress mode speed until a mode change is triggered, so you can see them coming. Whenever they're at crisis mode speed, that means at least some of your dwarves are too.

So...let's see now. Whenever an enemy sees a dwarf or vise versa...dude, that's like always until you get your dwarves underground, and even longer if you have grazing animals.

Triggers: If "whenever a dwarf panics/sees an enemy" is a bad trigger, we need to scrap that idea.

Please elaborate. Enemy recognition is a rather specific requirement, and one that will have to be adressed sooner or later anyway.

Wild animals are enemies. Wild animals are everywhere. Why does it need to be addressed, if we're not even sure if this idea should be added at all?

Having messengers force slow-mode until they reach your guards is dumb; how do you define guards, and what if you're not protected by them and rather by, say, some kind of trap/s?

Anyone with some kind of official capacity would suffice. If you choose to bunker in and kill anyone that approaches with traps, that's a choice with consequences.

So, now I need to wait until the messenger reaches my mayor to get back to fast-time and get some stuff done? Or do you mean actual military, and fail to realize the number of challenges and playstyles that do without for whatever reason?

Can you not see issues with marking critters as unimportant at will?

It's an optional measure, not essential. Since it's completely under control of the player, I can't see what would cause problems for him: after all, he would forego the option to have precise controls.

"This guy's not important, I can ignore him." This is a completely arbitrary thing. Sorry, but just because the player says it's not important doesn't mean it's not. Soon you'll need to get back to the fast-mode combat problem that your idea has.

And why is "dwarves handle time-sensitive issues" not a good way for fast responses to happen when most things that would require them autopause the game? And of course it's vague--there's at least a thousand situations it would apply to.

They have to recognize time-sensitive issues, they have to figure what is better in that specific situation, and given their walking speed, there's not that much more efficiency you can wring out of them. And if that was no problem, why wouldn't they always do things the more efficient way?

They should always do things the more efficient way, that's my point! And what do you mean by "you can only wring so much efficiency out of them?" If dwarves suck so much at handling time-sensitive issues that you want Toady to spend years rewriting the basic engine, then obviously it can be improved. Are dwarves as efficient as they can be or is there a reason for your idea?

Games are not about forcing you to do stuff, they're about letting you do stuff within limits. By your logic, the best game would be an awesome but non-interactive one, whic isn't really a game at all.

Then yours would be an editor, nothing more. The player has to face some constraints, otherwise he would reach his goals as soon as he had formulated them. In any case, I'm not forcing the player to do anything, just as the current version of the game isn't forcing the player to do anything but to follow the calendar and timing rules used in the game. Tell me what I force the player to do.

Hm...so you're saying that forcing the player to play 72 times slower isn't anything? Okay, clearly we aren't thinking the same things here. I'm saying that playing that slow would suck, because presumably it would take 72 times as much real-world time to do the same stuff in dwarf-time. It might be neat to go to slow-mode sometimes to watch the dwarves run about, but usually I'd rather have a fortress that's getting stuff done. Therefore, random points of slow-mode (when I'm likely watching something other than dwarven life) would be BAD, in my book.

If tere is the slightest difference between the modes, as far as anything goes, it will be abused. It's not like "minimising haling distances improves efficiency," or even "building this complicated device improves efficiency," but "oressing this button improves efficiency."

Disagree, there's no button to be pressed and there are no efficiency differences between modes.

Yea, yes, so you say. Everything has to be PERFECT for there to be no efficiency difference--and if there isn't, then dwarves can handle every-second-counts situations as well in fast-mode as in slow. And how is there no button? You only go to slow-mode when the game tells you to, in those time-vital situations? Then why the *&$% do we need to include a slow-mode at all?

I think that reaching the edge of the territory you control taking a week isn't too unreasonable, considering that you'd have to be pretty damn far away in DF for it to take a week. Dwarves aren't as slow as you all seem to think--a muner can dig many tiles a day, and I don't think it takes multiple days to build something in a workshop, barring huge haling distances.

They walk slowly. Too slow for soldiers, messengers and even traders. As said before, economic activity can be abstracted without much problems: the military and diplomatic manoeuvers are where the problems lie.

I have pointed out time and time again that it does not take a freakin' week to walk down the hall in Fortress Mode. I have crunched the numbers with some estimates that were VERY generous to your cause, and there is anyways no reason that the merchants couldn't run at one abstracted rate more appropriate for their relevance to gameplay and to realism while the fortress runs at a different abstracted rate that optimizes gameplay enjoyability. Some sacrifices must be made.

And one last question: Why is the slow mode needed? Couldn't we accelerate the working and consuming speeds a la the suggested fast modes and leave out all of the issues, obvious and not, which would occur with such a fundamental change to the Fortress Mode engine?

The fast modes, AFAI've seen, contain a mass of arbitrary production changes: that will make abuse inevitable, balancing becomes an enduring headache for each update, and it breaks suspension of disbelief much more than a mere time speed change for some dwarves in specific, predictable situations. In addition the game derives much of its charm from the fact that every craftsman has to walk a very specific path to a specific storeroom to pick up specific items. Lastly, fortress mode already is a kind of fast mode, because it minimizes working/sleeping speeds to make time for dwarves walking around, and only shows a limited number of work/eat/sleep cycles instead of one for every day of the year.

Arbitrary production changes...that are actually just like what we have now, only changed to better fit the model required by their suggestions. Very arbitrary. And "predictable situations?" "Every time a dwarf sees a crreature it deems an enemy" might be predictable, if only due to frequency, cut "A messenger runs from a nearby town" is nowhere NEAR predictable (or at least shouldn't be; if the nearby human hamlet has a goblin attack every 17th of Galena, there's a bigger issue than it taking a week to get from the edge of the dwarves' eyesight to the mayor's office). "In addition the game derives much of its charm from the fact that every craftsman has to walk a very specific path to a specific storeroom to pick up specific items." Erm, even taking that as true (for me, it's more the stories and the structures I make), what relevance does it have to do with this discussion? And of course Fortress Mode is like the fast-mode, the suggestion was for a slow-mode!

edit: ninja'd by Andeerz
>This is a game of emergent behavior; little events earlier on can have profound, often unforeseen effects down the line

Then I wonder why you would abstract them further away?

Huh?

>And I think it would be really silly to introduce such a break in continuity of movement... Combat would seem to me as if everyone except for the combatants are statues.

Pretty much, so their actions stay congruent with the calendar, their productivity remains the same the whole year, while the dwarves that need it get their fast action. They become combatants too when threatened and flee at fast speed.

Wow, this is really...I'd come up with a rebuttal, but there's a perfectly good one in the post you're replying to.

>And how to define someone as a "combatant" or "time sensitive" or whatever in a way that doesn't seem clunky and kludged-in and possibly game-breaking seems impossible to me.

Anyone fighting or alarmed by the fighting. Seems straightforward and simple to me.

See above note.

>when combat is occurring, (everything is) involved in combat in some way, shape, or form.

Most dwarves are inside a fortress, fighting usually happens at the fringes.

This isn't a bland strategy game, where no goblins can enter the fortress until they have killed all of your militia. It only takes a single goblin running inside to ruin your idea of "Civilians will never enter combat."

> What if such a stray arrow (or stray dwarf being hurled by a colossus) hit one of those non-combatants that is standing absolutely still

That civilian will most likely already be alarmed, since fighting happens nearby. In the rare situation that he's not, he'll become alarmed by being hit and will flee to safety if he can or cry for help.

And the fact that he is, relative to the combatants, a statue until such point as they scare him doesn't faze you a bit?

>What happens when we are dealing with siege machinery which might someday be able to destroy constructions and walls?

I don't see any problems that will cause. These are hostiles, so they'll alarm people.

See above.

>Everyone would obey the same rules regardless of game speed or what is happening / My suggestion would require fundamental changes in code for only one thing

On the contrary I'd say, you specifically mention different speeds, hunger rates, ways of moving about and production rates for both rates. Essentially, making an entire new game mode. Whereas I would only change the amount of ticks in a calendar day, and not even for all dwarves.

Different between modes, identical between parts of the fortress.

Taking reservations about in into account, I'd say that crisis mode should apply to any dwarf that's executing a military or diplomatic action.

Oh Armok, that's bad...it's not like the militia is ever activated except to deal with sieges, or that diplomacy is ever involved with anything but the occasional messenger from a nearby town...

People have been discussing why they think their own idea for abstraction is better. The reason I think mine is the best (from the "Dwarf Mode Real Time Game Speed w/ Time Skipping" thread) is that for a game designed to run on emergent, procedural behavior, abstraction based on a procedural level with NO abstraction is superior compared to abstraction created arbitrarily by the game developer. As far as I'm concerned, with that unabstracted mode, you can then procedurally have as many different levels of abstraction as anyone could want without Toady having to rebalance everything for every mode.

Sorry, bud, a video game is, by its very nature, an abstraction. Tiles? HUGE abstraction. Arbitrary bounds between body parts? Abstraction. DF's wound system in general? A very detailed abstraction, but an abstraction nonetheless. You can't avoid abstraction, you can just make it playable. (Andeerz made this point, but I'd like to imagine I made it better.)
And do you even know what "Procedural" means?

Also... with regard to hunting, arenas, shooting ranges, etc.

For arenas and shooting ranges, I think what can be done is just have it run without triggering the slow-down so long as these activities occur in the designated area.

For hunting... hmmm...  perhaps any combat involving a hunter and a wild animal could be toggle-able as not able to trigger slow-down.

Possible issues would arise depending on problems listed in #2 in the original post.  If it is impossible for the game to calculate more than one complex action or movement occurring in the same tick... ugh... it would require combat to be abstracted in cases where one wouldn't want combat to trigger a slow down (i.e. hunting and arena combat).  The reason one would probably have to abstract combat is because most of the movements that happen during adventure-mode combat occur within a handful of seconds of game-time, which would occur within a single tick if we are talking about fortress-mode time (1 tick =~ 1.2 minutes).  That means any combat occurring in dwarf-mode time in my suggestion without triggering a slow down would have to be simplified to a single calculation every 1.2 game-minutes of combat determining what happens, as opposed to what would happen were the game to slow down to adventure-mode speed.  So, unless we are ok with such combats being pretty much auto-calculated (an average fight to the death probably wouldn't last more than two, maybe three dwarf-mode ticks; so that would mean two or three calculations determining the victor of a one-on-one duel, instead of many order more calculations in the same amount of game time in adventure-mode speed), combat would have to trigger a slow-down.

For maybe arenas and definitely shooting ranges, such an abstraction would be alright...  But for hunting, I think it would not be good to do at all, since the position and movement of the hunter is particularly important.

Actually... come to think of it... I think that this is a problem that cannot be fixed to my satisfaction, at least for hunting.  Crap!  I think this defeats my suggestion!

Here's an idea: Include a fast-mode combat system. That would solve most of these issues. "Fort's in fast-mode and a goblin is attacking a peasant? No problem, just use the fast-mode combat engine!" Each frame is only a few monutes, you know, not hours. That might have caused some of Silver's misunderstandings, coms to think of it...

[Silverionmox]

>Everyone would obey the same rules regardless of game speed or what is happening / My suggestion would require fundamental changes in code for only one thing

On the contrary I'd say, you specifically mention different speeds, hunger rates, ways of moving about and production rates for both rates. Essentially, making an entire new game mode.

Hmmm... You might be misunderstanding my suggestion.  Yes I suggest different speeds, hunger rates, and ways of moving about.  But these changes would apply to everyone equally and not be affected by toggling game speed.  And all of these changes would pretty much just be a simple changes of numerical values of a handful of parameters.  There would be no fundamental rewrite of the coding except for MAYBE the underlying movement stuff. 

Now, these changed hunger rates, speeds of movement, production rates... ALL of these would be the SAME between game speeds and for all dwarves no matter what is happening.  Essentially my suggestion is a way of putting in a speed toggle like you see in the likes of Sim City.  You can make the game go faster without any changes in how the game carries on its simulation (or as little change as possible...).

It would be as if the faster speeds of Sim City used different parameters (eg. roads have more traffic capacity, appartment blocks have more inhabitants, more pollution etc.). Given the FPS constraints, doing the same, but faster, isn't really possible. So going faster means losing resolution.

For maybe arenas and definitely shooting ranges, such an abstraction would be alright...  But for hunting, I think it would not be good to do at all, since the position and movement of the hunter is particularly important.
Actually... come to think of it... I think that this is a problem that cannot be fixed to my satisfaction, at least for hunting.  Crap!  I think this defeats my suggestion!

Not quite, but you're essentially sacrificing detail for speed. The question is how much you're willing to sacrifice.

[Andeerz]

>Everyone would obey the same rules regardless of game speed or what is happening / My suggestion would require fundamental changes in code for only one thing

On the contrary I'd say, you specifically mention different speeds, hunger rates, ways of moving about and production rates for both rates. Essentially, making an entire new game mode.

Hmmm... You might be misunderstanding my suggestion.  Yes I suggest different speeds, hunger rates, and ways of moving about.  But these changes would apply to everyone equally and not be affected by toggling game speed.  And all of these changes would pretty much just be a simple changes of numerical values of a handful of parameters.  There would be no fundamental rewrite of the coding except for MAYBE the underlying movement stuff. 

Now, these changed hunger rates, speeds of movement, production rates... ALL of these would be the SAME between game speeds and for all dwarves no matter what is happening.  Essentially my suggestion is a way of putting in a speed toggle like you see in the likes of Sim City.  You can make the game go faster without any changes in how the game carries on its simulation (or as little change as possible...).

It would be as if the faster speeds of Sim City used different parameters (eg. roads have more traffic capacity, appartment blocks have more inhabitants, more pollution etc.). Given the FPS constraints, doing the same, but faster, isn't really possible. So going faster means losing resolution.

Well, it wouldn't be, as you said, the equivalent of "roads have more traffic capacity, appartment blocks have more inhabitants, more pollution etc." at faster speeds.  Slow speed would have the same everything as fast speed.  BUT you get at the crux of the problem... namely that "given the FPS constraints, doing the same, but faster, isn't really possible."  I don't think it's the FPS constraints, but the tick-constraints (which do end up translating into FPS constraints... so never mind).  If the game could have several ticks (72 ticks) in dwarf mode happening in the same frame, then this suggestion wouldn't have a problem (and then, this suggestion would be moot... just have everything operate like adventure-mode but faster!), but that is entirely impossible.

But yeah.  Going faster (in the way my suggestion requires) means losing resolution, and where that resolution is lost in my suggestion (and the ONLY place resolution is lost) is movement...  :/

For maybe arenas and definitely shooting ranges, such an abstraction would be alright...  But for hunting, I think it would not be good to do at all, since the position and movement of the hunter is particularly important.
Actually... come to think of it... I think that this is a problem that cannot be fixed to my satisfaction, at least for hunting.  Crap!  I think this defeats my suggestion!

Not quite, but you're essentially sacrificing detail for speed. The question is how much you're willing to sacrifice.

And I'm not sure I'm willing to sacrifice resolution of movement.  I feel like it would screw too much up.  But maybe it wouldn't.  It seems to me like the only way to test this is to actually try it out and do some controlled studies in the actual game.  I also would like to know more about the inner-gutty-works of the game.

Thinking about it more... I think the problems listed in problem #2 are not reconcilable.  I don't think it would be possible to have movements or actions take less than 1.2 minutes of game-time in dwarf-mode speed unless there was some miraculous reworking of the code that would reduce processor requirements by one or two orders of magnitude (like support for multiple cores), or some sort of supercomputer was used.  Poooooop!

Here's why: to solve these non-reconcilable problems, there would need to be provisions in the movement/pathfinding/AI code that if a distance to be traveled or action is short enough (as in, it would take shorter than ~1.2 minutes for an entity to travel or do), then another pathfinding operation/movement/action could be made with the remaining time in the same tick by the entity doing stuff.  I think this would make the calculations per tick skyrocket in dwarf-mode speed, where a good deal of actions would take less than 1.2 minutes (like short distance movements, combat-like stuff, lever pulling (if we make the time taken to pull a lever take the same amount of time as adventure mode), and anything else that in adventure mode takes less than 72 ticks to do.  And that's not even taking into account fluids.  Any ideas/requests for clarification?  Anybody disagree with me that this would be too processor intensive to be plausible?  I mean, it would be somewhat straightforward to code... and could work if relegated to a separate processor running in parallel...

[knutor]

I could champion this thread, right up the pearly steps of the Great One's capital.  If only the OP had picked a better subject line.  With Synchronizing replacing Rectifying.  Rectify is too close to Rectal.  And that word, Rectal, creates illusions in my mind.  Illusions, that I would rather not imagine.  Know what I mean? 

We called you all here together now, to discuss, the Rectifying of..
*Audience bursts out in a roar of laughter.* 
Now-now!  Quiet please!  QUIET!  We have called you all..  
*The noise gets louder and louder..*  Knutor

[Manveru Taurënér]

I could champion this thread, right up the pearly steps of the Great One's capital.  If only the OP had picked a better subject line.  With Synchronizing replacing Rectifying.  Rectify is too close to Rectal.  And that word, Rectal, creates illusions in my mind.  Illusions, that I would rather not imagine.  Know what I mean? 

We called you all here together now, to discuss, the Rectifying of..
*Audience bursts out in a roar of laughter.* 
Now-now!  Quiet please!  QUIET!  We have called you all..  
*The noise gets louder and louder..*  Knutor

I think you're the only one who thinks that though, no worries ;P

[Andeerz]

Actually... you have a point... Synchronize would be a better word than Rectify (not necessarily for the "rectum" reason though).    lol...

[QbertEnhanced]

Could someone summarize the issues brought up with having a variable speed toggle?

[MrWiggles]

It forces Fort Mode and Adventure Mode into being two fairly different games. This is fine, but the two modes are suppose to be very well interconnected between one another, and thats were issues arrive.

[Silverionmox]

Could someone summarize the issues brought up with having a variable speed toggle?

If you want to make it run faster:
Either you don't change the way the game works, and then it would be nothing but a smoother way to toggle the FPS cap, which is limited by hardware most of the time, not software; or you change the game when it runs at a faster speed, effectively having to create, maintain and coordinate a different version of DF, while opening the door for abuse if you switch between different rulesets.

If running slower at times is an option, then there are other possibilities, eg. http://www.bay12forums.com/smf/index.php?topic=113068.msg3440435#msg3440435 (which IMHO solves the coordination issues at their root, while not requiring changes in the way the rest (i.e. not the timekeeping) of the game works).

[Andeerz]

Basically, the issue with my suggestion is if the differences between how "fast" mode and "slow" mode operate would make things operate so differently between modes that things would be open to exploits and breaking of the game.  I am of the opinion that my suggestion has insurmountable issues.

This main issue arises from how pathing would be handled in "fast" mode vs. "slow" mode.  Basically, the way I have it suggested, "fast" mode would almost definitely have lower resolution in how things move and path than "slow" mode would.  To summarize:

1.  Both time modes would use the same framework for pathing and moving of entities, but in "fast" mode there could conceivably be less opportunities for the pathing algorithms to synthesize data from other things happening over time.  For example; say there is an action that in "fast" mode would take 3 ticks to do.  In "slow" mode, as per my suggestion, this would take 216 ticks to do.  Each tick is a cycle of calculations (one iteration of the simulation).  Therefore, in "fast" mode, that action would have only 3 opportunities to synthesize changes in parameters from things that have changed from one tick to the next, whereas in "slow" mode there would be 216 opportunities.  Basically, during fast mode, it would be difficult, if not impossible, to have "fast" mode catch everything that happens that "slow" mode would... at least, I think.  This leads to #2...

2.  When it comes to actions that take less than 1.2 minutes of game-time to complete by an entity, I am not sure how the game could allow entities to do multiple actions per-tick and handle that without either switching to "slow" mode, magically implementing multiple core crap (which would make this suggestion probably pointless anyway), or slowing the game to a crawl/crashing the game.

However, I feel that issues also arise with the suggestion Silverionmox links to that would run into as severe of problems as my suggestion... which would be best discussed in that thread, though if people do it here, I don't really mind.

In sum, my suggestion is broken.
   

[GreatWyrmGold]

Could someone summarize the issues brought up with having a variable speed toggle?

Aside from the major issues required to remake the Fortress Mode engine, and to make dwarves function at equal resource consumption and job completion levels in either speed, this would also screw up everything with combat. If combat is "supposed" to happen at Adventure-Mode speeds, what happens if you're in Fort-Mode speed? Does the game say "Ok, you're at A-M speed?" Or do you let combat occur at F-M speed, invalidating one of the biggest benifets to this suggestion (and also requiring a bunch of unneeded abstraction of blows, if we don't want fights to be decided by who can avoid dehydration the fastest). Those are the biggest downsides I see, and I think the upsides (a synchronization between modes, alleged realism) aren't worth it.

A brief note on the severity of the realism issue: Some (Silverionmox, notably) have claimed that it takes a dwarf a week to cross the fort, or two months to move a table, or some other ludicrous figure. Here's the facts: According to the wiki, a dwarf has nine "off" ticks between turns, so one "turn" per 10 frames (modified by agility, of course). A dwarf can move one tile a turn, so 0.1 tiles/tick. The wiki also calculates that a tick is 1.2 minutes in F-M speed. So, it takes 12 minutes to move a tile. An embark tile is 48 tiles square, and the default size of a fortress is 4*4 embark tiles. So, that means a dwarf would take 4*48*10, or 1,920, ticks to move across an average fortress area (not the fortress itself, which would be maybe an embark tile and a half across, although as forts are often multi-layered I'll only reduce it to an even 1,000 ticks, to throw Silver's ilk a bone). That means that by my liberal estimate, it takes 1,200 minutes or 20 hours to move across a large fortress. Maybe that's a bit long, but given the size of, say, Moria, huge forts aren't exactly unknown in dwarven lore. If an average drop from fortress-level to magma-sea level is about 100 z-levels, it would take a couple hours to get there, which doesn't seem unreasonable since you're descending to the mantle.

[Silverionmox]

It is a clear fact that the dwarves don't have 30 lunches and naps per month, so it's obvious that there's some kind of compression/abstraction going on already. With 12 minutes to move a tile, a dwarf would need an hour just to walk around a table. It becomes clear that you can't have any complex combat manoeuvres with that speed.

[GreatWyrmGold]

It is a clear fact that the dwarves don't have 30 lunches and naps per month, so it's obvious that there's some kind of compression/abstraction going on already[1]. With 12 minutes to move a tile, a dwarf would need an hour just to walk around a table[2]. It becomes clear that you can't have any complex combat manoeuvres with that speed[3].

1. So? Why should dwarves even have circadium rhythms based on the rising and setting of a sun that they almost never see?
2. 48 minutes =/= 1 hour, and that's assuming they don't just walk over the table...and that tiles are table-sized...and that you're ignoring various issues with tile-based movement...
3. Why not? Personally, I like the way it is now. IRL, battles (or at least sieges) could last for days, and the current system allows even little skirmishes to feel epic, not to mention you can easily get through the fort's first year in a couple hours, tops (assuming real life doesn't intervene too much...) Personally, little details like "three meals a solar day" and "fights last only a few minutes" aren't worth taking 72x as long to get anywhen, so I'd probably (almost?) never willingly use the A-M speed.

[Andeerz]

Even though I think my suggestion is dead in the water, let me clarify...

If combat is "supposed" to happen at Adventure-Mode speeds, what happens if you're in Fort-Mode speed? Does the game say "Ok, you're at A-M speed?"

During the combat, yes.  Those situations and a few others are the only times the game would suggest or force a change to adventure mode time.

Also... not taking one side or another here, just wanna highlight some things:

IRL, battles (or at least sieges) could last for days,

Sieges could often last months, and sometimes years.  And by far most battles during the medieval era were sieges.  Pitched battles, skirmishes, and the like were rather rare.  Also, a lot of warfare was indirect, focused on attacking an opposing force's ability to wage war rather than actually fighting on the battlefield.

An army would spend many weeks, months, and even years on a campaign, with most of the time spent traveling, maneuvering and not actually fighting.  Battles, when they did occur and if they were not sieges, would generally last at most a few hours, with actual fighting lasting only on the order of minutes. 

[GreatWyrmGold]

Even though I think my suggestion is dead in the water, let me clarify...

It's probably not that bad...

If combat is "supposed" to happen at Adventure-Mode speeds, what happens if you're in Fort-Mode speed? Does the game say "Ok, you're at A-M speed?"

During the combat, yes.  Those situations and a few others are the only times the game would suggest or force a change to adventure mode time.

If it forces, the game needs to be able to define "combat."