Jump to content

The Steppenwulf

Members
  • Posts

    650
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by The Steppenwulf

  1. Exactly!! @chopinIt Does an acute understanding of the fundamental issue for any 3rd party campaign design count as 'qualification'?!?!: Unless you have collabaration from BF regarding release of the algorithm for decompression of the .btt data, or have independently cracked the compression method, then it's impossible to seamlessly interface data between CM battles and any 3rd party software (application of Japanzers scripts aside, which would still hit certain boundaries in any case and therefore cannot be termed seamless either). Anything less than direct access to decryption relies on an awkward fudge in functionality between the op layer and the CM scenario editor. As Poesel71 has already pointed out, there are some very experienced CM game designers already operating their own campaigns and rule sets within these compromises. Any 'new design' cannot circumvent this fundamental problem. Now if BF agree to release such a decryption function then I want to know about it!!
  2. Inspirational work Umlaut. I must congratulate you on bringing some truly unique mapwork to the game. The 'urban benchmark' no less!!
  3. Yes that works. Actually, one could merely resize existing icons in photoshop, create a template blank 32 x 32 .bmp and then paste the resized images over the top. One would still have to edit the alpha though which, unless you've got photoshop, is an awful PITA; the alpha in .BMP format requires 32 bit support.
  4. There are lots of little bugs and improvements in CM2 generally that need to be addressed. One change that I would like to see in the scenario editor would be intel - there is no option for both sides to receive prior intel (only one side) which could prove to add an extra, as yet undervalued, aspect to CM2 scenarios. However, as a one off feature that would bring the greatest innovative change to CM2, then I'd have to concur with Womble's point as quoted. I've put some thought into how this could be done practically: The community needs a stand-alone function that decrypts the .bts file (the save file - not the scenario or PBEM file) data and creates a series of text documents with the particular game conditions, map details and feature locations, level of building damage, assets extant in game, their locations, current condition troop state etc... into an editable format. Clearly this function would work at any stage of a PBEM once a .bts save file is created. The same tool would allow such text data to be rebuilt into a new .bts file by encyption with the same algorithm. The only proviso - by reason of protecting PBEM WEGO games - would be for the .bts decryption to require both passwords of the respective .ema file (Such information is held in the .bts file anyhow). For those that don't realise how signficant this is. Such a function would allow (with permission of the 2 players) for a 3rd party (umpire) to introduce new units on map edges for reinforcement changes on the fly. This would facilitate the integration of CM2 onto a larger operational layer. It would also build in flexibility for all kind of similar desirabilities; dynamic weather conditions, supplies and yes persistent map damage. I see no real programming or other difficulties in producing such a function and there is no doubt it would prove to be the most mod friendly and innovative function in CM yet - with one off scenario battles quickly rendered tame. Hell, I would even pay double extra for such a sea-change.
  5. I'm interested to know how you ripped the BIA sounds. I didn't think the stock file format was a standard one - although I'm aware that the game sounds have come under attention by BIA modding community so I figure there must be a tool for converting them. The reason I query this is actually because I did have a fancy at adding some of BIA dialogue sounds to my current CM mod mix. I've always considered much of BIA's dialogue audio content to be as good as anything else; DOD, RO2, FH2 etc... with the added advantage of being pertinent to Normandy of course. Unfortunately, I no longer own the game and no one out there seems to be offering any of the game files in an accessible format - which I find perplexing. Please advise!!
  6. Yes, the problem is most likely to be a map that has carried forward units from a previous battle - eg part of a campaign. The reason I'd suggest is that units starting with radios are coded in the .bts files as being able to call artillery. The loss of a unit radio later in a campaign does not remove that coded capability. It's not a bug as such, more a shortcoming in the game code. Maybe Steve can confirm this is the case and also agree that it's worth BF time looking at for a future fix.
  7. The BF forum is full of sensitive souls and aggressive types alike (as we are all aware). In this light I sometimes read my post back and think I might be misunderstood. Yes I experimented with this idea, shaped as it is by the current game mechanics. I'm curious, do you leave uncommitted reinforcements standing around then on the map for the duration of the rest of the battle. And if one makes the decision not to commit them can one later change one's mind? A Brigade Commander does not need to need to pass his battalion management decisions up the chain of command. Once he receives and accepts his objectives and the resources available are agreed and allocated to him he proceeds as he sees fit. Unless something goes badly awry, requiring additional resources, or perhaps advice, his only communication up the ladder will be a progress report/update. Interesting point, sounds like it would work pleasingly well. I did mention in my previous post how such issues can be circumvented - this is similar but one I've not thought of. Of course this is logical and I agree. Brigade level is the next command level above which CM caters. Theoretically, this basic construction could be expanded but one would need multiple players each commanding a brigade to make up a division. A single player commanding a division and all it's component units is unrealistic and too inconsistent with CM gamplay in my view. Moreover, I think we'd all agree that multiple players each commanding a battalion is best for workability and the experience of command consistent with CM gameplay. From my experience of playing a broad range of multiplayer games (board games as well as computer games), I have always found that more than four players on each side, and for all kinds of reasons, the game enters a dangerzone of becoming unmanageable and some degree of disintegration normally ensues. Four is definitely a magic number for multiplayer game design or eight in total.
  8. These are all first class points Broadsword. My thoughts: 1) Tactical decision cycles at Reg/Brig level This is a pivotal question. What evidence do we have of the WW2 experience? My argument is based on an estimation that a radio update from Battalion HQ (who, yes, are in direct contact with the ground situation) to Brigade HQ for our C/O to make a decision that 3rd Battalion can actually stand down, contrary to the previous order of attack, and then relay that new order by radio to the 3rd Batallion C/O. I went with 20 mins as a safe bet because my guess is that it would actually even be less than that. When a company C/O can call in Artillery by radio in around 10 mins with fairly complex data exchanges I don't find my estimation to be off the scale. However, admittedly I have nothing firmer to base my claim on. I hope that we can have some evidence contributed upon which we can resolve this point one way or the other. It's an imperative consideration for any discussion on tactical operational warfare for a CM game. 2) You are quite right to raise the question of operational boundary lines. Even more so because it is another critical factor in our discussion. I have also previously considered this point when thinking about how to make CM work at the OP level. Again my guess (which seems entirely natural to make) is that it is the natural terrain features and objectives that normally dictate operational boundary lines not the edges of a map. There are ways to circumvent this apparent problem through careful map dimension design that could cover this anomally. Nevertheless, it still doesn't solve any situation where a direct order is passed from Brigade HQ to a recently disengaged 2nd Battalion to use their mortars in support of 1st Battalion for example. This dynamic cannot be replicated in a CM battle - or rather during the actual course of one (assuming that my perspective of the Reg/Brig decision cycle is correct). I welcome any rebuttals, thoughts or feedback on my points. And, I'm quite happy to change my view about all this - find some peace of mind over something which found me pulling my hair out over the .bts files. Also, I must stress that I think Tankhunter's effort here looks particularly neat & I will follow this project's development with the utmost interest.
  9. Taking the example provided above: Friendly German units on the flank a mere hundred metres to the right of the village, on another map, cannot, if successfully positioned -that in itself is circumstantial - then bring their fire to bear on the village- assuming they had LOS - until the time of the current game is up when of course we would have to include such a force as a reinforcement or widen the map boundaries itself to include them. Even so, we are not considering that such a RL tactical dynamic would force an allied attacking force to consider their own counter-moves to such circumstances-not at the end of an hour or more but within the scope of the present action. This is what I mean by abstraction of territory. Broadsword I agree, at least in the sense that the shorter the operational decision moves the less abstracted the time lapse would be. Which is why WeGo is not too much of a compromise (it is only one minute after all) but let's imagine a WeGo move were three minutes long, not just a single minute, we the players would surely feel considerably more compromised by that level of abstraction. This is why the WeGo analogy is a nice one it illustrates my point better than the one you raised it for. See, I'd say 15 or 20 mins response time would be acceptable for a decision making at a regimental level (equivalent to your minute WeGo) but this is hardly a practical time scale for fighting large operational affairs. This is what I mean by an abstraction in terms of time. To have to wait an hour for my tanks to finally arrive on my opponent's left flank when they, unknowingly, have already moved unopposed through enemy territory on their own map is excessive. Compounding this problem in any example is the fact that we have two separate but operationally simultanaeous events which we the player must solve in synchronism if we wish to avoid an abstraction of the sequence of events. After much deliberation, I have concluded the only way to practically achieve this is to play multiple battles by multiple players, over 4 hours not 1, with updates and outcomes being fed in a sychronised format, otherwise we cannot replicate the dynamic nature of the battlefield at an operational layer - further abstraction necessary. I realise, as I extrapolate my personal view here, it can be perceived as being negative and overly critical of other's efforts to make something work. Forgive me, that's not my intention. I can see that some players can make it work for them and it's commendable that there are some great minds within the CM community who are able to condense the ideas into something resembling an operational exercise. I'm just tryng to be realistic about the whole issue for the benefits of others who might not be aware of the limitations ("why hasn't it already been done?"). Without the means to modify the .bts save file (which is the technical doorway), we must accept the considerable limitations of what we can currently simulate. What the player considers realistic and acceptable enough for them is a matter of personal opinon/satisfaction. I only wish someone had saved me the time when I was considering the issue by providing me with an explanation of the technical connundrum that I now understand.
  10. This has been discussed many times and something I pondered over a long time when I first discovered CM:BN. Also, I understand that a BF endorsed attempt at an operational CM game was developed for CMx1. The problem is not that there isn't an external game that can be used to simulate the higher operational dimension. On the contrary there are many. In fact there is actually no need to use another game as a vehicle for the operational layer, one could merely use a map and some operational symbols with a basic art editor and move symbols around on a map. And all this without the territorial abstractions of hex boundaries. No that isn't the problem, the issue is this; the current CMx2 file format does not provide the capability to edit an ongoing battle. This creates an insurmountable difficulty because a player is unable to reinforce his forces in the middle of a battle. This means every battle (whether it be a scenario or a QB map) in CM is a separate event; it is isolated from the dynamics of a wider operational front -or actions across multiple maps. There are a number of CM enthusiasts who have made an operational layer work by conveniently ignoring this element of an operational battle (as mjkerner alludes to above) - which is fine if one is willing to accept such limitations and be happy with an abstracted concept. However, for me such a shortcoming leaves much to be desired. :-(
  11. Thanks for that info. I haven't yet played any of these scenarios hence my oversight.
  12. Got me thinking if there are any authentic battle maps or scenarios covering Operation Bluecoat? I seem to have that many maps downloaded or in anticipation of release that I've forgotten if there is one. It would be so useful if the community had a running catalogue of all the maps and scenarios made. Some basic labels such as authentic or fictional and any OOB's and AI plans would be the only other essential info. I'm aware that there is at least one such catalogue of maps on a gaming website but it isn't comprehensive by any means.
  13. I believe it's all there in the v2.00 manual. You'll never take a "Warrior" AAR quite as seriously again...
  14. Interesting reading - thanks for taking the time to translate and write up!!
  15. I still have this one in my scenario folder waiting to play. However I'm wondering whether it will play on v2.01 without any issues? I can't see that there would be any, but always worth running it past the forums first.
  16. Jacksons, Pershings, Jumbos and without doubt the JagdTiger too: I fear the 'Road to Berlin' will aggravate my priapic condition and leave me hospitalised in a persistent drooling stupour. I must stop reading this thread.
  17. Precisely and this was exactly my point! I recall there being another bridge blown in OMG but the demolition was not within the context of a local enemy action attempting to seize said bridge. In any case, seizing bridges before they explode seems to be the type of objective - not to mention dramatic cutscene - associated with other more gamey WWII franchises and I understand perfectly why BF would choose to avoid that kinda' party. Nevertheless, I think Broadswords right - time to move on with more interesting questions and ideas...
  18. For the sake of clarity on this matter: I wonder how many of those listed blown bridges actually occured during a tactical battle John?
  19. My hunch is that persistent damage isn't much of an obstacle for the current game iteration - it's just a case of a tool function that inputs the relevant data from a .bts game save and outputs it as a .btt map file. Perhaps not as straightforward as some might think because there's a lot of data that such a tool must ignore. Still I don't think it's unrealistic - and I certainly want it!! Personally, I don't care how long it takes to develop and release MG, the EF continuation or even SF2. I have so much to get on with BN/C and FI/GL (that I still haven't yet touched). I'd be prepared to wait for MG till christmas if it means it will be vastly superior as a result. In fact I'd quite happily settle for a pack and patch in the meantime. Yes, I'm in the more brigade too but I'm prepared to be as patient as is necessary. Edit:- Sorry I overlooked this: I suspect more people would want this feature than you might think. Do it!!
  20. Shame - but thanks ASL for the info all the same
  21. As Michael Palin would say "You lucky, lucky, lucky B*****D!!" With regard to the various discussions comparing BN/C and FI/GL, I note that noone has mentioned/ or bothers to mention the movie mode. On face value, this appears to me to be a big plus for FI - though I don't yet own it. Can someone confirm that the function is indeed what I assume it is; an in-game screen recorder and editor. If this is the case I might go and purchase FI/GL despite my reduced enthusiasm for this particular theatre. I think such a feature alone is worth the extra play value.
  22. What's wrong with coop multiplayer WeGo? I'd suggest that BF are more likely to implement such a mode than RT at first because code-wise it's a little easier - no need to worry about live multiplayer set up's, connection issues etc.. Moreover, it would provide a good test-bed for in-game multiplayer issues; fog of war, shared off map support etc.. I've been reading elsewhere about speculation of multi -multiplayer RT but in my view 4player WeGo would be a more realistic expectation and would be a fantastic evolutionary move forward.
  23. I had a fav link to this site already but I've never stumbled upon the colour plates at the bottom before. They are a great find in themselves thanks for posting!!
  24. Thanks for replying to my post. I concur with that analysis but that begs the question why is the entire sequence contained in the stock files - normals included. And all community uniform mods have a complete sequence too - has noone picked up on this?? And then, equally, can we be absolutely sure that this is perculiar to the m41 uniform. I do know there is a similar issue with one or two of the german vehicle textures but beyond that I haven't tested with any other textures so I don't know, I'm just posing the question?
  25. This takes us to the kernel of this entire issue: Essentially task-overload for the CM player. This is a relative experience; overload affects individuals at different rates and RT play exacerbates the problem because the RT player cannot possibly perform more or monitor more events than the WeGo player can. This is not an experience that is limited to CM2; the scale of task management the brain can handle in any game is finite. However, it is something that is more apparent in CM2 because of the extension of the game to increasingly larger battlefields and ever larger formations. The splitting of squads only further increases the cognitive demands. The answer however is not necessarily to provide additional information gathering or alerts. The answer is to accept that a company size force is about the maximium that the average player can cope with - certainly in an RT battle. Thus BF should ensure that CM supports multiplayer coop modes in V3.0. This long overdue feature would allow the high cognitive demands of commanding larger formations over larger areas to be naturally dampened by dividing those forces up amongst several players. Personally I don't play RT because this feature isn't currently accomodated, but nevertheless WeGo would benefit from the feature in equal measure for exactly the same reasons. I don't even need to mention the whole new tactical dimension that such a feature would add to the game in any case. If one accepts this premise then my point earlier about the devs using their valuable dev time to enhance the game in other more interesting ways (than the OP suggestion) still stands. :cool:
×
×
  • Create New...