Jump to content

Kat Johnston

Members
  • Posts

    173
  • Joined

  • Last visited

Posts posted by Kat Johnston

  1. Interesting. Now if that RAM disk software you are using would allow you to start up the image from a file - thus allowing a RAM disk to boot up that already had the game on it that would be something.

    It does, but it takes such a long time to load it that any performance gain for a single run is lost - it makes loading Windows look like loading a CM map - I had to use a 12Gb file for it. For my next trick I'll try a USB 3 stick - but like sfhand I'm worried about upsetting the DRM, even though it doesn't seem to have taken notice so far.

  2. I haven't tried as the disk space on the freeware RAM disk I used isn't big enough to hold CM - I just copied across one of the .brz files and one of the mod tools to access it.

    I think that if you have CM already installed and activated on a machine and you then make a complete copy of the program folder to a RAM disk, you would be able to run it. In the spirit of experimentation I tried making a copy of my CM:FI folder to another location on the HDD and running CM from it - that worked fine (it ran, showed the GL module as installed, and launched a QB). I think therefore that the activation is per machine, not per 'complete installed path on the machine' (that would be kinda overkill anyway!) and that there's nothing in the registry that compels CM to run from the location it was first installed to, which is good.

    Watch this space. :)

  3. Interesting that a RAM disk is twice as fast as an SSD. I wouldn't have expected that. What software are you using for your RAM disk?

    I was using the freeware version of Dataram's RAMdisk. There's a 4Gb cap on the freeware version.

    Bit drastic but might be that with a full CM install onto it it'd be handy for map editing or trying different QB combinations. :)

  4. I am not backing down whether you want me to or not, the old guard mentality here seems to be pretty strong, you do realize being polite to newer players is a good idea, right? I know you live here and own the place, but that is no excuse to be an ass.

    Well said. This place can be reactionary.

    I think some of it stems from earlier times when there were a lot of 'old' CM fans coming on to rant about how awful 'new' CM is. Some of it was justified - CM:SF has needed heavy patching - some of it still is justified, but a lot of it wasn't and it's probably why some people are excessively defensive against any criticism of CM, even though BF make no claim to perfection. (Their approach is a hard-nosed "we do what we can do, when we want to, if we think it'll sell, and we don't do things if we don't expect a return.")

    Anyway, WOOHOO! I was sure I'd read on the forum that GL was the last and only planned module for CM:FI and I'm delighted to learn that that's not likely to be the case. I'm also missing the Italians! :)

  5. I've lined up some Shermans and had them shot at for a bit with a range of Italian weaponry. Had some tanks at slightly different elevations to ensure they were hit all over.

    At very close (200m) range, shooting until ammunition runs out or for up to ten minutes:

    20mm ATR:

    Frontally: is occasionally able to penetrate the lower front hull, but never does any significant damage.

    At 45 degrees sidewards: can score partial penetrations on the upper side hull. Can result in mobility kills if its in a position to hit the wheels.

    At 90 degrees side on: can penetrate the upper left hull and kill the tank given time.

    20mm Breda autocannon:

    Frontally: can occasionally penetrate the lower front hull, can score partial penetrations on the weapon mount. Given time will mobility kill the tank.

    45 degrees: Given time will mobility kill the tank.

    90 degrees: can penetrate the upper left hull and kill the tank.

    37/21 Puteaux: I would have liked to test it, but I couldn't convince my test Renaults to open fire much - for the most part they just sat there with the commander hanging out of the turret. Firing on them with small arms made them button, but that was it. Every now and then one would stir itself to fire, in which case it would bounce off even the side armour - but I didn't see enough volume of fire to judge whether that was the rule.

    37/40 Vickers:

    Frontally: No penetrations, no significant damage.

    45 degrees: Occasionally scores a partial penetration on the upper side armour. No significant damage.

    90 degrees: Can penetrate the upper side armour and kill the tank.

    47/32 cannon:

    Frontally: Can penetrate the lower front hull and can partially penetrate the upper front hull and weapon mount. Given time will kill or mobility kill the tank.

    45 degrees: Can penetrate the upper side hull and partially penetrate the lower side hull, can penetrate the side turret. All my test tanks were mobility killed but not destroyed.

    90 degrees: Can penetrate the side turret and kill the tank. None survived sustained fire.

    65/17 infantry gun:

    Frontally: Can penetrate the front turret and lower front hull with HEAT rounds and kill the tank. There aren't many HEAT rounds so this is rare; the remaining HE is enough to mobility kill the tank given time.

    45 degrees: Can partially penetrate the upper side hull. I didn't test as many of these as of the front armour so its possible I missed penetrations by HEAT. In any case, HE is enough to mobility kill the tank given time.

    90 degrees: Can penetrate the upper left hull and kill the tank.

    75/18 cannon:

    Frontally: Can penetrate the lower front hull, upper front hull and weapon mount, can kill, mobility kill or firepower kill the tank.

    45 degrees: Can penetrate the upper side hull and side turret and kill the tank. None survived sustained fire.

    90 degrees: Can kill the tank. None survived sustained fire.

    90/53 cannon:

    All aspects: Take a wild guess what happens. ^^

    Think I'll do some longer range testing in a bit. I'm keen to find how to stop Shermans reliably with the Italians - the big gunned TDs tend to die in practice 'cause they're too slow to react. :)

  6. Hi. I just bought a digital download version of CM:SF to replace my old Paradox retail version.

    I tried installing on a desktop computer (Win 7 64bit, pretty clean install, Avast); I've had it running on this machine with this OS before. CM:BN+CF and CM:FI but not CM:A are also installed on the machine.

    When I run the installer it completes and installs version 1.11 of the base game. When the game runs it fails with exception code: 0xc0000005

    Event viewer says there is a problem with elicen40.dll

    I am well used to installing CM:SF. :)

    I have tried every combination of patches and modules I can think of, from "base game - no patches" up to "all modules patched to 1.32" but it doesn't look to me like this is where the issue lies - the elicence just isn't starting and this is stopping the game from going further.

    I have been careful to run everything with admin rights.

    I have tried installing to different folder locations.

    I have had a quick trawl through the registry to remove references to Shock Force before trying reinstalls.

    To confirm this (and verify the download, although I'd already taken it twice to check the file size) I tried installing the game on a laptop computer (Vista, 32bit) which was the only other thing I had to hand; it ran fine and started the elicence program at about the part where it crashes on the other machine.

    Can anyone suggest anything (preferably short of "reinstall Windows", which is very much a last resort) to try? Anyone had a similar issue?

  7. If you mean "do I have a clue what I'm saying when I talk about programming, because I suspect that you're not understanding the complexities involved behind the scenes", the answer is "yes, as it happens, I do."

    Facts not in evidence, your honour.

    I do not lie. Least, not about "something dumb like that".

    So here's a couple of short lo-fi videos of a simple little dynamic AI for moving company sized groups to seize exciting little crosses on a big green box.

    You can have the script, if you really want it. It's very bad, and you'll need pygame as well as the standard Python install to run it, but it's fun to mess around with. ;)

    http://www.filefactory.com/file/4nffbjrs1v1b/n/New_15th_B_mpg

    http://www.filefactory.com/file/5kqpboarzuh1/n/New_15th_A_mpg

    (If anyone knows a better file hosting place that doesn't require registration, I'll be delighted to hear it!)

  8. The proposed 'fix' for AI units finding themselves unable to shoot at a target due to elevation limits was something like "reverse 20m". What does 'reverse' mean in this context for an AI controlled Tiger - backwards towards the Sherman, or forwards away from it?

    A proposed fix, which would in some cases allow the unit to get a shot (potentially satisfactory), as opposed to what would presently happen if correct elevation limits were included - the unit would be unable to fire where it cannot aim (not ideal) - and as opposed to what would presently happen without elevation limits modelled - the unit is able to hit where it cannot aim (also not ideal.)

    *shrugs*

  9. @John Johnston: Moving backwards twenty yards would be insufficient in any but the most optimal circumstances. Your system is not generically effective. Just increasing the move distance won't fix it, either; the longer the move is, the more complex the underlying behaviors are going to be, so you might as well make something that provides accurate results most of the time.

    So say we actually create a generically effective system that takes gun elevation into account, among other things - now you're trying to move, in some cases, 40-50 yards backwards in an urban environment whilst still maintaining LOS (otherwise how is that an optimal move for the AI? or is this a behavior that intentionally tries to break LOS?). And *then* the TacAI needs to be taught to use it. And *then* the scripted AI needs to be told that this might happen and given tools to deal with it. And all this for a fairly rare occurrence.

    First, lemme say this - troops at high elevations are generally rare across the whole range of situations in the game - but in a large town, it's common and important.

    My thought was that as there are several things that push a unit out of the position it has been moved to by the player or the AI plan, a (relatively) small backwards move to try for a better shot and/or break LOS with unhittable AT weapons would be just one more among many, not unusual. For trying to hit something (as opposed to avoiding fire, in which case just move back), I guess you could quickly poll a series of points in a direct line away from the target unit for LOS to the target, and if one was available within a certain distance, plot a move to it, and if not, do nothing?

    Ach. Sorry. I know what you mean, I'll shut up. Though right now I'd love to see how the TacAI is written! :D

  10. When I said, and emphasized, 'exactly', it was for a reason.

    I used to program (including wargames) for kicks, for a long time. I guess I understand your defensiveness, given the oddly large number of people who treat this forum as a platform for BF-bashing, but you may note I'm not one of them. CM:BN is an excellent game, but it does have problems. One of the more glaring ones - for a game simulating armoured vehicles fighting in urban areas - is the lack of elevation limits. It is right to raise the issue.

    See the complexity you've just added? It's 'allowed' to, but it doesn't 'have' to. So now we need a decision making algorithm. As well as everything else that needs to be changed.

    If I am trying to shoot something and I can't hit it because the elevation doesn't let me then I need to budge my ass.

    Or if I have LOS to enemy infantry with an AT weapon pointed at me and I can't bring a gun to bear then I need to budge my ass.

    Move how? How fast? Where? Which direction? Which route? What happens when it loses LOS to the target?

    None of this matters much. Move twenty yards away from the enemy. If you can shoot it, good, if you can't, at least you may have made their job harder. The issue is NOT that we need to enable a vehicle to hunt down out-of-reach infantry in any and all circumstances, pursuing its job with guile and tenacity. The issue is that a vehicle shouldn't be able to shoot where it can't, and if it finds that it needs to, it should HAVE A GO at moving a bit to find a shot, in similar fashion to units adjusting their aim when their shot is blocked. If you lose LOS, you lose LOS, no problem. The AI is not clever enough by itself to pursue targets under normal circumstances (which would be difficult, and is a far more serious issue than elevation limits!) so there's no need to mandate that it should be able to in the special case of not having elevation to a target.

    That's nice. Now the game is finely tuned to your preferences. Sucks to be everyone else though, huh?

    Which is why I said my preference, and didn't say "this is how it must be!" Pretty much anything would be an improvement over guns firing at ninety degrees, so it doesn't matter. It's not about my preference - it's about the general preference people have for guns not to fire at ninety degrees to the barrel. ;)

  11. Did you go to the same design school as Diesel?

    If you mean "do I have a clue what I'm saying when I talk about programming, because I suspect that you're not understanding the complexities involved behind the scenes", the answer is "yes, as it happens, I do." ;)

    What does 'free to', 'alter their position' and 'if they need to' mean, exactly, in this context?

    'Free to' - is allowed to move. In much the same way that at present a vehicle is 'free to' move if it comes under fire.

    'Alter their position' - move. In much the same way that at present a vehicle 'alters its position' if it comes under fire. ;) It doesn't have to be complicated - the vehicle doesn't necessarily even have to "think" about where it is moving to - and it doesn't have to be far. Think "if you can't immediately hit this target because of elevation, move ten yards away from it and try again." It does not have to mean a straw-man "if you can't hit the lone infantryman in the building next door, abandoning all reason and in preference to doing anything else you must career wildly across the map getting shot at." :)

    Though units often do exactly that when they come under fire - reversing wildly, flailing around seemingly in an attempt to present their weakest armour to as many possible enemies as possible. Reminds me of Carius's "and then after they were shot at the greenhorns turned their shiny new Jagdtiger around to run and were immediately destroyed" anecdote.

    'If they need to' - comes down to aggression. Personally I'd set it very low, and have vehicles allowed to move to engage only if the infantry pose a threat - that is, only if the infantry are either within a very short distance or if they are armed with AT weapons. In other cases, it'd be the player's problem and job to move the vehicle, and the AI could continue bungling along as it always does.

    What I'm suggesting is basically that in most cases, units would just find themselves unable to hit things they should not be able to hit, and when in clear danger ("does target have an AT weapon pointed at me") they should move away in an attempt to give themselves a shot. It's not a major reworking of code.

    As far as enemy armour goes, implement elevation limits and leave it. If they can't hit, they can't hit and it's a rarer situation because armour, like daleks, can't climb stairs. Again, if a player-controlled vehicle ends up in some odd reverse-slope situation it's the player's problem, and the AI can continue bungling along.

    How would this putative behaviour interact with succeding AI orders?

    In exactly the same way that units moving after they have been shot at, or routed, or whatever interacts with succeeding AI orders. As you know, units aren't always in the exact place the AI designer expects (which is in any case an area rather than an exact location) and they aren't always in a condition to carry out the next move immediately if they're in a panic.

  12. Elevation should be implemented for tank MGs and tanks could simply ignore infantry they can't hit. It'd still be a little odd, but not as silly as tanks firing underneath themselves.

    And heck - why not give diesel's suggestion a go? AI units following a move order can be exempted until they finish the move; once the move is complete they can be free to alter position if they need to.

×
×
  • Create New...