[WARLORDS 2.08] Ranged Bombardment

[OrionVeteran]

Name one MBT that can engage beyond its line-of-sight.

Exel,

I'll give you two modern battle tanks that have the capability to engage targets beyond line of sight:

M1 Abrams
M1A2

Read: The MRM-KE (Mid-Range Munition - Kinetic Energy) is a 120mm precision guided munition for use by the M1 Abrams. The missile/projectile is designed to be used as a high velocity penetrator at both line of sight, and beyond line of sight (BLOS).

http://www.defense-update.com/products/digits/120MRM.htm

"Raytheon Projectile Scores a Direct Hit Against Moving T-72 Tank" Sep 2006

Raytheon successfully conducted the first beyond line of sight mission with a test firing of its Mid Range Munition Chemical Energy (MRM-CE) guided projectile with digital semi active laser sensor. The projectile, fired from an Abrams M1A2 SEP (system enhancement program) tank, scored an extended-range, guided direct hit. The test firing at the U.S. Army's Yuma, Ariz., Proving Grounds demonstrated the laser-guided seeker's ability to successfully target, acquire and track a moving tank and guide the munition to intercept at a distance of 5.4 miles (8.7 km).

http://www.spacewar.com/reports/Raytheon_Projectile_Scores_a_Direct_Hit_Against_Moving_T_72_Tank_999.html

Also read about Extended Range Munition [ERM]
XM1007 Tank Extended Range Munition (TERM)

The Tank Extended Range Munition (TERM) is a new 120 millimeter munition for the M1A2 Main Battle Tank, that will extend the maneuver commander's battlespace beyond line of sight (BLOS) to more than 8 kilometers.

http://www.fas.org/man/dod-101/sys/land/erm.htm

If these factual references don't convince you, then nothing will. As for me, I'm convinced of the capability and I have chosen to change the mod to give the Modern tank a 1 square Ranged Bombardment capability. You don't have to make the change if you don't want to, as the change is only a suggestion.

Dale, once again, thanks for a great mod.

Very Respectfully,


Orion Veteran

 

[Exel]

None of those rounds are in service, and it is not even sure if they ever will be employed to the Abrams. They are primarily intended for FCS platforms. They can be equipped to the Abrams as well (your own sources state this is a possibility) but that will require some modifications in the tank.

 

[Dale]

Guys, I think it's time to stop thread-jacking.

Thankfully I've designed the mod openly so that you CAN make these changes if you want. If you don't want, then that's okay.

 

[Exel]

Guys, I think it's time to stop thread-jacking.

Just bumping the thread up.

 

[OrionVeteran]

Exel,

Last word: In my humble opinion, if a Trebuchet, with 300 yard range, can have ranged bombardment of 1 square all around, then I see no reason not to give modern armor, with direct line of sight range capability, far beyond 300 yards; the same 1 square capability. As for BLOS capability, if it is available to a commander, he will use it to his advantage in the field of battle. ...and so would I.

Guys, I think it's time to stop thread-jacking.
Thankfully I've designed the mod openly so that you CAN make these changes if you want. If you don't want, then that's okay.

Bottom Line is: I agree with Dale. The mod is so good, it allows changes to modify unit capabilities to match player preferences. Make any changes you, as the player of the game, desire! After all, CIV4 is a great game and the objective is to have fun.

Question to all: Does anyone have the code necessary to add The Privateer to this mod? ...and can you please post the code and/or files?

Very Respectfully,


Orion Veteran

 

[cf_nz]

Dale

I've merged your ranged bombardment mod with the BetterAI mod. I've started to experience crashes of late and I think a recent change in BetterAI is clashing with your mod. I have made an assert build (note I'm only vaguely aware of what I'm doing) and am getting an assert error in CvUnitAI.cpp; Expression: pDefender != NULL; this is part of bool CvUnitAI::AI_bombardCity().

What sort of errors would trigger this assert?

Many thanks.

 

[Iustus]

Dale

I've merged your ranged bombardment mod with the BetterAI mod. I've started to experience crashes of late and I think a recent change in BetterAI is clashing with your mod. I have made an assert build (note I'm only vaguely aware of what I'm doing) and am getting an assert error in CvUnitAI.cpp; Expression: pDefender != NULL; this is part of bool CvUnitAI::AI_bombardCity().

What sort of errors would trigger this assert?

Many thanks.

I responded with some thoughts on how to fix this bug over on the BetterAI post.

-Iustus

 

[Iustus]

I've tested this, and the AI does bombard my units in the open (for collatoral). There's no collatoral whilst bombarding cities, it's defense reducing only. Also, the AI does bombard tile imps as well.

I've just tested all of this, and the AI is picking all three situations for the mission. Even as far as AI battleship coastal bombarding.

Just a question, can you bombard other things than cities? The only thing I can of is either the AI in your game hasn't seem anything more attractive than cities, or the mod isn't installed correctly for you.

Yes, the intention was to do collatoral damage.

The AI actually uses the same mission code as the human, so it can do collatoral damage. It's just the AI is deciding that frontal attack is more beneficial to it than continuing bombarding.

Does it follow up the frontal attacks with other units to try to finish you off?

(Forgive me if you have already done these, I have not looked over the code of this mod)

If you want the AI to get the best out of this, you probably want to look at changing the AI to have a much lower chance to attack with a bombard unit, when you could just bombard and not die, you could do in one or more ways:
- change getBestAttacker to return non-bombard units first
- change AI_attackCityMove and AI_attackMove to better deal with this new technique, probably splitting up groups into bombard groups and actual attack groups (you will want to leave behind defense on the bombard groups)
- change AI_cityAttack, AI_anyAttack (and AI_stackAttackCity in BetterAI) to know about ranged bombarding, spliting groups as necessary
- change bombard units so they cannot be UnitAI "city attack", but rather are both collateral and probably counter (and city counter). (AI_unitValue)
- change both groupAttack, AI_update, and AI_follow to know about splitting groups to bombard with those that can not bombard.

Probably a few more things I am not thinking of right off the bat.

One thing you do not want to do is to change AI_groupFirstVal to have bombard units come after non-bombard units, because in a mixed stack, you still want the bombard units to go first. You just do not want them to move first. Overall, I think the best solution is going to involve splitting the groups up.

In an ideal world, there would be a new MissionAI you could use for bombard groups, so they could get their own defenders, could shadow attack groups, and provide support. You could mimic this without your own MissionAI by just doing a check at the top whether the top unit in a group can bombard, and calling something like AI_bombardAttackMove rather than AI_attackMove or AI_attackCityMove. Of course, this does not solve the problem that you want to work on defense as well. Perhaps a AI_bombardDefenseMove also, or just incorporate the defensive logic into AI_reserveMove, AI_counterCityMove, and AI_collateralMove

-Iustus

 

[Dale]

I posted this in another thread, and place it here for reference:

----------------------------------------------------------------------------

Actually, the problems with that posted code go a lot deeper than you think. It's got nothing to do with how AI_BombardCity() (my one) works, but calls to it from other areas of the AI.

I post the CvUnitAI.cpp changes required here:

Add the following to (near the top, under the Heal() call):

		// Dale - Field Bombard: START
		if (AI_bombardCity())
		{
			return;
		}
		// Dale - Field Bombard: END

- AI_attackMove
- AI_attackCityMove
- AI_cityDefenseMove
- AI_cityDefenseExtraMove
- AI_attackSeaMove
- AI_assaultSeaMove

In AI_anyAttack comment out the line: if (iValue >= AI_finalOddsThreshold(pLoopPlot, iOddsThreshold))

In AI_anyAttack change the pBestPlot check to:

	if (pBestPlot != NULL)
	{
		// Dale - Field Bombard: If odds are right, attack, else field bombard
		if(iBestValue > iOddsThreshold)
		{
			FAssert(!atPlot(pBestPlot));
			getGroup()->pushMission(MISSION_MOVE_TO, pBestPlot->getX_INLINE(), pBestPlot->getY_INLINE(), ((bFollow) ? MOVE_DIRECT_ATTACK : 0));
			return true;
		// Dale - Field Bombard: new method
		} else if(DCMFieldBombard) {
			if(canBombardAtRanged(pBestPlot, pBestPlot->getX_INLINE(), pBestPlot->getY_INLINE()))
			{
				getGroup()->pushMission(MISSION_BOMBARD, pBestPlot->getX_INLINE(), pBestPlot->getY_INLINE());
				return true;
			}
		// Dale - Field Bombard: old method
		} else if(!DCMFieldBombard) {
			if(canBombard(pBestPlot))
			{
				getGroup()->pushMission(MISSION_BOMBARD);
				return true;
			}
		}
	}

In AI_followBombard change the bombardCity check to: (this is the one that causes the crash)

	// Dale - Field Bombard: different AI checks under each method START
	if(DCMFieldBombard)
	{
        if (AI_bombardCity())
		{
			return true;
		}
	} else if(canBombard(plot())) {
		getGroup()->pushMission(MISSION_BOMBARD);
		return true;
	}
	// Dale - Field Bombard: different AI checks under each method END

That'll do it. Just so you know, I've successfully merged ranged bombard with Better AI and it works seamlessly with no errors. Just need those fixes.

Dale

 

[cf_nz]

Just so you know, I've successfully merged ranged bombard with Better AI and it works seamlessly with no errors. Just need those fixes

Many thanks Dale. I've been using your Ranged Bombardment mod for a long time without any problems (including with BetterAI). The crashes only started occurring about a month ago.

Edit: I've made the appropriate changes to:
- AI_attackMove
- AI_attackCityMove
- AI_cityDefenseMove
- AI_cityDefenseExtraMove
- AI_attackSeaMove
- AI_assaultSeaMove

The changes listed to AI_anyAttack and AI_followBombard were already part of CvUnitAI.cpp as they are part of your mod.

 

[Iustus]

That'll do it. Just so you know, I've successfully merged ranged bombard with Better AI and it works seamlessly with no errors. Just need those fixes.

Even with all the changes you list, I think more can be done.

In BetterAI you will tend to get relatively larger mixed city attack stacks. I could be mistaken about this, but I believe that in general what is going to happen is that if the stack decides to bombard, then that is all it will do that turn. AI_follow logic, even if it does result in some attacks, they will be much less directed than the attacks generated in AI_attackCityMove. But a mixed stack will never get to that code, because it will always trigger a bombard.

The reason for this is the action of the whole group is determined by the head unit of a stack. And unless the whole stack can still move, the only chance for any of the other units to take an action is through AI_follow, which as you can see by looking at it, has a lot less logic than AI_attackCityMove.

I think you might get better use of units that can field bombard if you made some bigger changes in the AI logic of these units, as I suggested above. I think the best approach might be to change the calls to AI_group and AI_groupMergeRange so that you can build stacks that have bombard units and stacks that do not have bombard units, and use the bombard stacks for bombardment, but not for direct attacks. (I have not used the mod, so I do not know whether or to what percent field bombardment is less effective than attacking with a collateral unit, this would affect this of course). My general feeling though is that if you can get nearly the same effect as suiciding a collateral unit by bombarding with it, that might be the way to go.

Changing groupAttack to have bombard units bombard rather than attack when the odds are low: changing the logic so that it checks for a bombard unit in the stack before looking for bestGroupSacrifice, and generates a bombard action rather than an attack might also work, although its a bit tricky because you cannot push a mission at that point, you would have to call the bombard function directly. I am not certain what effect that has on isBusy, you might need to make some changes there, so that the right animations are drawn before the next unit acts.

-Iustus

 

[Dale]

Let me just say, that I spent 12 months messing around with groupAttack (for my true stack attack component) and it's a nightmare.

I ain't going there again for quids!

But if you want, be my guest.

BTW, in my true stack attack, bombarding units actually did bombard (and animate as such) as well as ranged units range attacking (and animate). Unfortunately due to not having access to how GameBryo releases an animation, there are a couple of unsolvable bugs. So dev stopped on it.

 

[Iustus]

Let me just say, that I spent 12 months messing around with groupAttack (for my true stack attack component) and it's a nightmare.

I ain't going there again for quids!

But if you want, be my guest.

BTW, in my true stack attack, bombarding units actually did bombard (and animate as such) as well as ranged units range attacking (and animate). Unfortunately due to not having access to how GameBryo releases an animation, there are a couple of unsolvable bugs. So dev stopped on it.

I am not sure what your true stack attack component did, but BetterAI has made some significant changes to groupAttack. Including the following two things:

(1) if the odds are low enough, rather than using the bestGroupAttacker unit, it substitutes bestGroupSacrifice unit.

(2) if there is more than 1 unit in the group, it sets m_bGroupAttack using CvSelectionGroupAI::AI_queueGroupAttack(int iX, int iY), which is then used the next time around in AI_update to short circuit decisions on what to do next. This causes it to follow through and attack with an entire group, choosing the best sacrifice or attacker as appropriate without having to go through the logic of AI_follow (which it still does in the cases where it did not attack).

(3) groupAttack now returns whether an attack failed because there is an animation currently playing, so AI_update can abort, and return and wait until the animation finishes before trying groupAttack again.

While these changes were problematic at first, because of how convoluted the whole thing is, they now work pretty solidly.

-Iustus

 

[Dale]

I am not sure what your true stack attack component did, but BetterAI has made some significant changes to groupAttack. Including the following two things:

(1) if the odds are low enough, rather than using the bestGroupAttacker unit, it substitutes bestGroupSacrifice unit.

(2) if there is more than 1 unit in the group, it sets m_bGroupAttack using CvSelectionGroupAI::AI_queueGroupAttack(int iX, int iY), which is then used the next time around in AI_update to short circuit decisions on what to do next. This causes it to follow through and attack with an entire group, choosing the best sacrifice or attacker as appropriate without having to go through the logic of AI_follow (which it still does in the cases where it did not attack).

(3) groupAttack now returns whether an attack failed because there is an animation currently playing, so AI_update can abort, and return and wait until the animation finishes before trying groupAttack again.

While these changes were problematic at first, because of how convoluted the whole thing is, they now work pretty solidly.

-Iustus

It does what I believe should've been done to start with.

http://forums.civfanatics.com/downloads.php?do=file&id=2509

 

[Iustus]

It does what I believe should've been done to start with.

http://forums.civfanatics.com/downloads.php?do=file&id=2509

Well, looking at what your combined attack does, you might want to take a look at we do in BetterAI with m_bGroupAttack and returning bFailedAlreadyFighting. Using this technique, you should be able to do one phase of your attack inside groupAttack, then set up some variables in the same way (probably just add in a pointer to a struct/class in CvSelectionGroup showing what phase of the stack attack you are in), and you should be able to trigger re-calling groupAttack when the animation is done drawing (assuming that is the problem you ran into).

The calling chain looks something like this for BetterAI:

1. CvPlayerAI::AI_unitUpdate calls CvSelectionGroupAI::AI_update
2. CvSelectionGroupAI::AI_update called for a group that is going to attack
3. pHeadUnit->AI_update() pushes a MoveTo mission, calling
4. group->groupAttack which does the first attack, if an AI stack sets m_bGroupAttack true and stores the x,y coords, and returns
5. CvSelectionGroupAI::AI_update loops again not calling pHeadUnit->AI_update() when m_bGroupAttack is true, but calling groupAttack directly, with those x,y coords,
6. groupAttack finds the next unit to attack, then sees that there is already fighting going on in the target plot, so it sets m_bGroupAttack to true, returning bFailedAlreadyFighting true
7. CvSelectionGroupAI::AI_update bails out, giving up on that stack for now
8. CvPlayerAI::AI_unitUpdate bails its loop, it will be called again after the animation is finished
9. CvPlayerAI::AI_unitUpdate called again, even if the head unit was killed, it will not separate an AI group until m_bGroupAttack is false, to let the group continue to attack until there are no more foes.
10. repeat 5-9 until either there are no more foes (which will bring us back to step 1), or no more units in our stack (stopping after 4)

I am not sure what bugs you ran into, but if it had to do with not being able to trigger one animation, then wait to do the next one, we solved that for BetterAI.

-Iustus

 

[Dale]

The actual bug was if you queue up two animations for the one unit (IE: two rounds of combat) then the second would fail to respond back from GameBryo engine. This is only in the case where a ranged unit would be in battle with either a melee or air unit.

Anyways, I'd love to re-look at this mod again, but right now I don't have the time.

 

[Iustus]

The actual bug was if you queue up two animations for the one unit (IE: two rounds of combat) then the second would fail to respond back from GameBryo engine. This is only in the case where a ranged unit would be in battle with either a melee or air unit.

Anyways, I'd love to re-look at this mod again, but right now I don't have the time.

Fair enough.

It does sound like the solution I worked out for BetterAI would work for you. Since we specifically do avoid queueing up two animations. (By only doing one, then falling all the way back through the calling chain, but shortcircuit our way back to groupAttack once the previous animation is finished).

-Iustus

 

[GyroLeader]

Is any way to get this mod work with Modern Warfare mod? I tryed but i just error messages. If there is a way, could somebody tell how?

Sorry for my bad english.

 

[ebo]

I merged this bombardment mod, with my other mods it all worked great. I had a little trouble figuring out what was changed on the civ4missions.xml, because there were no comments, but I got it working, by replacing the bombard section of yours into mine. Thanks for a great addition to civ4.

ebo

 

[garillo]

Great job Dale. Makes an excellent game even better.