Dune Wars Enhanced Patching
- Thread starter Horatius
- Start date
platyping
Sleeping Dragon
It is still redundant 
1) There is a direct isBarbarian() check, so why such a long code just to check the same thing
2) Purpose of iCount which is totally unused?
3) Not sure what is the purpose of the getGroup check. Effectively 2 Dancers on the same plot, ungrouped will trigger, but if grouped will not trigger when whacking the same target... odd
4) CyTranslator().getText is meant to translate "TXT_KEY_XXX" text into the translated text files based on language.
Yet the input is already translated then what is the point, and it will always be displayed in English regardless of language of user.
5) I guess iEnemyUnitsCount is meant to count number of enemy units in the loser plot to decide whether to spawn the new unit in winner or loser plot.
Yet it is neither correct logic nor efficient.
Firstly, it is possible that units in the loser plot can be neutral units, or invisible ones.
So it is counting wrong things.
Secondly, there is a direct code to count visible defenders...
With that, you can easily decide which plot to use.
This plot check should also be used for the dance message, since currently the message will always spawn in the winner plot even if the winner moved to the loser plot after battle.
1) There is a direct isBarbarian() check, so why such a long code just to check the same thing
2) Purpose of iCount which is totally unused?
3) Not sure what is the purpose of the getGroup check. Effectively 2 Dancers on the same plot, ungrouped will trigger, but if grouped will not trigger when whacking the same target... odd
4) CyTranslator().getText is meant to translate "TXT_KEY_XXX" text into the translated text files based on language.
Yet the input is already translated then what is the point, and it will always be displayed in English regardless of language of user.
5) I guess iEnemyUnitsCount is meant to count number of enemy units in the loser plot to decide whether to spawn the new unit in winner or loser plot.
Yet it is neither correct logic nor efficient.
Firstly, it is possible that units in the loser plot can be neutral units, or invisible ones.
So it is counting wrong things.
Secondly, there is a direct code to count visible defenders...
With that, you can easily decide which plot to use.
This plot check should also be used for the dance message, since currently the message will always spawn in the winner plot even if the winner moved to the loser plot after battle.
Btw, this is part of the Kael code that I used, so you can take that criticism to him if you think yourself worthy
This is actually useful.
Ah, its getNumVisibleEnemyDefenders (CyUnit pUnit). Excellent.
platyping
Sleeping Dragon
It doesn't matter who wrote the code.
Even if it is coded by professionals in Firaxis, I will still read through and understand the purpose of the code before I use it for my own usage.
Unless there are more codes below this portion, it is totally redundant.
Even if it is coded by professionals in Firaxis, I will still read through and understand the purpose of the code before I use it for my own usage.
Unless there are more codes below this portion, it is totally redundant.
Thanks. Working with code professionally must be a pain.
getNumVisibleEnemyDefenders (CyUnit pUnit) does not count missiles and other units with combat str that can't defend?
platyping
Sleeping Dragon
Ignores all that cannot defend against the unit, including invisible ones without vision
platyping
Sleeping Dragon
1) Usually I will use canAcquirePromotion rather than isPromotionValid.
The difference is the former checks prereqs while the latter does not.
Using the latter, it is possible to copy Combat V without having Combat I to IV.
2) That whole chunk of hard coded promos can be simplified to this:
The difference is that using this method, addition or deletion of further INSPIRED chain of promos can be done without modifying the python codes. You can add IV, V, X all you like.
Furthermore, using your method, if there is a typo, gc.getInfoTypeForString will return -1 and screw it.
3) Points 4 and 5 of previous post still the same.
4)
Besides the first line, everything else is the same, is there a need to copy twice under if and else?
isAttacking checks if the unit is currently attacking.
isAttacked checks if the unit has already made an attack, so it will be true for all units which have made an attack in the current turn.
The difference is the former checks prereqs while the latter does not.
Using the latter, it is possible to copy Combat V without having Combat I to IV.
2) That whole chunk of hard coded promos can be simplified to this:
Code:
sType = gc.getPromotionInfo(iProm).getType()
if sType.find("PROMOTION_HOMEGROUND") > -1: continue
if sType.find("PROMOTION_INSPIRED") > -1: continueThe difference is that using this method, addition or deletion of further INSPIRED chain of promos can be done without modifying the python codes. You can add IV, V, X all you like.
Furthermore, using your method, if there is a typo, gc.getInfoTypeForString will return -1 and screw it.
3) Points 4 and 5 of previous post still the same.
4)
Code:
if pPlot2.getNumVisibleEnemyDefenders(pWinner) > 1:
[COLOR="Red"]newUnit = pPlayer.initUnit(pLoser.getUnitType(), pWinner.getX(), pWinner.getY(), UnitAITypes.NO_UNITAI, DirectionTypes.NO_DIRECTION)[/COLOR]
newUnit.convert(pWinner)
newUnit.finishMoves()
if pPlayer.isHuman():
CyInterface().addMessage(pWinner.getOwner(),false,20,("Your unit has shapeshifted into the defeated enemy!"),'',0,gc.getUnitInfo(newUnit.getUnitType()).getButton(),ColorTypes(8), newUnit.getX(), newUnit.getY(), True,True)
else:
[COLOR="red"]newUnit = pPlayer.initUnit(pLoser.getUnitType(), pLoser.getX(), pLoser.getY(), UnitAITypes.NO_UNITAI, DirectionTypes.NO_DIRECTION)[/COLOR]
newUnit.convert(pWinner)
newUnit.finishMoves()
if pPlayer.isHuman():
CyInterface().addMessage(pWinner.getOwner(),false,20,("Your unit has shapeshifted into the defeated enemy!"),'',0,gc.getUnitInfo(newUnit.getUnitType()).getButton(),ColorTypes(8), newUnit.getX(), newUnit.getY(), True,True)Besides the first line, everything else is the same, is there a need to copy twice under if and else?
isAttacking checks if the unit is currently attacking.
isAttacked checks if the unit has already made an attack, so it will be true for all units which have made an attack in the current turn.
I know, i want it like that. Its a sci-fi fantasy mod...
Nice to know!
What do you mean? I changed that.
I can see a better way of doing it but it does not matter much; the spawning code, that did it matter. Thanks for the help.
Thanks.
You're welcome.
platyping
Sleeping Dragon
12345
Heh, you can be a weird one. Of course, i knew what 4 and 5 meant.
platyping
Sleeping Dragon
That "12345" is because it is a requirement to type 5 letters to post a message lol
Ah, yes. Still, you're sometimes cryptic. You probably have fun with that.
Thanks for the lesson again. I'll polish the code again some other time with your suggestions. Coding is not really that fun for a coding amateur like me, its the result I'm interested in.
For playability it is now working well.
platyping
Sleeping Dragon
It is good to see new coders who are willing to learn.
The first level of success is to ensure your code works in the general situation.
The second level is to ensure it works even in exceptional cases.
The iEnemyUnitsCount example is one that will fail here and give unwanted results.
Then finally you look at ways to improve efficiency.
Although computers nowadays can handle thousands of codes pretty fast, it is still good to improve it as much as possible to reduce lag in late game big maps.
Of course if I look at my earlier works one year ago, I can also spot inefficiencies here and there, but I can't be bothered either.
The first level of success is to ensure your code works in the general situation.
The second level is to ensure it works even in exceptional cases.
The iEnemyUnitsCount example is one that will fail here and give unwanted results.
Then finally you look at ways to improve efficiency.
Although computers nowadays can handle thousands of codes pretty fast, it is still good to improve it as much as possible to reduce lag in late game big maps.
Of course if I look at my earlier works one year ago, I can also spot inefficiencies here and there, but I can't be bothered either.
