Question: I don't see how the existing pause functionality is in any way like the previous behavior. For me the menu comes up as a modal dialog box that doesn't allow the mouse to interact with the screen except within the frame of the dialog box (as expected for modal windows). If I can't select anything then it works nothing like prior behavior.
For people that seem confused about this please understand that the prior pause behavior worked the same way in every Relic game since Homeworld. COH 1, COH 2, all the DOW versions, and I believe Homeworld 1 and 2. This change is a retrograde reduction in functionality that is amazing in its depth and scope.
I have a physical disability which limits how I interact with computer games. I have to play using the mouse in my non-dominant hand and only for 20-30 minutes at a time. Removing this functionality essentially destroyed the game for me and I'm sure for many others. You should really look into the average age of your few remaining players.
Doing this at this moment in the life cycle of the game is baffling since I would suspect that single-player/skirmish players probably outnumber multi-players since multi-players have to dash off and play the latest game to have any sort of pool of competitors. We single-players are the die hard loyalists that stick with a game for years. Messing with us at this point is driving a small but poisoned stake through the heart of your somewhat fragile franchise.
It is a pitty that steam does not allow to downgrade. If only there was a way to get the game I already bought in other version than latest...
Remember the forum rules!
As a company that makes its money selling software we frown on people who steal software, movies, comics or anything else. We can't stop you from pirating the latest episode of the HBO vampire sex show, but we can ban you for talking about it, or encouraging others to do so.
My greatest fear is that Relic actually thinks this is a desirable user interaction and will taint their other games with this loss of capability. I can't understand why they bothered to neuter it for an end-of-life game except as a poke in the eye for their most loyal players.
Well, I'm off to play Pillars of Eternity -- a game that understands the value of pause functionality.
That form of pausing is useless. Every game has a dialog box that comes up that stops the action. Not a feature and not under discussion here.
What baffles me is why people need to justify what is clearly a reduction in critical functionality for many of us. Some sort of "theory of mind" deficit that results in dismissing the experiences of anyone that isn't you?
You can pause the game. You just can't play it while you do so.
Let's not go in circles, we've been over this 10 times already. Nobody says you can't pause the game. I think swat has made pretty clear what we're asking to be reverted.
I was speaking to the user that specifically stated "pause functionality", and then compared a real-time strategy game to something completely different.
We have been through this ten times already. I've let you bump the thread as you wish.
However, there is a critical lack of understanding of what "real-time strategy" means in this thread. How you play the game isn't necessarily what the developers intend. Feel free to ask for the previous functionality back.
But as soon as your posts stray to what games "should" have and how Relic have "lessened" their game, I will gladly correct you.
Relic games have always been hybrid real-time with pausing. This is fundamental to their design. There are many other games that have similar functionality across many genres. Frozen Synapse for example.
I understand how this might cause problems in multiplayer but to just yank single-player functionality out seems almost like a coding error -- some intern with no institutional memory set loose in the code base.
Gorb: to maintain that there is some platonic ideal of any form of game is nonsense. All other Relic games do this, this game used to do this, therefore this was removing a prior supported feature for no plausible reason.
Apparently for Gorb Dawn of War II Retribution exist to fulfil some idealistic concept of a true "real-time strategy" game, and not needs of some pesky users.
I belive this is some platonic type philosophy thing.
Lemurcatta, unless you're a Relic developer I don't think you can speak of something being "fundamental to their design".
I've also offered plausible reasons as to why this happened earlier in the thread. They were ignored, evidently. If you're a developer (you're presuming things about the codebase and Relic's staff competency), feel free to send me a message (as a developer - but not of Relic at all) to debate the issue further.
swat, I'm simply pointing out the realities of playing a real-time strategy game. The clue, as ever, is in the name. Your simple attempts at trolling may continue, but there's no way in heck I'd ever be affected by them
Let's not derail the thread anymore. Swat is not trolling, he is just infuriated and he has every right to be so. I suggest we wait to see how the dev(s) respond to this eventually.
Gorb, unless you are a Relic developer or program manager I think we stand equal in the validity of our speculations. The reason I keep coming back to this discussion it puzzlement over your dismissal of our claimed experience. As I said the term real-time strategy does not override years of history of user experience with Relic games. There is no sacred tome that decrees that active pause is heretical for this genre.
Hey, heck, I'm happy to debate programming specifics here. I didn't say that I knew more. I simply said that I'd offering potential reasons, and an avenue to debate them that wouldn't overshadow Morfeas' attempts at getting Relic to reply.
I had to go back and read the entire thread to understand how we got here. Gorb, you originally conceded that removing functional pause from single player/skirmish was probably a coding error.
Maybe this is more a specification error since Relic seems to have thought they fixed the problem by just binding the pause key to the modal dialog box. So not so much a coding issue as a fuzzy understanding of the original feature by the current team. You had the same misunderstanding originally because you never used the feature as would be the case for most multiplayer users but us compstompers really got burned.
This feels like something that would happen if you handed off a code base to some external/outsourced team. A feature like this might only exist in the heads of some of the original team and the loss of institutional memory on the handoff may have resulted in this problem.
Simple knowledge about software design tells you this: - somewhere in the code there is mapping between keys pressed (events) and functions started. There has to be. - what was done first is "make PAUSE button do nothing". Simplest way of achieving it is go to this mapping and remove binding for "PAUSE pressed" event. - then there was fix -- "make PAUSE button bring up menu". Again -- you go to the mapping and copy-paste binding from F10 to PAUSE key.
This is a very basic case. If they did something more than that, then they wasted their time.
If you do what I described above then you will arrive at situation we have now. And you need only to make one change in one file. No need for extensive testing; and you can be quite sure you did not broke anything.
I think that if they intend to remove active pause from multiplayer it might be more complicated than restoring the key mapping. It might be a challange to unwind the functionality from only one mode.
I do agree that it would be preferable to restore the original functionality now and then do the work to disable active pause only in multiplayer.
I had to go back and read the entire thread to understand how we got here. Gorb, you originally conceded that removing functional pause from single player/skirmish was probably a coding error.
Maybe this is more a specification error since Relic seems to have thought they fixed the problem by just binding the pause key to the modal dialog box. So not so much a coding issue as a fuzzy understanding of the original feature by the current team. You had the same misunderstanding originally because you never used the feature as would be the case for most multiplayer users but us compstompers really got burned.
This feels like something that would happen if you handed off a code base to some external/outsourced team. A feature like this might only exist in the heads of some of the original team and the loss of institutional memory on the handoff may have resulted in this problem.
Reasonable assumptions, you trend to pessimism where I trend to optimism. That's fair. Sorry for making you go through the thread, up til this point I was trying to avoid an excessive derail.
I originally conceded that it could be related to ripping out the entire pre-existing network library (predicated on GfWL for vDoW II and CR, though Retribution would be a slightly different usecase). Mainly the differences between P2P networking and the new Battle Server client-server model. To go into more detail (if I didn't previously) this is because it is (incredibly) likely that the previous "pause" code was shared between the SP and MP states, the difference being online MP wouldn't pause the simulation state because P2P ensures all clients sync their game state every frame (or so). For SP and MP it would be relatively easy to pause the simulation. Allowing input outside of the pause dialogue would be desirable (if intended or unintended), so even if it wasn't intended, a bug report for it would probably be ignored.
(I've been doing some personal work on threaded simulations of late, it's really helped me get a better understanding of the basics of creating stuff that runs at a particular frame rate)
Now, if we expand on what I've said below to swat, the pause functionality is likely to be a single entity (of some description), so if we replace, we'll replace it for all calls for that function. So both SP, offline MP and online MP are affected by this change. To restructure the code to allow for separate pause functions for variant game modes would involve far more code maintenance and developer man-hours.
This is without getting into the particulars of the pause functionality and how it works. Certainly, we have to assume that Relic did not intentionally design their games to allow for "active pause". At best, it would be a happy coincidence, which is why I've always said that it was never intended functionality. You might have enjoyed the benefits of it, but that doesn't mean it was intended. As I said above, it was probably a non-critical bug / consequence of the software's original design that due to positive benefits was never chalked up to be fixed.
Simple knowledge about software design tells you this: - somewhere in the code there is mapping between keys pressed (events) and functions started. There has to be. - what was done first is "make PAUSE button do nothing". Simplest way of achieving it is go to this mapping and remove binding for "PAUSE pressed" event. - then there was fix -- "make PAUSE button bring up menu". Again -- you go to the mapping and copy-paste binding from F10 to PAUSE key.
This is a very basic case. If they did something more than that, then they wasted their time.
If you do what I described above then you will arrive at situation we have now. And you need only to make one change in one file. No need for extensive testing; and you can be quite sure you did not broke anything.
Not really reasonable assumptions, and that isn't really involving software development paradigms at all. Your "design" of key mapping is completely dependent on the subsystem involved and the language the game was written in (object oriented paradigms making a significant difference to code layout). Assuming C++ as is generally the industry standard, it only involves an attempt at wrapping the base language in some weird object-oriented wrapper that kinda helps (when compared to C) but also kinda doesn't.
All you're doing it making an assumption based on how the regular keybinds work ingame. Actual native functionality is a lot more complicated than the simple associative array that binds keyboard characters to certain ingame shortcuts.
Certainly, you're likely to be changing more than one file, in a well-maintained codebase at least. Modularity is key, and while the pause functionality is a singular entity and thus likely to be defined by itself, it will have references and calls throughout larger parts of the project which will also need updating.
These changes will then need syncing with the master repository and basic project management applied so that no-one else compromises the integrity of the build. A lot of this is more simple than the stupid words some programmer invented for them, but the reality of the situation is definitely more than what you're suggesting.
I think that if they intend to remove active pause from multiplayer it might be more complicated than restoring the key mapping. It might be a challange to unwind the functionality from only one mode.
Of course it will be hard. They will actually need to change how things work and not simply change bindings. They will need to modify functionality, not disable and reuse old one.
Changing bindings is fast and simple, and this is what they did. Creating separate pause behaviour for SP requires work.
They removed the existing Pause functionality. It was removed. Yes, they forgot to re-associate F10 with the new pause functionality but that isn't all of what they did.
This is without getting into the particulars of the pause functionality and how it works. Certainly, we have to assume that Relic did not intentionally design their games to allow for "active pause". At best, it would be a happy coincidence, which is why I've always said that it was never intended functionality. You might have enjoyed the benefits of it, but that doesn't mean it was intended. As I said above, it was probably a non-critical bug / consequence of the software's original design that due to positive benefits was never chalked up to be fixed.
I disagree strongly with this assertion. If you use this functionality you can see many behaviors that are clearly intentional. When you path by shift clicking you see each track, you can move over the map by clicking the map and it correctly positions you. There is clearly functionality that continues to work while paused. If I remember correctly in COH1 there were bugs filed against it and improvements made in how it worked. There is no question that this was an intentional and well-designed feature.
That's very interesting regarding the change to the networking library. That would explain the reason to change things. However, I assume COH2 supports the latest networking model and it has the active pause functionality (thank god because it's the last game I'm physically able to play for more than 15 minutes).
CoH 2 was developed from the ground-up to support said model (well not initially, but the game still has active, dedicated support). As I said, to replicate this behaviour (presumably by splitting pause functionality into separate methods) it'd take more man-hours / developer attention.
DoW / DoW II are dead products with barely any active sales and no active, dedicated support. The mission statement was to update the DoW series with MP that wouldn't crash and burn when GameSpy and GfWL died. Retribution being updated was a happy coincidence, that unfortunately for you guys lead to this particular issue.
And you still can't call that intentional. All of what you're describing is how the game works when it's unpaused. Everything you listed, the game does while unpaused. Ergo, if pause doesn't prevent input, all these functions will continue to work when paused (in the old model). In the new model, given the baseline of support granted to DoW and DoW II, they don't work due to how the game code has changed (as I explained, networking wise).
Nobody can comment on what is intentional or not. However, if it was such a huge massive advertised intended part of the game (as others have also been claiming), it would've not been left as such an oversight. Statistical trends indicate that it is an oversight, and that the amount of players affected by this number as a massively small percentage of the userbase (otherwise we'd see more complaints).
Not that I'm saying that I don't hope it gets fixed. I'm just saying you can't declare intent when the only supporting evidence you have is "the other games let you do this". A text input box lets you input "Penis". That doesn't make Commander Penis an intended result All you can do is hope Relic get this fixed for you - if CoH 2 has the same functionality, that increases the likelihood of DoW II being fixed at some point.
Menu
Comments
Lemurcatta
For people that seem confused about this please understand that the prior pause behavior worked the same way in every Relic game since Homeworld. COH 1, COH 2, all the DOW versions, and I believe Homeworld 1 and 2. This change is a retrograde reduction in functionality that is amazing in its depth and scope.
I have a physical disability which limits how I interact with computer games. I have to play using the mouse in my non-dominant hand and only for 20-30 minutes at a time. Removing this functionality essentially destroyed the game for me and I'm sure for many others. You should really look into the average age of your few remaining players.
Doing this at this moment in the life cycle of the game is baffling since I would suspect that single-player/skirmish players probably outnumber multi-players since multi-players have to dash off and play the latest game to have any sort of pool of competitors. We single-players are the die hard loyalists that stick with a game for years. Messing with us at this point is driving a small but poisoned stake through the heart of your somewhat fragile franchise.
swat
Remember the forum rules!
Morfeas
swat
//sarcasm off
Lemurcatta
Well, I'm off to play Pillars of Eternity -- a game that understands the value of pause functionality.
Gorb
Lemurcatta
What baffles me is why people need to justify what is clearly a reduction in critical functionality for many of us. Some sort of "theory of mind" deficit that results in dismissing the experiences of anyone that isn't you?
Morfeas
Gorb
We have been through this ten times already. I've let you bump the thread as you wish.
However, there is a critical lack of understanding of what "real-time strategy" means in this thread. How you play the game isn't necessarily what the developers intend. Feel free to ask for the previous functionality back.
But as soon as your posts stray to what games "should" have and how Relic have "lessened" their game, I will gladly correct you.
Morfeas
Everything else I more or less agree with.
swat
And in the meantime:
Lemurcatta
I understand how this might cause problems in multiplayer but to just yank single-player functionality out seems almost like a coding error -- some intern with no institutional memory set loose in the code base.
Gorb: to maintain that there is some platonic ideal of any form of game is nonsense. All other Relic games do this, this game used to do this, therefore this was removing a prior supported feature for no plausible reason.
swat
I belive this is some platonic type philosophy thing.
Gorb
I've also offered plausible reasons as to why this happened earlier in the thread. They were ignored, evidently. If you're a developer (you're presuming things about the codebase and Relic's staff competency), feel free to send me a message (as a developer - but not of Relic at all) to debate the issue further.
swat, I'm simply pointing out the realities of playing a real-time strategy game. The clue, as ever, is in the name. Your simple attempts at trolling may continue, but there's no way in heck I'd ever be affected by them
swat
And i am happy -- I play this game with active-pause, and give no (...) about latest "improvements".
Morfeas
Lemurcatta
Gorb
Lemurcatta
Maybe this is more a specification error since Relic seems to have thought they fixed the problem by just binding the pause key to the modal dialog box. So not so much a coding issue as a fuzzy understanding of the original feature by the current team. You had the same misunderstanding originally because you never used the feature as would be the case for most multiplayer users but us compstompers really got burned.
This feels like something that would happen if you handed off a code base to some external/outsourced team. A feature like this might only exist in the heads of some of the original team and the loss of institutional memory on the handoff may have resulted in this problem.
swat
- somewhere in the code there is mapping between keys pressed (events) and functions started. There has to be.
- what was done first is "make PAUSE button do nothing". Simplest way of achieving it is go to this mapping and remove binding for "PAUSE pressed" event.
- then there was fix -- "make PAUSE button bring up menu". Again -- you go to the mapping and copy-paste binding from F10 to PAUSE key.
This is a very basic case. If they did something more than that, then they wasted their time.
If you do what I described above then you will arrive at situation we have now. And you need only to make one change in one file. No need for extensive testing; and you can be quite sure you did not broke anything.
Lemurcatta
I do agree that it would be preferable to restore the original functionality now and then do the work to disable active pause only in multiplayer.
Gorb
I originally conceded that it could be related to ripping out the entire pre-existing network library (predicated on GfWL for vDoW II and CR, though Retribution would be a slightly different usecase). Mainly the differences between P2P networking and the new Battle Server client-server model. To go into more detail (if I didn't previously) this is because it is (incredibly) likely that the previous "pause" code was shared between the SP and MP states, the difference being online MP wouldn't pause the simulation state because P2P ensures all clients sync their game state every frame (or so). For SP and MP it would be relatively easy to pause the simulation. Allowing input outside of the pause dialogue would be desirable (if intended or unintended), so even if it wasn't intended, a bug report for it would probably be ignored.
(I've been doing some personal work on threaded simulations of late, it's really helped me get a better understanding of the basics of creating stuff that runs at a particular frame rate)
Now, if we expand on what I've said below to swat, the pause functionality is likely to be a single entity (of some description), so if we replace, we'll replace it for all calls for that function. So both SP, offline MP and online MP are affected by this change. To restructure the code to allow for separate pause functions for variant game modes would involve far more code maintenance and developer man-hours.
This is without getting into the particulars of the pause functionality and how it works. Certainly, we have to assume that Relic did not intentionally design their games to allow for "active pause". At best, it would be a happy coincidence, which is why I've always said that it was never intended functionality. You might have enjoyed the benefits of it, but that doesn't mean it was intended. As I said above, it was probably a non-critical bug / consequence of the software's original design that due to positive benefits was never chalked up to be fixed. Not really reasonable assumptions, and that isn't really involving software development paradigms at all. Your "design" of key mapping is completely dependent on the subsystem involved and the language the game was written in (object oriented paradigms making a significant difference to code layout). Assuming C++ as is generally the industry standard, it only involves an attempt at wrapping the base language in some weird object-oriented wrapper that kinda helps (when compared to C) but also kinda doesn't.
All you're doing it making an assumption based on how the regular keybinds work ingame. Actual native functionality is a lot more complicated than the simple associative array that binds keyboard characters to certain ingame shortcuts.
Certainly, you're likely to be changing more than one file, in a well-maintained codebase at least. Modularity is key, and while the pause functionality is a singular entity and thus likely to be defined by itself, it will have references and calls throughout larger parts of the project which will also need updating.
These changes will then need syncing with the master repository and basic project management applied so that no-one else compromises the integrity of the build. A lot of this is more simple than the stupid words some programmer invented for them, but the reality of the situation is definitely more than what you're suggesting.
swat
Changing bindings is fast and simple, and this is what they did. Creating separate pause behaviour for SP requires work.
Morfeas
Gorb
Hence, my post.
swat
Remove one binding, copy-paste other one -- this is commit history when regarding Pause in last two patches.
Of course they seem to be doing something with MP, but i don't use it, so I don't know about it.
Gorb
swat
Lemurcatta
That's very interesting regarding the change to the networking library. That would explain the reason to change things. However, I assume COH2 supports the latest networking model and it has the active pause functionality (thank god because it's the last game I'm physically able to play for more than 15 minutes).
Gorb
DoW / DoW II are dead products with barely any active sales and no active, dedicated support. The mission statement was to update the DoW series with MP that wouldn't crash and burn when GameSpy and GfWL died. Retribution being updated was a happy coincidence, that unfortunately for you guys lead to this particular issue.
And you still can't call that intentional. All of what you're describing is how the game works when it's unpaused. Everything you listed, the game does while unpaused. Ergo, if pause doesn't prevent input, all these functions will continue to work when paused (in the old model). In the new model, given the baseline of support granted to DoW and DoW II, they don't work due to how the game code has changed (as I explained, networking wise).
Nobody can comment on what is intentional or not. However, if it was such a huge massive advertised intended part of the game (as others have also been claiming), it would've not been left as such an oversight. Statistical trends indicate that it is an oversight, and that the amount of players affected by this number as a massively small percentage of the userbase (otherwise we'd see more complaints).
Not that I'm saying that I don't hope it gets fixed. I'm just saying you can't declare intent when the only supporting evidence you have is "the other games let you do this". A text input box lets you input "Penis". That doesn't make Commander Penis an intended result