Yet Another Unaltered Gameplay Mod

It doesn't work for me either, the naming mods. It worked in the previous version of the mod.

I love the mod, i usally just lurk though. Really want the naming one to work, adds so much more.
 
Okay, guys. Find and replace Assets/RuffMod/UnitNameEventManager.py with this attachment. This will make the unit naming mod work even if RuffMod.ini is not found, and contains a fix for method 3 and another fix I borrowed from Teg's Unit Statistics Mod.

Anyway, if the mod works after you replace this but you are not able to disable it, or change to a different naming mod, then we know that it has to be a path problem. Please let me know how it goes.

Edit: Attachment removed - please download latest mod version.
 
looks great. will install and start a game in a couple of hours.

will post comments later.

thanks in advance.
 
the mod works after replacing the file, and changing the RuffMod.ini variable changes the naming style. success!
 
Gaurav said:
Good. Can you disable it by setting [ENABLED]UnitName = 0?

Yeah, seems like this was the failure

#Fix to not interfere with Great Person naming

I don't know python, but it's similar to perl. What is the actual return for gc.getUnitInfo(unit.getUnitType()).getType()

How would one test that during the game, I know this is a question more of how to program, but it might be interesting implementing my own stuff, doesn't look too hard.
 
notque said:
Yeah, seems like this was the failure

#Fix to not interfere with Great Person naming

I don't know python, but it's similar to perl. What is the actual return for gc.getUnitInfo(unit.getUnitType()).getType()

How would one test that during the game, I know this is a question more of how to program, but it might be interesting implementing my own stuff, doesn't look too hard.

I found that line inside GreatPersonMod. It is supposed to return the (unlocalized) key string for the Unit Type, e.g. "UNIT_PROPHET". The fix worked well on my own machine, so I still don't think it was the reason for the issue. Anyway, the fix I copied from Teg's Unit Statistics is more widely applicable, faster, simpler, more likely to be compatible with "Great General" mods, and stops any units from being named twice to boot.

Did you try to see if you can disable the unit naming using the [ENABLED] section of RuffMod.ini? It really is hard to know if a bug is truly squashed when you could not reproduce it in the first place. I was actually trying to isolate it with that patch, not fix it. I just put up the latest version I was working on anyway.

By the way, I don't see too much similarity between Python and Perl, but I suppose they are both open source and interpreted, and every language borrows features from every other one anyway. Python's use of indenting as part of its syntax is what makes it unique.

Personally I prefer languages with explicit typing. That bug with method 3, where I had "znName" instead of "zsName", would never have happened with explicit typing, because I would have gotten an error message.
 
Gaurav said:
Good. Can you disable it by setting [ENABLED]UnitName = 0?

Yes. Sorry, got caught up in the Fall from Heaven mod. But all variables work in the RuffMod.ini file now.
 
Gaurav said:
I found that line inside GreatPersonMod. It is supposed to return the (unlocalized) key string for the Unit Type, e.g. "UNIT_PROPHET". The fix worked well on my own machine, so I still don't think it was the reason for the issue. Anyway, the fix I copied from Teg's Unit Statistics is more widely applicable, faster, simpler, more likely to be compatible with "Great General" mods, and stops any units from being named twice to boot.

Did you try to see if you can disable the unit naming using the [ENABLED] section of RuffMod.ini? It really is hard to know if a bug is truly squashed when you could not reproduce it in the first place. I was actually trying to isolate it with that patch, not fix it. I just put up the latest version I was working on anyway.

By the way, I don't see too much similarity between Python and Perl, but I suppose they are both open source and interpreted, and every language borrows features from every other one anyway. Python's use of indenting as part of its syntax is what makes it unique.

Personally I prefer languages with explicit typing. That bug with method 3, where I had "znName" instead of "zsName", would never have happened with explicit typing, because I would have gotten an error message.

Yes, I disabled it and it worked fine. I think the similarity between them I found is that with any interpreted languages. But considering I do not have experience with anything other than perl, it just struck me as useful that they were in general very similar.
 
notque said:
Yes, I disabled it and it worked fine. I think the similarity between them I found is that with any interpreted languages. But considering I do not have experience with anything other than perl, it just struck me as useful that they were in general very similar.

Thanks again for your feedback. The first bug reported to me has been squashed!

Just think of programming languages like the modpacks on CivFanatics, they borrow each other's best features, while holding on to something unique that draws people in the first place. So, you will find many familiar elements in just about any of them.
 
Sorry for this late realization, but there's no difference between option 3 and option 4 in the naming mod. I looked at the code and, well, there's no difference there either. Let me direct your attention to option 3 and 4 in UnitNameEventManager.py...

starting with line 71:
PHP:
if (iOwner.isHuman() and RuffMod.get_boolean('ENABLED', 'UnitName', True)):
			ziNameMthd = RuffMod.get_int('UNITNAME', 'Method', 2)
			if ziNameMthd == 0:
				return
			elif ziNameMthd == 1:
				zsName = RandomNameUtils.getRandomName()
			elif ziNameMthd == 2:
				zsName = RandomNameUtils.getRandomCivilizationName(civtype)
			elif ziNameMthd == 3:
				zsName = UnitNameRuff.getUnitNameNoCity(unit)
			elif ziNameMthd == 4:
				zsName = UnitNameRuff.getUnitNameNoCity(unit)
			elif ziNameMthd == 5:
				zsName = UnitNameRuff.getUnitBorgName()
			else:
				return

I changed one line to make it look like this:
PHP:
if (iOwner.isHuman() and RuffMod.get_boolean('ENABLED', 'UnitName', True)):
			ziNameMthd = RuffMod.get_int('UNITNAME', 'Method', 2)
			if ziNameMthd == 0:
				return
			elif ziNameMthd == 1:
				zsName = RandomNameUtils.getRandomName()
			elif ziNameMthd == 2:
				zsName = RandomNameUtils.getRandomCivilizationName(civtype)
			elif ziNameMthd == 3:
				zsName = UnitNameRuff.getUnitNameNoCity(unit)
			elif ziNameMthd == 4:
				zsName = UnitNameRuff.getUnitNameWithCity(unit, city)
			elif ziNameMthd == 5:
				zsName = UnitNameRuff.getUnitBorgName()
			else:
				return

And now it works right!
 
Vorgen said:
Sorry for this late realization, but there's no difference between option 3 and option 4 in the naming mod. I looked at the code and, well, there's no difference there either. Let me direct your attention to option 3 and 4 in UnitNameEventManager.py...

starting with line 71:
PHP:
if (iOwner.isHuman() and RuffMod.get_boolean('ENABLED', 'UnitName', True)):
			ziNameMthd = RuffMod.get_int('UNITNAME', 'Method', 2)
			if ziNameMthd == 0:
				return
			elif ziNameMthd == 1:
				zsName = RandomNameUtils.getRandomName()
			elif ziNameMthd == 2:
				zsName = RandomNameUtils.getRandomCivilizationName(civtype)
			elif ziNameMthd == 3:
				zsName = UnitNameRuff.getUnitNameNoCity(unit)
			elif ziNameMthd == 4:
				zsName = UnitNameRuff.getUnitNameNoCity(unit)
			elif ziNameMthd == 5:
				zsName = UnitNameRuff.getUnitBorgName()
			else:
				return

I changed one line to make it look like this:
PHP:
if (iOwner.isHuman() and RuffMod.get_boolean('ENABLED', 'UnitName', True)):
			ziNameMthd = RuffMod.get_int('UNITNAME', 'Method', 2)
			if ziNameMthd == 0:
				return
			elif ziNameMthd == 1:
				zsName = RandomNameUtils.getRandomName()
			elif ziNameMthd == 2:
				zsName = RandomNameUtils.getRandomCivilizationName(civtype)
			elif ziNameMthd == 3:
				zsName = UnitNameRuff.getUnitNameNoCity(unit)
			elif ziNameMthd == 4:
				zsName = UnitNameRuff.getUnitNameWithCity(unit, city)
			elif ziNameMthd == 5:
				zsName = UnitNameRuff.getUnitBorgName()
			else:
				return

And now it works right!

You are correct that there is no difference in onUnitCreated (lines 71-85). But that is because there is no city!!!

Because this is python, you won't get an error. You'll just introduce a hard to find bug. :sad: We all have to be very careful because Python has no explicit type checking. Typing is strong but latent (or dynamic).

If you look in onUnitBuilt (lines 105-120), I have the lines as you have them there. There is a city, so there is a difference in the methods.

The problem seems to be that onUnitCreated() runs before onUnitBuilt(), and now once a name is assigned, the fix I introduced does not allow it to be changed. Previously with method 4, the onUnitBuilt() method overwrote the onUnitCreated() method's name.

Since we are not supposed to try to change the order of calls from CyEventManager, the only correct fix is to determine if a unit is built in a city and then not set a name. Unfortunately, that does not seem to be possible without the SDK, there is no method in CyUnit that can help us out with that.

I have disabled the fix in onUnitBuilt() for now. It worked well enough before since I don't think the vanilla game names any units that are built. I hope I haven't introduced another obscure bug. I seem to really need an army of testers with this. Please try out the patch. I have tried this patch out with version 1.2.1 only, but I suppose it might work if you still have version 1.2.0 also.

(Attachment deleted)

Edit: I don't want to discourage you from trying to write fixes. And you are helping out a lot by finding the bug. Try turning on debugging next time and checking the logs, I think it might have helped you catch your error. And now I better run off and fully test this patch myself.
 
I'd love to try this but I get some key error from filefront link and I can't even get to the 3ddownloads site. :(
 
Ben Music said:
I'd love to try this but I get some key error from filefront link and I can't even get to the 3ddownloads site. :(

Regarding key error at Filefront, I am getting the same error right now. I have submitted a ticket to their support department. It was working most of today, according to download numbers.

I am able to get through to 3D Downloads at this time.

I am sorry you are having such problems. :sad:
 
Gaurav said:
Regarding key error at Filefront, I am getting the same error right now. I have submitted a ticket to their support department. It was working most of today, according to download numbers.

I am able to get through to 3D Downloads at this time.

I am sorry you are having such problems. :sad:

Regarding Filefront, I did not get an email or anything, but I was able to get a key and final download link just now.
 
smartus said:
Is there any problem with this MOD when playing multiplayer online? When somebody has the MOD and other players don't?

I have started to understand some of the issues on multiplayer compatibility, but I am not likely to achieve it unless someone volunteers significant testing help and is very motivated to get it to work. I only have one PC recent enough to play this game.

Btw, the same pretty much goes for Mac compatibility. I don't have a Mac.
 
Top Bottom