Quantitative Resources

[Gaius Octavius]

Oops, just noticed my code had returned FALSE. It was originally TRUE but I changed it when I was messing around with CanTrain earlier. Small error.

 

[snipperrabbit!!]

Gaius, I don't get if you missed Mylon's previous post or not. As there is a chance it happened, I report you it back to you.

 

[Gaius Octavius]

I did not miss it; it is simply not useful to me. If I understand the code he added correctly, what it will do is prevent any other unit from being trainable once your city starts work on something. That's not what I want.

 

[Mylon]

I did not miss it; it is simply not useful to me. If I understand the code he added correctly, what it will do is prevent any other unit from being trainable once your city starts work on something. That's not what I want.

Sorry, I didn't read the name of the function (cannot). I was looking for a way to equate eUnit with the unit's build ID and use that for the comparison function. If equal, have it return false.

In other words, before checking if adequate resources are available, is the city already training this unit? If so, keep training, otherwise, check for resource availability.

 

[primordial stew]

I really don't see how a script save of the city production would matter. You can't hide the city from CannotTrain until the production is done because that would foul up the summary of the choices on the menu.

Can you explain the last part? I'm not familiar with how these functions behave

I'm guessing that so long as the city continues to build settler it can continue. If the stockpile is insufficient then no other cities can begin construction.

 

[Gaius Octavius]

Sorry, I didn't read the name of the function (cannot). I was looking for a way to equate eUnit with the unit's build ID and use that for the comparison function. If equal, have it return false.

In other words, before checking if adequate resources are available, is the city already training this unit? If so, keep training, otherwise, check for resource availability.

Oh, sorry, I see what you mean now. Still not exactly what I wanted to do, but I understand what you were saying. Maybe I will end up going along these lines, but it will require me to deduct the resources from the stockpile at the outset, and I do not know how to manage that in this setup. Is there a Python command that looks at when a unit/building is assigned in a production queue? (The critical issue is reassigning resources to the stockpile if you remove a unit from the queue.)

EDIT: I think I found out how to handle the first part using onCityBuildingUnit and onCityBuildingBuilding, but I still don't see how to reset the stockpile if you quit production midway through.

Can you explain the last part? I'm not familiar with how these functions behave

I'm guessing that so long as the city continues to build settler it can continue. If the stockpile is insufficient then no other cities can begin construction.

That is exactly how I thought it would work, but there's some weird catch: once you end the turn (if you have reached the end of your stockpile), the last unit you assigned will be thought of as untrainable. The game then kicks it out of your queue, and brings up the list of units you can train--including the unit it just stopped!

The problem is not in the stockpiles, but in CannotTrain. Let me run through it again:

1. You have 30 iron, enabling you to make 3 swordsmen.

2. You assign 2 swordsmen and start work on them. Nothing happens.

3. You assign a 3rd swordsman, and CannotTrain returns TRUE and the unit disappears from all your cities as a buildable unit.

4. On the next turn, one of your units gets dropped from the queue. You get a message saying "You cannot continue training a Swordsman" and it asks you what you want to build, including a swordsman unit!

In answer to your first question, CannotTrain looks at what units you cannot make in a city. Thus, if you made the city immune to this function once work on something started, you'd no longer be able to add other units to the queue or it would be fouled up some other way.

 

[Zebra 9]

Post your python files (or pm them to me) and I'll see if I can figure out what is wrong.

 

[Gaius Octavius]

I did that already.

There is only one section that could possibly be causing it, and that's in the CannotTrain above.

 

[Zebra 9]

Ok, I copied your code into a text editor and it clicked. This should work.

def cannotTrain(self,argsList):
		pCity = argsList[0]
		eUnit = argsList[1]
		bContinue = argsList[2]
		bTestVisible = argsList[3]
		bIgnoreCost = argsList[4]
		bIgnoreUpgrades = argsList[5]
                # QR
		maxUnits = QR.getStockpile('CIVILIZATION_0','iStockpile_1')) / 10
		producing = gc.getPlayer(pCity.getOwner()).getUnitClassMaking(4))

		# This will make sure that the unit that is being asked about is the correct type
		if gc.getUnitInfo(eUnit).getUnitClassType() == 4:
			# If this unit is being worked on check to see if too many are being made
			if bContinue and producing > maxUnits:
				return True

			elif producing >= maxUnits:	# Otherwise return True if we are maxed out
				return True
                # End QR
		return False

 

[Gaius Octavius]

Thanks Zebra, but your code does not work. (It did have two extra parentheses in it, but I caught that.) I had 10 resources in the stockpile and tried to build one unit (costing 10 of the resource) and it returned the old "cannot train" message.

The only way I could get it to work was by changing the code to read:

	elif producing >= maxUnits:	# Otherwise return True if we are maxed out
		return False

But the problem with this is that you can still queue a unit even when you're already building the maximum, though it will get deleted on the next turn. This will undoubtedly confuse the AI (not to mention the player) since you can allocate a unit when you shouldn't be able to, and therefore it is likely that production will just get wasted in the process.

 

[Zebra 9]

Sorry about the parentheses, I rarely use them. Now upon look at the code again I see why it didn't work. This should do the trick.

def cannotTrain(self,argsList):
        pCity = argsList[0]
        eUnit = argsList[1]
        bContinue = argsList[2]
        bTestVisible = argsList[3]
        bIgnoreCost = argsList[4]
        bIgnoreUpgrades = argsList[5]
                # QR
        maxUnits = QR.getStockpile('CIVILIZATION_0','iStockpile_1') / 10
        producing = gc.getPlayer(pCity.getOwner()).getUnitClassMaking(4)

        # This will make sure that the unit that is being asked about is the correct type
        if gc.getUnitInfo(eUnit).getUnitClassType() == 4:
            # If this unit is being worked on check to see if too many are being made
            if bContinue and producing > maxUnits:
                return True

            elif producing >= maxUnits and not bContinue:    # Otherwise return True if we are maxed out
                return True
                # End QR
        return False

 

[Gaius Octavius]

[As Scotty] Aye, that's done it! Now I just have to adapt this for buildings too, and we're all set.

Since I'm doing this in Python things will get tricky once you lose access to a resource (as the SDK intercepts that, I believe, so you wouldn't be able to train a unit in spite of having built up a stockpile), but I know how to get around this...

 

[Zebra 9]

Great, can't wait to see it done. Just let me know if ya need anything else.

 

[Gaius Octavius]

Actually, I do have one more question. Is it possible to have the game look at how many of a unit type, rather than a unit class, you are making? I looked for a function similar to getUnitClassMaking but couldn't find one.

If this is possible, it would be better since you could specify different costs for units that are technically part of the same class but still unique. For example, a regular spearman costs so much iron or copper to make, but the Mayan Holkan (which replaces the spearmen) requires no special resources at all. Under the getUnitClassMaking system, there would be no distinction, so they'd both have to require resources.

 

[Zebra 9]

As far as I know there is no possible way to use the SDK to find the number of a unit type.

Now you could make a variable that held the number of units of a certain type a civ had and increase it or decrease it as required.

 

[Dom Pedro II]

Actually, I do have one more question. Is it possible to have the game look at how many of a unit type, rather than a unit class, you are making? I looked for a function similar to getUnitClassMaking but couldn't find one.

If this is possible, it would be better since you could specify different costs for units that are technically part of the same class but still unique. For example, a regular spearman costs so much iron or copper to make, but the Mayan Holkan (which replaces the spearmen) requires no special resources at all. Under the getUnitClassMaking system, there would be no distinction, so they'd both have to require resources.

Well, what you would do is get the number of the unit class being made and then find the unique unit of that unit class for that civilization.

For example, when you pick a unit to build, you're really picking a unit class... but then you'll see code similar to the following:

UnitTypes eUnit = (UnitTypes) GC.getCivilizationInfo(getCivilizationType()).getCivilizationUnit(eUnitClass);

 

[Seven05]

Actually, I do have one more question. Is it possible to have the game look at how many of a unit type, rather than a unit class, you are making? I looked for a function similar to getUnitClassMaking but couldn't find one.

If this is possible, it would be better since you could specify different costs for units that are technically part of the same class but still unique. For example, a regular spearman costs so much iron or copper to make, but the Mayan Holkan (which replaces the spearmen) requires no special resources at all. Under the getUnitClassMaking system, there would be no distinction, so they'd both have to require resources.

Why would you need a different function? Each civ can only build one specific unit of any unitclass anyway. That is to say that if you're playing the Romans and building 'UNITCLASS_SWORDSMAN' you're building a Praetorian as it's the only UNITCLASS_SWORDSMAN you can build.

Also, regarding the que, this will probably cause you some problems because build orders aren't removed from the que even if they no longer show on the city's production list. Hard to explain... try this:

Start producing a settler, when your about 50% finished change to producing a warrior or a building and remove the settler from the que (click on it when it's not at the top of the list). When your warrior is finished, start building a settler again, note the stored progress. As far as I know this data is not exposed to python, it does decay over time but it's a long time although i think you can modify the decay rate.

 

[Gaius Octavius]

Well, what you would do is get the number of the unit class being made and then find the unique unit of that unit class for that civilization.

For example, when you pick a unit to build, you're really picking a unit class... but then you'll see code similar to the following:

UnitTypes eUnit = (UnitTypes) GC.getCivilizationInfo(getCivilizationType()).getCivilizationUnit(eUnitClass);

Ah, got it... you just basically use a clever trick. Good idea.

Why would you need a different function? Each civ can only build one specific unit of any unitclass anyway. That is to say that if you're playing the Romans and building 'UNITCLASS_SWORDSMAN' you're building a Praetorian as it's the only UNITCLASS_SWORDSMAN you can build.

I already said why! Because I have it so that the game looks in an array of all the costs, and the way it is set up, since it presently only returns a unit class and not a unit, there is no difference between a Praetorian and a Phalanx in cost. This will help me distinguish the two to allow for specific costs.

 

[Dom Pedro II]

Ah, got it... you just basically use a clever trick. Good idea.

I basically just use the developer's clever trick, but if you really want me to take credit for it...

 

[Gaius Octavius]

I basically just use the developer's clever trick, but if you really want me to take credit for it...

Makes no difference to me so long as it works.