Jump to content

ATG crew small arms fire.


Recommended Posts

Is engine the limited so much, that implementing in a patch "firing from short halts" is impossible ? Just make the tank - moving with "move" or "slow" command, maybe also "quick" (but not on "fast") to stop when it "wants" to fire at a target. Let it run untill the gun is loaded, then make it stop, aim, fire, and move it again untill it reloads.

It should reload 2-3x slower while on the move with "quick comand", and 1.5-2x slower with "move" command. After it reloads and the gun is ready, a halt order is given, after the tank comes to stop - the gunner aims quickly and fires (gunners already are aiming quickly...), then it accelerates again untill the gun is reloaded.

It doesn't sound hard to make such algorithm from programming point of view. It's only combination of existing commands and behaviours depending on already existing in the game conditions.

It would be also good to block pivoting hull rotation of a stopped tank when the tank aims and shoots.

In reality, in 99% of cases there was absolute priority of aiming and firing over positioning the hull, the drivers were strictly ordered to not interfere with the process of aiming and shooting of the main gun. Only the commander could order to abort firing and - for example - move on or back up or rotate instead of firing a loaded gun.

So - if the gunner rotated the gun on target and tank is in "aiming" state, please stop the rotation!

After it fired, the driver can continue to rotate the hull. (

Randomly, once in 10 cases the driver could ignore it and continue rotating - simulating insubordination or poor training or panic :) ).

I have lost quite few tanks (mainly Fireflys) which, after stopping and rotating it's turret at the target that was to side - then it couln't fire at it because the hull continuously rotated and interfered with the aiming procedure, aborting the shot several times. After 10-15 seconds of such pivoting and aiming without a shot, my tank - nearly rotated - was killed by the enemy which finally spotted him, rotated it's turret and fired :). It happened more than once.

Oh boy this can of worms again. Honestly way beyond my ability to comment on having about zilch technical knowledge of what it would take. So instead I'll punt and did what I recall doing last time - defering to Steve.

http://www.battlefront.com/community/showthread.php?t=100325&page=2

edit - for what it is worth the rotating tank pulling the gun off line drives me batty as hell too. :P

Link to comment
Share on other sites

  • Replies 53
  • Created
  • Last Reply

Top Posters In This Topic

(warning: personal opinion below)

Any person having some knowledge and experience in programming, knows that such behaviour is quite simple thing to code - IF only the programmer has al the needed "tools" available for him in the game engine/code.

The problem may be, if (because of the engine design) there is lack of some possibilities (commands, variables) or information (some specific info about other units, some specific info about own unit) available for programmer.

For example, part of code that is "tank" has no easy way of "checking" some info about another unit. Or there is no needed variable. Then a coder have to either modify some higher functions (maybe even core of the game engine) which is always risky, or develop clever workarounds which takes time.

I hope that such fundamental variables like "moving state", "aiming", "loaded", "speed", "engaging a target" and commands like "stop" are so common and easily available that there will be no problem with coding such a sequence into the unit's behaviour - like building construction from already available blocks. Testing should be also relatively straightforward.

Adding a new feature - this is completly different story. Lot's of new code to write, test, fix, test again. Coding a new behaviour for infantry - (like using the windows to get into buildings) would also probably mean lot of coding, testing, and also making new animations, that is also lot of work.

But modyfying behaviour of tanks should be much more easy.

I did such things years ago with behaviours of torpedos and missiles in some simulation game - fixing bugs, and trying to make them them more smart (modes of operations, guidance, sensors, target selection, ECCM), and make them behaving more like real ones (trajectory, speed, maneuverability, range ect). I've also seen the code of the AI routines in some other tank game. There is usually lot of room for improvement, for coding more "smart" and realistic behaviours of AI without adding very much lines, only some smart conditions, randomisers, enchancing existing routines. But there are always limits of what can be done easily - to make more, one has to make greater changes to the code of the game itself... I hope that regarding to improvements in CMBN tanks the BF coders are still on the "easy" side, andy many things in tank behaviour can be improved quite easily, just enchancing the original, basic behaviour code.

Link to comment
Share on other sites

womble,

Am NOT trying to be difficult here. And I have repeatedly detailed the smallness of my sample size, as well as the limits of the particular map and scenario to which I refer. That is NOT to say this a systemic problem for all of CMBN, but for the engagements I've fought, it HAS been a recurring issue. I do hope BFC does something to fix this, because it artificially, in my view, adds to the punch and shock power of the German attack, thus imbalancing the scenario, which is already quite challenging.

dieseltaylor,

You may well be right, but only Guards units got the Shermans, so it's not unreasonable that the gyrostabilizers were kept in repair, particularly since Loza talks about all the manuals and mountains of spare parts, not to mention all the incredible bells and whistles on the tank, to include a Tommy gun, magazines and ammo, not to mention a clinometer better than anything the Red Artillery had. The spare part mountain became evident when large numbers of spares had to be ordered in when a whole batch of return rollers failed unit wide. Loza simply marveled that such a thing was possible.

Regards,

John Kettler

Link to comment
Share on other sites

The comment someone made elsewhere about the firing on the move issue (just read that whole thread from 2011) to the effect that he didn't care, since both sides got the same advantage, doesn't apply, or apply much, when the defenders are static, such as hull down behind a ridge, or ATGs, not to mention outclassed by the opponent's main gun and fairly nasty friends on the ridge or descending same. A Panther firing on the move is hardly in the same league as a Sherman or, worse, an M10 trying to do the same. Tends to be both bloody and militarily counterproductive for the Allies. The approaches are too exposed to fire, so the choice becomes decorate the ridge lines with Allied armor carcasses or move up and have them die there. Am going to see what I can do with an advance behind smoke, praying this'll cancel the German ridge's LOS advantage, but I won't know until I try, will I?

Regards,

John Kettler

Regards,

John Kettler

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...