Naval Mines

You've got several syntax errors in there (def vs. Def, must have () after kill call), and it doesn't use upgrade (but maybe that's okay), but it looks okay at first glance. Better to run it and see what happens. :)
 
You've got several syntax errors in there (def vs. Def, must have () after kill call), and it doesn't use upgrade (but maybe that's okay), but it looks okay at first glance. Better to run it and see what happens. :)

Will do. I'll post the results tomorrow or should I say later today.

Thanks,

Orion Veteran :cool:
 
You've got several syntax errors in there (def vs. Def, must have () after kill call), and it doesn't use upgrade (but maybe that's okay), but it looks okay at first glance. Better to run it and see what happens. :)

Here are the results: I get the following error:

Code:
Traceback (most recent call last):

File "CvScreensInterface", line 657, in handleInput

File "CvMainInterface", line 3207, in handleInput

File "MineWarfare", line 237, in ActivateMine

ArgumentError: Python argument types in
	CyPlayer.initUnit(CyPlayer, CyUnit, int, int, int, int, CvPythonExtensions.DirectionTypes)
did not match C++ signature:
	initUnit(class CyPlayer {lvalue}, int, int, int, enum UnitAITypes, enum DirectionTypes)

As you know, line 237 reads:

Code:
pPlayer.initUnit(iUnitUnArmedNavalMine, iPlotX, iPlotY, DefaultUnitAI, DirectionTypes.NO_DIRECTION )

Not sure how to fix the types.
 
Weird, the error makes it look like it knows what to do, but I see a problem it's not reporting.

Change

Code:
DefaultUnitAI = "UNIT_AI_ATTACK"

to this

Code:
DefaultUnitAI = UnitAITypes.UNIT_AI_ATTACK

According to the error message you are passing in pUnit as the first argument, but I don't see it in your code. Did you change it from what you posted earlier?
 
Weird, the error makes it look like it knows what to do, but I see a problem it's not reporting.

Change

Code:
DefaultUnitAI = "UNIT_AI_ATTACK"

to this

Code:
DefaultUnitAI = UnitAITypes.UNIT_AI_ATTACK

According to the error message you are passing in pUnit as the first argument, but I don't see it in your code. Did you change it from what you posted earlier?

Yes I did use pUnit as a test, after the first failure, but it didn't work. So I posted the first error.

Did what you asked and got this error:

Code:
AttributeError: type object 'CvPythonExtensions.UnitAITypes' has no attribute 'UNIT_AI_ATTACK'
 
As for setImmobileTimer(), I would guess that's used by the events that allow you to choose to have a unit in the city remain "busy" for X turns to handle guarding the food or whatever. It counts down every turn until it reaches zero and then makes the unit mobile again. While you could use this by setting its value to 10000000 or something that will never reach zero, I think I prefer creating a new unit instead. It allows you to have different graphics, too.
 
As for setImmobileTimer(), I would guess that's used by the events that allow you to choose to have a unit in the city remain "busy" for X turns to handle guarding the food or whatever. It counts down every turn until it reaches zero and then makes the unit mobile again. While you could use this by setting its value to 10000000 or something that will never reach zero, I think I prefer creating a new unit instead. It allows you to have different graphics, too.

Agreed. I prefer the new unit solution over the setImmobileTimer() solution.

I just finished testing the nuclear mine.

1. I moved an unarmed nuclear mine to the plot where I wanted it.
2. Then I clicked on the arm naval mine button to arm the nuclear mine (now it can no longer move). Yippee!
3. After arming the nuclear mine the detonation button appeared.
4. I detonated the nuclear mine which blewup every ship on the plot. (I used World builder to put the ships there for the test)
5. The mushroom cloud looks great.

It is hilarious! I like it! ...good explosive fun!

Now all I have to do is make all the same changes for the land mines, put the mod through more testing and release it.
 
OK now that all of the mine warfare units have been built, it is time to determine how the AI should use mines. I have come up with the following:

1. Can't arm a mine within an enemy's cultural borders. You can pass through the territory, but can't arm the mine until reaching a plot outside of the cultural border.

2. Prime spots for arming a mine:

....a. Geographical choke points
....b. Recommended plots to place a city.
....c. Plots with strategic resources

Question: Where can I find the code that identifies the recommended city plots for settlers? Is it in SDK or is there a python function that makes the determination and displays a circle on the recommended plot?

Question: Is there code that could identify plots that are 3 to 5 squares away from an enemy cultural border?

Question: Is there code that could identify geograhical choke points outside of cultural borders?

This kind of code would locate mines a strategic locations, which would likely provide the best kind of harassment for rival Civs.

Lastly, is there any seek out and destroy python code that I could use for the mine sweepers? Note: I have the destroy side working. I just need a way to compel the AI to seek out mines.



Orion Veteran :cool:
 
Forget it. Maybe you can get that abomination exposed if it isn't already, but trying to recreate that funcitonality in python is not a good idea.

Question: Is there code that could identify plots that are 3 to 5 squares away from an enemy cultural border?
Would be expensive to calculate, "at least 2 tiles away" would look doable though. (Not owned, and not adjancent to owned)

Question: Is there code that could identify geograhical choke points outside of cultural borders?
That's just it. No.
If you want to make the AI map-aware, don't let anyone stop you. But really, a strategical understanding of the map for the AI would be difficult to implement, simply based on the fact that you would have to do that from scratch. Of course, if that info were put to good use, it could make the AI a lot stronger in warfare in general, not just mine placement.

Lastly, is there any seek out and destroy python code that I could use for the mine sweepers? Note: I have the destroy side working. I just need a way to compel the AI to seek out mines.
I believe subs aren't hunted either so that means no. There is no seek&destroy code in bts afaik.
You could create whole new unit_ai based loosely on the worker AI, where the minesweeper can only perform one worker action: "remove mine". I'm still not sure how you could get this unit to look for mines it can't already see though. It would need to know which tiles were cleared when and which tiles should be cleared because troops will be moving over them. Sounds like stuff that breaks savegames :p
 
I agree with Fuyu, I don't know why you aren't doing this in the SDK. You'd have much more power and control there.

Why someone with your obvious programming talent with your ideas is still coding in python for this stuff is beyond me.
 
I agree with Fuyu, I don't know why you aren't doing this in the SDK. You'd have much more power and control there.

Why someone with your obvious programming talent with your ideas is still coding in python for this stuff is beyond me.

Isn't it obvious? Once you commit to changing the DLL through SDK, the mod becomes incompatible with and must compete against all of the major mods. Sure, there might be a few individuals, with the skills necessary to combine the SDK into a new DLL: A Dll that no other mod, with a modified DLL can use! In Civ4, the DLL is a huge limiting factor for many modders. By not having a DLL, the Mine Warfare mod remains standard and can be used by everyone out there. The interest in this project is huge. This is why I work so hard to make it all happen in XML and Python. :hammer: I know it is not an easy task.

However, everything I have developed in this project to date works and works very well. If I have to spend another 2 or 3 weeks developing and testing python to make the AI properly deploy and hunt down mines, I think it is worth the time and effort to keep the mod standard.

Very Respectfully,


Orion Veteran :cool:
 
Isn't it obvious? Once you commit to changing the DLL through SDK, the mod becomes incompatible with and must compete against all of the major mods.

There are only 4 major mods actually( BUG & BULL, RevDCM, FFH2, RoM, in that order[the fifth most popular mod is much less popular than the top 4, and not worth naming]), and if the ideas are good enough, it will be added to one or more of them and trickle into all of its derivatives.

Anyway, half the reason I wish you were doing this in the SDK is so I don't have to re-invent the wheel to make your mods work with mine, lol. ;)
 
Back
Top Bottom