Jump to content

Mad Mike

Members
  • Content Count

    337
  • Joined

  • Last visited

Everything posted by Mad Mike

  1. I already had a deeper look into this and believe it can not be done easily. As you've already found out, the way the data is saved into a "btt" file changes every time. My best guess is that the data is encrypted (with a fast and easy algorithm) which still makes it very hard to read the files. Why this has been done to the "normal" files and not just the "ema" files for H2H games, I can not really say. Maybe you can get someone from BFC to comment on this. Overall I would say that most likely you would be wasting your time without being able to achieve even the simple goal you described.
  2. This bug is so ancient and has always been around. The problem is that it is not reliably reproducible, as can be seen from the description. But it happens and gets mentioned a lot on wargaming club sites like the FGM, for example. One factor in the appearance of the bug could be that two different instances of CMBN are used in the process instead of (most likely) just the same running instance when testing this on one computer. Why it would be this way, I don't know, but it could be a factor in the overall problem since it seems to work as intended when tested on only one computer. Also, it mostly happens when there is a german attack/assault/probe involved. The reason for this is simple - there are less QB maps available where the germans are the attacking side and the automatic selection will also choose QB maps where originally the Allied side is defined to attack. Supposedly, the game should still recognise the switch of the attacking / defending sides as opposed to what is defined via the editor, but this does not happen reliably. My advice is to select the maps manually when playing as the german attacker and to make sure that it is an original "german attack map".
  3. On the face of it, it might seem flabbergasting. But you have to keep in mind how campaigns are handled. The campaign file (.cam file) contains all scenarios which are part of the campaign. If you do a save at any point during the campaign, the created .bts file will contain all scenarios which are still potentially ahead of the player in the campaign flow. This can be verified if you look at the size of your campaign save files, which get progressively smaller the further the player progresses in the campaign. For a PBEM of the Scottish Corridor (.cam file size approx. 57 MB) or Kampfgruppe Engel (.cam file size approx. 33 MB) this could give turn files of up to 70 MB. This could have been a consideration of BFC when they decided not to allow campaigns for PBEM or RT. Of course this could be handled today since most players (not all, I know) will use dropbox and H2HH. It would still be a massive amount of data and most of it would not even be useful to the particular battle.
  4. Yeah, I'm afraid the manual is to be interpreted as "RT and Wego for Single Player only". If you try to start your Eternal campaign, you will see the options available: - 1 Player PBEM - 1 Player RT - 2 Player Hotseat The interesting options for 2 Player games are greyed out and can't be selected. Well, it was a nice idea anyway...
  5. No, damn, of course you're right Ian. Can't play via PBEM or RT, only Hotseat is allowed. So I guess that rules out any multiplayer tests.
  6. Sounds ideal, you can set it up and send me a dropbox invite, my EMail can be found over at FGM.
  7. OK, had a look, there were some problems with the script, most noteably a strange "line termination" at some of the lines in the script file (very likely, those were responsible for the crash). Also, I deleted all the spaces between the [markup] and the actual content (probably not really necessary). Lastly, I renamed the battles to get rid of the hyphens ("-") in the names, since this will produce an error as well. The result can be checked here, a campaign file, which I also checked with my "Scenario Organisor". It should work, I guess: https://dl.dropbox.com/u/30942618/eternal_MM.zip Of course all the inputs are attached as well, so you can try and change it for yourself.
  8. Hi poesel, I can confirm that your campaign crashes CMBN . I will have a look and see if I can provide any help. The concept could be quite interesting, maybe if we get it to work, we could test it with a very small force to assess its feasibility? Cheers, Mike
  9. JonS is right, the campaign script is not part of the .cam file in its original form. It is just a set of instructions for the campaign generation process of CMx2's scenario editor how to create a campaign. Thankfully, the important information will be written into the .cam file in directly readable format, i.e. it is not encrypted.
  10. I don't know, it is quite uncommon, for games at least, to have a specific download charge applied to them. The cost for providing an infrastructure is certainly included in the full price for the license, i.e. it is hidden, but it will have been calculated. I guess what BFC must have calculated is the cost for them for the expected number of customers downloading the installer 10 times. I know for sure I only downloaded CMBN and CMFI exactly one time, so I paid for 18 downloads (and the associated bandwidth) which I never used. I would be more than happy to share these with anybody whose download expired. I would also bet that I'm not the only one never used all the downloads. Just something to take into consideration when talking about numbers and cost.
  11. From what I understand from Schrullenhafts post, the $5 fee is to cover download costs, which is fair enough. But you don't purchase such a thing as a "download license". You purchase a license to use the program called CMBN, how it arrives on your computer is quite secondary to this purchase. The limitation introduced by Battlefront is purely there due to cost issues since they are not in the mass download provider market. But in theory it should be ok to share an install image of CMBN since without a valid license key it would be unuseable. This is of course assuming that the license/activation scheme used has not been compromised.
  12. Artofwar, you could use the tool I created, see my signature for links to BFCs repository and GreenAsJades Mod website. It will extract all individual battles from the campaigns and will tell you the settings for each battle (basically what the campaign script does, which a campaign writer has to create when the campaign is produced - see CMBNs manual for details). This would allow tweaking of single battles and, if you wanted and had some time, rebuilding of these changed scenarios in a new campaign. V2.0 should have no impact on the tool, since I think no camaigns have been updated for V2.0 and the tool seems to function with scenarios created under V2.0. Cheers, Mike
  13. One final comment (hopefully, I can already hear people groaning ). I cut you slack for bugs, they do happen. But I would never go so far as saying that I'm not unsatisfied by them being in the product. Also, after reflecting what has been written here over the past days, this discussion for me is not about comparisons and what other companies, which sometimes make shiploads of money, do equally bad, but what you - Battlefront - could do better. I understand now, as a result of this discussion, that you don't see any way of expanding your automated testing. This is due to constraints in resources/budget and a perceived return on investment which is too small. But pointing to others as examples for bad practices and things gone wrong to paint own mistakes in a better light is not really a constructive way of thinking. That's why I tried not to compare and rather speak about general principles. I can see that this seems like preaching about theory, but it is the only starting point really. In my opinion, it is fair enough to say: "In principle, automated unit testing helps the developer to create cleaner code and enables him to implement and check changes reliably and quicker, especially for unintended side effects in the code unit behaviour. Due to the special nature of the software project under development and a resource/budget constraint, we made the decision to not do this and try to ensure overall quality by other measures". It is not fair enough to say: "Since NASA uses automated testing and they still had bugs, this whole automated testing stuff can not be worth much and we should therefore not do it." It is simply a wrong argument since it completely neglects that the automated testing has probably caught thousands of smaller and bigger bugs and errors in this NASA project and the "metric and English values" anecdote is rooted in faulty application of specifications. After reading the wikipedia entry about this example, automated testing could have picked this up - but was probably not implemented correctly. Still, this discussion has been worthwhile and educational for me, since I now understand your way of working a little bit better. I still don't agree with the automated testing part of it, but it's of course not really my concern.
  14. Automated testing, especially for games, is not superior in any way to testing by users. If you interpreted my comments in this way, I can only clarify that automated testing can complement the testing by the users already in place, ensuring that certain bugs will not reach those users so that they may concentrate on testing the integrated product. I hope this is an understandable way of approaching software testing - testing from small chunks or individual parts towards more complex, user driven testing of the whole game. I wouldn't say my dissatisfaction is petty. I just don't agree with the "release it now, fix it later" mentality from a customer point of view, which is hopefully quite natural. Wholesale subscription to this approach as a customer, no matter which game developer does it (and they all do in these days), I would describe as "gullible".
  15. Steve, thanks for the reply. For the sake of letting you get back to work instead of arguing with me, I can only say that I have to remain one of your unreasonable customers. I hope you can agree that this is certainly not the worst imaginable outcome of this small debate.
  16. Sorry for the double reply, but if I may be allowed to try to summarise your point of view on this, I would say that: You are quite happy with the stability and bug-to-feature ratio of the game. All bugs, should they occur, are collateral damage which can not be avoided in any way given the constraints and even if they could be avoided, it doesn't matter since the customer actually accepts this state of affairs and any further modification of the way you're testing is therefore not necessary. I would not agree with this as there are always measures for improvement, a defined set of "test points" or (even selective) automated unit testing being two of them. If my summary is incorrect, I would like to know where I misinterpreted what has been said.
  17. That would not be good enough for me, but of course I'm not going to tell you how you should run things. I can only tell you that I'm not really satisfied with the final result with regards to stability and fatal, game-preventing bugs. That would be an interesting survey. I am not sure one way or the other. But I would definetely like to see some survey like this.
  18. I actually did not try to be ironic. I really believe that something like this would cripple your ability. So there is no argument here. Things are the way they are, especially real constraints like time and resources. But style follows needs and resources, surely. And statements like " I am telling you, emphatically, that automated testing is NOT DONE." are not mine (also, admittedly, not yours). But we can only discuss things which are being stated, so maybe some care should go into these statements. Sure, as I'm the customer and not involved in your development. The bugs which remain are all I have to go by in my judgement. As such, I'm not satisfied with the bugs which are in the game. Nothing more, nothing less. But those bugs I mentioned should have been caught, especially since they are in areas which are common in a lot of typical games of CMx2. Start a QB via PBEM and check if everything works. Create a map with every terrain feature and placeable object (mines etc.) and check if everything works, in play. I apologise for the quoted "QA", it was indeed a cheap shot on my part. I'm interested, does your QA have a catalogue or list of points and functional areas (user workflow) of the game which have to be checked before the game or a patch is released?
  19. Should not make a difference .. are you sure you both are using the same versions of the game? What you're describing sounds like a version mismatch.
  20. You're in the software engineering business as well, which is quite universal in its principles. The basic failure or bug causing reasons are the same for every piece of software, no matter what it is programmed to do. I also think you don't have a clue about programming or software engineering, but of course you have huge experience as a game designer, which I'm obviously not questioning. I know more about software engineering than you, without a doubt. About game development, not really .. but in the end it is all software development which follows universal principles. Just because it is a game doesn't make it so special - that's just a chip on your shoulder. Nope, still quite the opposite, while Phil's response was quite balanced even with the admission that some automated testing seems to be done already, yours is still trying to paint everything in black and white with the justification that your software product is a game - which doesn't really matter.
  21. I can believe that it would cripple your ability. I didn't make any assumption on any specific bug being caught be automated testing. But it will catch bugs, including some which will have an impact on the overall stability or gameplay. So you do test automatically after all .. why is that, if it doesn't suit your development style? Yeah, but in your special case the "QA" is just not working so well - barbed wire crashes, quick battle crashes, wandering crewman .. not a track record show case advocating the QAs effectiveness.
  22. 100% agree with you. Steve doesn't know what he's talking about here, and it's actually embarassingly obvious and painful to read - for every software engineer with some experience who has ever worked on big projects in the real world. Mind baffling response by Battlefront, really. :eek:
  23. I agree, cases can be constructed ad infinitum to argue for or against automatic behaviour like the one I described. So I'm not really expecting this behaviour to change. Yeah, but real human beings would try to kill the TC (if they perceive a good opportunity) and then try to stay alive. They wouldn't be thinking "Oh, I will be staying here no matter that there is a tank 100m away which now knows, with high probability, where I am. If it should proceed to shoot me, well then, that's fair enough..". But basically I still agree with you, I don't think we will see this kind of sophisticated Tac AI behaviour in CM for some time, if ever. I don't agree that the current controls are an adequate solution to the general problem though. But, after all, it's just an (imperfect) game.
  24. The shooting part is not so bad, but as soon as the result has been achieved - either a killed TC or buttoned-up tank - the infantry should change its place .. automatically. If they are in a house, get out of it (behind it). At least that would make it more realistic. And the player can not always intervene when stuff like this happens early in a turn (assuming WeGo PBEM, for example).
×
×
  • Create New...