Help Wanted Ads

[God-Emperor]

I am supposed to update Python/Screens/CvScreenEnums,py with the new screens I have added to the pedia. But it uses CivilopediaPageTypes and I have no idea where this is defined.

The CivilopediaPageTypes are defined in the DLL.

The actual definitions are inCvEnums.h and they are exposed to Python via code in CyEnumsInterface.cpp. If you change them, you'll have to do it in both places.

 

[strategyonly]

Is this anything or is it just OLD C++/python junk?? (vector)

Spoiler :

#!/usr/bin/env python
# 
# a python vector class
# A. Pletzer 5 Jan 00/11 April 2002
#
import math

"""
A list based vector class that supports elementwise mathematical operations

In this version, the vector call inherits from list; this 
requires Python 2.2 or later.
"""

class vector(list):
	"""
        A list based vector class
	"""
	# no c'tor

	def __getslice__(self, i, j):
		try:
			# use the list __getslice__ method and convert
			# result to vector
			return vector(super(vector, self).__getslice__(i,j))
		except:
			raise TypeError, 'vector::FAILURE in __getslice__'
		
	def __add__(self, other):
		return vector(map(lambda x,y: x+y, self, other))

	def __neg__(self):
		return vector(map(lambda x: -x, self))
	
	def __sub__(self, other):
		return vector(map(lambda x,y: x-y, self, other))

	def __mul__(self, other):
	    """
	    Element by element multiplication
	    """
	    try:
		    return vector(map(lambda x,y: x*y, self,other))
	    except:
		    # other is a const
		    return vector(map(lambda x: x*other, self))


	def __rmul__(self, other):
		return (self*other)


	def __div__(self, other):
	    """
	    Element by element division.
	    """
	    try:
		    return vector(map(lambda x,y: x/y, self, other))
	    except:
		    return vector(map(lambda x: x/other, self))

	def __rdiv__(self, other):
	    """
	    The same as __div__
	    """
	    try:
		    return vector(map(lambda x,y: x/y, other, self))
	    except:
		    # other is a const
		    return vector(map(lambda x: other/x, self))

        def size(self): return len(self)

	def conjugate(self):
	    return vector(map(lambda x: x.conjugate(), self))

        def ReIm(self):
		"""
		Return the real and imaginary parts
		"""
		return [
			vector(map(lambda x: x.real, self)),
			vector(map(lambda x: x.imag, self)),
			]
	
        def AbsArg(self):
		"""
		Return modulus and phase parts
		"""
		return [
			vector(map(lambda x: abs(x), self)),
			vector(map(lambda x: math.atan2(x.imag,x.real), self)),
			]


	def out(self):
	    """
	    Prints out the vector.
	    """
	    print self

###############################################################################


def isVector(x):
    """
    Determines if the argument is a vector class object.
    """
    return hasattr(x,'__class__') and x.__class__ is vector

def zeros(n):
    """
    Returns a zero vector of length n.
    """
    return vector(map(lambda x: 0., range(n)))

def ones(n):
    """
    Returns a vector of length n with all ones.
    """
    return vector(map(lambda x: 1., range(n)))

def random(n, lmin=0.0, lmax=1.0):
    """
    Returns a random vector of length n.
    """
    import whrandom
    new = vector([])
    gen = whrandom.whrandom()
    dl = lmax-lmin
    return vector(map(lambda x: dl*gen.random(),
		       range(n)))
	
def dot(a, b):
    """
    dot product of two vectors.
    """
    try:
	return reduce(lambda x, y: x+y, a*b, 0.)
    except:
	raise TypeError, 'vector::FAILURE in dot'
	

def norm(a):
    """
    Computes the norm of vector a.
    """
    try:
	return math.sqrt(abs(dot(a,a)))
    except:
	raise TypeError, 'vector::FAILURE in norm'

def sum(a):
    """
    Returns the sum of the elements of a.
    """
    try:
	return reduce(lambda x, y: x+y, a, 0)
    except:
	raise TypeError, 'vector::FAILURE in sum'

# elementwise operations
	
def log10(a):
    """
    log10 of each element of a.
    """
    try:
	return vector(map(math.log10, a))
    except:
	raise TypeError, 'vector::FAILURE in log10'

def log(a):
    """
    log of each element of a.
    """
    try:
	return vector(map(math.log, a))
    except:
	raise TypeError, 'vector::FAILURE in log'
	    
def exp(a):
    """
    Elementwise exponential.
    """
    try:
	return vector(map(math.exp, a))
    except:
	raise TypeError, 'vector::FAILURE in exp'

def sin(a):
    """
    Elementwise sine.
    """
    try:
	return vector(map(math.sin, a))
    except:
	raise TypeError, 'vector::FAILURE in sin'
	    
def tan(a):
    """
    Elementwise tangent.
    """
    try:
	return vector(map(math.tan, a))
    except:
	raise TypeError, 'vector::FAILURE in tan'
	    
def cos(a):
    """
    Elementwise cosine.
    """
    try:
	return vector(map(math.cos, a))
    except:
	raise TypeError, 'vector::FAILURE in cos'

def asin(a):
    """
    Elementwise inverse sine.
    """
    try:
	return vector(map(math.asin, a))
    except:
	raise TypeError, 'vector::FAILURE in asin'

def atan(a):
    """
    Elementwise inverse tangent.
    """	
    try:
	return vector(map(math.atan, a))
    except:
	raise TypeError, 'vector::FAILURE in atan'

def acos(a):
    """
    Elementwise inverse cosine.
    """
    try:
	return vector(map(math.acos, a))
    except:
	raise TypeError, 'vector::FAILURE in acos'

def sqrt(a):
    """
    Elementwise sqrt.
    """
    try:
	return vector(map(math.sqrt, a))
    except:
	raise TypeError, 'vector::FAILURE in sqrt'

def sinh(a):
    """
    Elementwise hyperbolic sine.
    """
    try:
	return vector(map(math.sinh, a))
    except:
	raise TypeError, 'vector::FAILURE in sinh'

def tanh(a):
    """
    Elementwise hyperbolic tangent.
    """
    try:
	return vector(map(math.tanh, a))
    except:
	raise TypeError, 'vector::FAILURE in tanh'

def cosh(a):
    """
    Elementwise hyperbolic cosine.
    """
    try:
	return vector(map(math.cosh, a))
    except:
	raise TypeError, 'vector::FAILURE in cosh'


def pow(a,b):
    """
    Takes the elements of a and raises them to the b-th power
    """
    try:
        return vector(map(lambda x: x**b, a))
    except:
        try:
		return vector(map(lambda x,y: x**y, a, b))
	except:
		raise TypeError, 'vector::FAILURE in pow'
	
def atan2(a,b):    
    """
    Arc tangent
    
    """
    try:
	return vector(map(math.atan2, a, b))
    except:
	raise TypeError, 'vector::FAILURE in atan2'
	

###############################################################################
if __name__ == "__main__":

	print 'a = zeros(4)'
	a = zeros(4)

	print 'a.__doc__=',a.__doc__

	print 'a[0] = 1.0'
	a[0] = 1.0

	print 'a[3] = 3.0'
	a[3] = 3.0

	print 'a[0]=', a[0]
	print 'a[1]=', a[1]

	print 'len(a)=',len(a)
	print 'a.size()=', a.size()
			
	b = vector([1, 2, 3, 4])
	print 'a=', a
	print 'b=', b

	print 'a+b'
	c = a + b
	c.out()

	print '-a'
	c = -a
	c.out()
	a.out()

	print 'a-b'
	c = a - b
	c.out()

	print 'a*1.2'
	c = a*1.2
	c.out()


	print '1.2*a'
	c = 1.2*a
	c.out()
	print 'a=', a

	print 'dot(a,b) = ', dot(a,b)
	print 'dot(b,a) = ', dot(b,a)

	print 'a*b'
	c = a*b
	c.out()
	
	print 'a/1.2'
	c = a/1.2
	c.out()

	print 'a[0:2]'
	c = a[0:2]
	c.out()

	print 'a[2:5] = [9.0, 4.0, 5.0]'
	a[2:5] = [9.0, 4.0, 5.0]
	a.out()

	print 'sqrt(a)=',sqrt(a)
	print 'pow(a, 2*ones(len(a)))=',pow(a, 2*ones(len(a)))
	print 'pow(a, 2)=',pow(a, 2*ones(len(a)))

	print 'ones(10)'
	c = ones(10)
	c.out()

	print 'zeros(10)'
	c = zeros(10)
	c.out()	

	print 'del a'
	del a

	try:
		a = random(11, 0., 2.)
		a.out()

	except: pass

 

[Dancing Hoskuld]

Is this anything or is it just OLD C++/python junk?? (vector)

It looks useful.

onVassalState provides information about vassals turning on and off. There is not one for colonies as far as I can see. is this one also used for colonies? If so how do I tell that it is a colony? Or is there a way to get a onColonyFounded event exposed to Python? I just want to give the new colony a golden age of two turns so that they don't splinter due to revolutions while changing from the base civics and religion.

 

[strategyonly]

It looks useful.

onVassalState provides information about vassals turning on and off. There is not one for colonies as far as I can see. is this one also used for colonies? If so how do I tell that it is a colony? Or is there a way to get a onColonyFounded event exposed to Python? I just want to give the new colony a golden age of two turns so that they don't splinter due to revolutions while changing from the base civics and religion.

I have NO idea, sorry, thats why i put it here

Also i was just going over some of my python and your BeastMaster was the only other one that had

Spoiler :

def onUnitCreated(self, argsList):
	'Unit Completed'
	unit = argsList[0]
	player = PyPlayer(unit.getOwner())

but in the one you advised me on was this way:

Spoiler :

def onUnitCreated(self, argsList):
	pUnit = argsList[0]

 

[strategyonly]

@Koshling:

On your dll change for this:

Spoiler :

	<Define>
		<DefineName>SHOW_BUILDINGS_LEVEL</DefineName>
		<iDefineIntVal>3</iDefineIntVal>
	</Define>

Now is this ALL buildings including module ones?? (Including the religion ones)
(i dont consider Wonders and Defensive stuff buildings).

If so, i wrote asking about the structures but didnt get an answer.

I want to delete all buildings from the structure FPK, excluding as referenced above(not considered buildings).

 

[Koshling]

@Koshling:

On your dll change for this:

Spoiler :

	<Define>
		<DefineName>SHOW_BUILDINGS_LEVEL</DefineName>
		<iDefineIntVal>3</iDefineIntVal>
	</Define>

Now is this ALL buildings including module ones?? (Including the religion ones)
(i dont consider Wonders and Defensive stuff buildings).

If so, i wrote asking about the structures but didnt get an answer.

I want to delete all buildings from the structure FPK, excluding as referenced above(not considered buildings).

It applies to all buildings in a city hat have actually been built there, so independent of where thy are defined in module/FPK terms (which is actually invisible to the code anyway in the latter case)

 

[SargontheGreat2]

Sorry, found it

 

[Thunderbrd]

I need a bit of help with the Sevopedia that only now I realize I need.

I just designed a new promo and when looking at it in the Sevopedia, I suddenly realized that the way I want to be able to establish Combat Class prereqs and how I want promotionlines to automatically (on non-equipment/affliction promos) be prereqs of the next step on the line doesn't properly show these facts in the pedia. The coding should work this way properly, but the display hasn't been updated to account for this.

In the following pic, you have 'Requires', 'Leads to', and 'Available to' boxes.

This is the iLinePriority 1 version of its promotionline. So Requires is displaying correctly to only show the tech prereq. BUT on those that follow it, iLinePriority 2 and up, they should be automatically showing the promotion that exists on the same promotionline at 1 less iLinePriority than their own. Thus, Disease Control II should be displaying Disease Control I in this 'Requires' box. (And it does not of course because nothing has been done to update this yet.)

Equally, if there's another step up the iLinePriority count in the same Promotionline, that promotion should be displayed here in the 'Leads to' box. In the pic I'm providing, this would mean that Disease Control II would be displayed in the Leads to box, which we can see of course that it is not, understandably since this issue has never been addressed here.

I've also implemented a way to define the Combat Class prereqs on the Promotionline as a whole rather than on each individual promotion. Makes the design and editing process for promos much easier this way. However, obviously this isn't being checked for the pedia so in the 'Available to' box we aren't showing the prereq Combat Class for this promotion's promotionline (in this case UNITCOMBAT_HEALTH_CARE).

As y'all know, I don't have a great deal of comfortability with python and the screens so I'm simply asking for some assistance in updating the promotions screen for these 3 issues. There's more to bring up here too as I've added some added prereq capabilities to promos that haven't been accounted for on the promo screen either, including NOT on Combat Class (bans that combat class in particular - with multiple CCs on units this is useful) and Tech Obsoletions.

And from what I'm seeing, some help would be appreciated in duplicating this screen for Equipments and Afflictions - they'd operate under some slightly different rules on what would show - no compiling of the values with each step on the promotionline etc... And they should show up on a different page for the sake of making them easier to differentiate for the player.

But that can wait for a bit until we've got some coming into play. What's important right now is helping the player see the actual Requires, leads to, and available to displays.

 

[Dancing Hoskuld]

And from what I'm seeing, some help would be appreciated in duplicating this screen for Equipments and Afflictions - they'd operate under some slightly different rules on what would show - no compiling of the values with each step on the promotionline etc... And they should show up on a different page for the sake of making them easier to differentiate for the player.

Duplicating is easy if there is a way to identify which page the promotion goes on.

 

[Dancing Hoskuld]

This is the iLinePriority 1 version of its promotionline. So Requires is displaying correctly to only show the tech prereq. BUT on those that follow it, iLinePriority 2 and up, they should be automatically showing the promotion that exists on the same promotionline at 1 less iLinePriority than their own. Thus, Disease Control II should be displaying Disease Control I in this 'Requires' box. (And it does not of course because nothing has been done to update this yet.)

This works for all the other promotions because they have the promotion II require promotion I explicitly. IE

			<PromotionPrereq>NONE</PromotionPrereq>
			<PromotionPrereqOr1>PROMOTION_COMBAT1</PromotionPrereqOr1>
			<PromotionPrereqOr2>NONE</PromotionPrereqOr2>

It is done via getPromotionInfo(j).getPrereqPromotion(). If you want to change this then it will require some dll work and enforcing of naming standards as currently the bit that indicates the difference could be the suffix 1, _1, I or _I.

Edit attached is a fix for the disease control promotion requirements.

edit 2 To get the combat classes that the promotions are available to will require something in the dll to be exposed to python so that I can get at them. In the mean time I'll look at adding a "not available to" box on the pedia page.

 

[God-Emperor]

Looking at the names should be unnecessary and therefor the naming should be irrelevant.

The line name and priority are data items in the promotion info. I just checked and it looks like the actual promotion line name (or numerical equivalent) for a promotion is not exposed to Python, only the line priority. If the line identifier were exposed to python then having the pedia page add the previous promotion in the line would be easy: just check the promotion to see if it's line priority is > 1 and if so loop over all the promotions looking for the promotion with the same line name but one lower priority and add its button when showing the requirements.

 

[Dancing Hoskuld]

Looking at the names should be unnecessary and therefor the naming should be irrelevant.

The line name and priority are data items in the promotion info. I just checked and it looks like the actual promotion line name (or numerical equivalent) for a promotion is not exposed to Python, only the line priority. If the line identifier were exposed to python then having the pedia page add the previous promotion in the line would be easy: just check the promotion to see if it's line priority is > 1 and if so loop over all the promotions looking for the promotion with the same line name but one lower priority and add its button when showing the requirements.

I wrote that before realising that all that was needed was to have the lower level/line promotion in defined as a prerequisite. Which is how I "fixed" that particular display problem.

 

[Thunderbrd]

Duplicating is easy if there is a way to identify which page the promotion goes on.

There is. We have bEquipment and bAffliction tags. I believe those are exposed to python but I'll check.

Of course, at the moment we don't have any but this development structure would still be helpful.

This works for all the other promotions because they have the promotion II require promotion I explicitly. IE

			<PromotionPrereq>NONE</PromotionPrereq>
			<PromotionPrereqOr1>PROMOTION_COMBAT1</PromotionPrereqOr1>
			<PromotionPrereqOr2>NONE</PromotionPrereqOr2>

It is done via getPromotionInfo(j).getPrereqPromotion(). If you want to change this then it will require some dll work and enforcing of naming standards as currently the bit that indicates the difference could be the suffix 1, _1, I or _I.

I'm not sure if the later statements below indicate that you have this sorted out but we have options, apparently. One option would be for me to now track that back to the way getPrereqPromotion is compiled and add the new prereq source to that coding. Another would be to let it be taken care of in python pretty much along the lines that GE states there(and apparently PromotionLine is not exposed to python yet? Interesting... I suppose that was done later than the iLinePriority as the original PromotionLine was just an integer until I was shown how to generate a new class.)

Edit attached is a fix for the disease control promotion requirements.

Um... I'm a little confused as to what you actually attached here... I guess I'll have to download it and take a look huh?

edit 2 To get the combat classes that the promotions are available to will require something in the dll to be exposed to python so that I can get at them. In the mean time I'll look at adding a "not available to" box on the pedia page.

Well... is that a list generated in the dll now? If so I can find that function and add some extra coding. But if its drawing directly from the xml, passed to the dll then directly to python, then I would probably just need to expose the Combat Classes for a promo as defined by the promo's Promotionline definitions.

Looking at the names should be unnecessary and therefor the naming should be irrelevant.

The line name and priority are data items in the promotion info. I just checked and it looks like the actual promotion line name (or numerical equivalent) for a promotion is not exposed to Python, only the line priority. If the line identifier were exposed to python then having the pedia page add the previous promotion in the line would be easy: just check the promotion to see if it's line priority is > 1 and if so loop over all the promotions looking for the promotion with the same line name but one lower priority and add its button when showing the requirements.

Yep. Pretty much. That could be done in compiling the list in the dll too before even exposing to python perhaps... Then again, it sounds like it might be done already somehow? I really do need to expose the Promotionline tag though.

I wrote that before realising that all that was needed was to have the lower level/line promotion in defined as a prerequisite. Which is how I "fixed" that particular display problem.

Did you need to filter the promos to make sure that they matched the same promoline?

 

[Dancing Hoskuld]

The pedia Python only looks at what it gets from the lists so it does no checking between promotion lines in this case because the code is from before there were promotion lines.

I just added in the three (confusing) XML lines for prerequisites that come with the promotions file. It uses those three fields to determine what goes into both the "Leads to" and "Requires" boxes. Using the functions getPrereqPromotion, getPrereqOrPromotion1 and getPrereqOrPromotion2. If you want me to do extra stuff between PromotionLine and Priority then your idea of the names being the same does not make sense (I assume name = contents of type tag). I.E. PROMOTION_DISEASE_CONTROL1 is not the same as PROMOTION_DISEASE_CONTROL2! To make maters worse some promotions don't use a number at the end but _I and _II instead.

Currently the information on what combat classes the promotion is available to comes from the list in the promotion UnitCombats tag.

 

[God-Emperor]

"Promotion line name" is not the same as "promotion name".

Example:
Type PROMOTION_COMBAT1 has PromotionLine set to PROMOTIONLINE_COMBAT and iLinePriority set to 1

Type PROMOTION_COMBAT2 has PromotionLine set to PROMOTIONLINE_COMBAT but iLinePriority set to 2

The types are different and the actual name in the type tag is completely irrelevant. Both have PromotionLine set the same.

If, after it is exposed to the Python, you find the promotion the screen is being display for has PROMOTIONLINE_X (or, more likely, it will actually be an integer corresponding to the promotion line, so in this example above for the first two combat promotions it would be the integer 0 since that is the first promotion line in the CIV4PromotionLineInfos.xml file) and it has iLinePriority 3 then whatever promotion has the same promotion line and iLinePriority 2 is a prereq for it. It does not matter if one of them is PROMOTION_JOE3 and the other PROMOTION_FRED_II since you never need to look at the actual name specified in the XML for the rpomotion.

You may also want to check to see if very same promotion is also mentioned in one of the PromotionPrereq related tags so you don't display it as a requirement twice.

Of course this whole thing is just to deal with the case where the prereq is not actually specified as a prereq but just defaults to being one via the promotion line data. If the promotions always directly specified the prereq you wouldn't need to do this at all.

 

[strategyonly]

Just thought i'd put this out there for the Win 8 users, now you can use the OLD Win 7 start-up and START button, it made a heck of lot of difference, i can find my "accessories" again, YEAH!!

http://www.classicstart8.com/

 

[Thunderbrd]

"Promotion line name" is not the same as "promotion name".

Example:
Type PROMOTION_COMBAT1 has PromotionLine set to PROMOTIONLINE_COMBAT and iLinePriority set to 1

Type PROMOTION_COMBAT2 has PromotionLine set to PROMOTIONLINE_COMBAT but iLinePriority set to 2

The types are different and the actual name in the type tag is completely irrelevant. Both have PromotionLine set the same.

If, after it is exposed to the Python, you find the promotion the screen is being display for has PROMOTIONLINE_X (or, more likely, it will actually be an integer corresponding to the promotion line, so in this example above for the first two combat promotions it would be the integer 0 since that is the first promotion line in the CIV4PromotionLineInfos.xml file) and it has iLinePriority 3 then whatever promotion has the same promotion line and iLinePriority 2 is a prereq for it. It does not matter if one of them is PROMOTION_JOE3 and the other PROMOTION_FRED_II since you never need to look at the actual name specified in the XML for the rpomotion.

You may also want to check to see if very same promotion is also mentioned in one of the PromotionPrereq related tags so you don't display it as a requirement twice.

Of course this whole thing is just to deal with the case where the prereq is not actually specified as a prereq but just defaults to being one via the promotion line data. If the promotions always directly specified the prereq you wouldn't need to do this at all.

All true of course, but it does make the XML a bit easier to work with the way those promoline assumptions are setup.

So all this amounts to: I've GOT to expose the Promotionline to the Python for this to work - and perhaps it can be done by manipulating what generates the list from the dll in the first place. I'll take a solid look at that this weekend.

 

[Dancing Hoskuld]

Is the unit related workRate(bool iMax) function exposed to Python? The doco says it is but I get a no such method error message. Also what is the iMax meaning?

 

[Thunderbrd]

Is the unit related workRate(bool iMax) function exposed to Python? The doco says it is but I get a no such method error message. Also what is the iMax meaning?

I'll look into this and let you know tomorrow.

 

[Thunderbrd]

Edit attached is a fix for the disease control promotion requirements.

I now see what you did there... I've added new rules through the promotionline mechanisms to enable new ways to attach promotion requirements. This is intended to make things MUCH easier on us as we can attach prereqs to entire categories of promos rather than just to each and every individual promotion. This makes us more agile in being able to audit and adjust promotion prereqs throughout and makes it much easier when designing a promotion set. So its an update to the pedia we're looking for here that makes this fit the way the pedia displays these things. (I'm sure you get all this at this point so I'm just trying to clarify anything that MIGHT be confusing at the moment.)

The idea that many of these displays are being derived from lists generated in the dll in the first place gives me a concept of how I may be able to repair these without much adjustment on the python side and I'm looking into that today. (along with the previous request)