[Religion and Revolution]: Bugs and Todos

vetiarvind said:
I've seen something similar happen a couple of times where I can't select a stack when a nearby stack is alraedy selected. What I usually do is scroll out, select another unit and then come back to select the one I want. Maybe this isn't even the same issue, since I've never encountered anything major beyond that (let alone over a number of turns).
Click to expand...

This doesn't help because I can't activate any of my other units. Well that's not entirely true, I can double click the cannon to select the other units on the same plot with it.

Thanks for confirming there is an issue :)
 
@BSPollux Could you see my edit in the previous post and try that way out?

------------------------------------------------------------------------------

Canal Value Bug
Another bug I think I've noticed is with the AI code to calculate a plot's "canal value"...

If you see how the plot's canal value is calculated, it appears to check the number of tiles of water in the "second" area..i.e how much water can be reached from building a canal in this spot. Obviously, the greater area of water i can reach, the better it is. However, the last line in the method that checks this values does a min(0, numberOfTilesICanReach) instead of a max.

I'm planning on going with the "super forts" code for my mod-mod instead of this one, but it appears R&R (or was it derived from TAC or vanilla?) has this bug. Maybe I've misunderstood how the code works, but just in case...

Spoiler :
Code: 
int CvPlayerAI::AI_getPlotCanalValue(CvPlot* pPlot)
{
	PROFILE_FUNC();

	FAssert(pPlot != NULL);

	if (pPlot->isOwned())
	{
		if (pPlot->getTeam() != getTeam())
		{
			return 0;
		}
		if (pPlot->isCityRadius())
		{
			CvCity* pWorkingCity = pPlot->getWorkingCity();
			if (pWorkingCity != NULL)
			{
				if (pWorkingCity->AI_getBestBuild(pWorkingCity->getCityPlotIndex(pPlot)) != NO_BUILD)
				{
					return 0;
				}
				if (pPlot->getImprovementType() != NO_IMPROVEMENT)
				{
					CvImprovementInfo &kImprovementInfo = GC.getImprovementInfo(pPlot->getImprovementType());
					if (!kImprovementInfo.isActsAsCity())
					{
						return 0;
					}
				}
			}
		}
	}

	for (int iI = 0; iI < NUM_DIRECTION_TYPES; iI++)
	{
		CvPlot* pLoopPlot = plotDirection(pPlot->getX_INLINE(), pPlot->getY_INLINE(), (DirectionTypes)iI);
		if (pLoopPlot != NULL)
		{
			if (pLoopPlot->isCity(true))
			{
				return 0;
			}
		}
	}

	CvArea* pSecondWaterArea = pPlot->secondWaterArea();
	if (pSecondWaterArea == NULL)
	{
		return 0;
	}
        //I think this should be std::max
	return 10 * std::min(0, pSecondWaterArea->getNumTiles() - 2);
}
 
vetiarvind said:
@BSPollux Could you see my edit in the previous post and try that way out?
Click to expand...

Thanks for the reply! I tried it.

I can delete the heavy artillery.
Afterwards I can select the other stack without problem.
If I add a new artillery to the city again, the problem is back, just the same.

Here's the save, if you want to try if you have the same problem with it.

Edit: I'll try out Dawn of a new era for now. Please let me know if you find a way to fix this bug. Your mod seems great and I would like to play it, but I really don't want to have to use the worldbuilder each turn
 

Attachments

  • Hernan Cortes AD-1520.ColonizationSave
    461.3 KB · Views: 147
vetiarvind said:
I was wondering if there were any art files that were used as part of this mod as well?
Click to expand...
It doesn't look like the exe installer gave me any art files. All references must be in vanilla. I can't find the files mentioned meaning they must be in one of the 8 fpk files. I'm not going to unpack those, at least not right now. Graphics will have to wait.

I'm not sure if I like the concept of having two different types of forts. I find that a bit too complex for gameplay, especially if we want the AI to figure out forts.
 
BSPollux said:
Here's the save, if you want to try if you have the same problem with it.

Edit: I'll try out Dawn of a new era for now. Please let me know if you find a way to fix this bug. Your mod seems great and I would like to play it, but I really don't want to have to use the worldbuilder each turn
Click to expand...

Well, this isn't my mod. The last two retired modders of the game are RayStuttgart and Schmiddie and a few others. I am a mod-modder of R&R and unfortunately since I run my own mod-mod on my machine, I cannot test your save directly. Your error is something I haven't faced actually (the one I described is minor compared to your issue) and maybe some other modders maybe able to look into your savegame.

Nightinggale said:
I'm not sure if I like the concept of having two different types of forts. I find that a bit too complex for gameplay, especially if we want the AI to figure out forts.
Click to expand...
The "super fort" doesn't have upgrades AFAIK. Also, it consumes a pioneer i think and has less defensive abilities. Which is why i thought of having outposts vs forts. Forts for internal protection and outposts for territorial expansion. Currently AI ignores the R&R fort, but maybe you are right. I may well merge the two together (so the "super fort" functionality replaces R&R fort and upgrades to a large fort).
 
I've encountered the bug BSPollux is talking about. It comes from the new "heavy artillery" unit.

I've found a solution though! Press control+left/right arrow to rotate the view (remember that you can now rotate the view by 360 degrees). Generally there is a view where you can select your unit. That's how I'm doing and it makes the game at least playable again.

I think the bug is graphical so Schmiddie could solve it. It's just as if the unit was surrounded by a huge transparent screen that would be clicked instead of what is located "behind" it.

The bug is specific to that heavy artillery unit. I'm really convinced that it comes from its associated art file.
 
Great news! Thank you Marla!

I suspected the same 'hit box' problem, thats why I tried zooming in and out, but I didn't try rotating. Lets see if it works...

Edit: Yep, it works! Thank you Marla! Surprisingly quick and precise help, concidering the size of the community!
 
Marla_Singer said:
For once I feel useful on this board, now I only need to learn Python.
Click to expand...
You have been useful several times in the last few days and I never considered you dead weight. I'm not sure I would have figured out the graphical box issue.

I wonder about the learn python thing. Python is used to make the user interface, not really the features. Most of the actual features are written in C++. Besides with Schmiddie retiring, I'm not sure if there are any graphical artists left. Worth to keep in mind if you are going to learn a new ability from scratch.

I'm not trying to force you to do anything. If python is what you want, then it's fine with me. I just want to make sure you don't spend time learning something and then figure out later you would rather have learned something else.
 
I think the bug is graphical so Schmiddie could solve it. It's just as if the unit was surrounded by a huge transparent screen that would be clicked instead of what is located "behind" it.
Click to expand...

I have noticed the bug, but I cannot solve it. I have looked after the files, but they are fine and there is no obvious problem with the canon files. I'm sorry, but I cannot help in this regard. :dunno:
 
Schmiddie said:
I have noticed the bug, but I cannot solve it. I have looked after the files, but they are fine and there is no obvious problem with the canon files. I'm sorry, but I cannot help in this regard. :dunno:
Click to expand...
The bug comes from the "Imperial_Cannon.nif" file.
When you replace that file with the one of the royal artillery, it works all well (but with the royal artillery graphics of course). So it's necessarily in that file that the bug is.

As all the animations and so on seems to work the same between the heavy and royal artilleries, maybe a solution could be to start from the royal artillery NIF file and replace the cannon body by the one of the heavy artillery. Maybe this could be tested?

I don't have the tools to perform this by myself so I have no idea if it can be done easily.
 
I know, that a bug should come from this file if there is a bug. - As I said, I have tested the files. I don't want to replace the cannon body since I like the new one.

The animations are different - that's one feature of the new artillery version!

The tools can be found easily via this forum / google.
 
I love the new heavy artillery graphics too! My idea was actually to start from the royal artillery file, import the heavy artillery body in it and save it as the new heavy artillery file (so that we could keep the graphics but without the bug).

I have downloaded something called "Nifskope". It seems I can open the files with it but I'm not sure I can modify them.
 
Marla_Singer said:
I love the new heavy artillery graphics too! My idea was actually to start from the royal artillery file, import the heavy artillery body in it and save it as the new heavy artillery file (so that we could keep the graphics but without the bug).
Click to expand...

That does not work. I have already tested this yesterday. But I will have a look at the cannon model. Maybe something went wrong with blender.
 
Thanks a lot Schmiddie! :)

As I was looking at all the artillery files to see if I could find a solution by myself, I was wondering, what about adding a royal touch to the royal artillery? Even if they already don't have the same aspect, this could always help to visually distinguish them from the heavy artillery.

Here's just a personal test:
 
Marla_Singer said:
The bug comes from the "Imperial_Cannon.nif" file.
When you replace that file with the one of the royal artillery, it works all well (but with the royal artillery graphics of course). So it's necessarily in that file that the bug is.
Click to expand...
I have up with the very same idea for testing this bug. However you beat me to actually do it. Next question is what to do about it. Maybe the invisible polygon is far from the unit meaning you would have to zoom out a lot to see it.

BSPollux said:
Oh my god, what did I do?
So much work just for my little bug!
Click to expand...
Yeah and I want to shoot you for it. Unfortunately there is a buggy artillery, which prevents me from clicking on my musketmen and ordering them to fire. I guess we are stuck with you :cringe:
 
Hi Folks,

good news: I solved the problem. It was necessary to rebuild the unit completely (work in blender and nifskope), but it was worth to do it. Now the unit works fine!

I will upload a bugfix shortly for all heavy artillery units.

EDIT: Please find attached the "emergency bugfix". :)

Copy the files directly into your "Mod" Folder (please have in mind that you maybe will have to change the name of own your RaR folder if you have changed the name of your mod to your personal taste).
 

Attachments

  • Religion and Revolution_bugfix_heavy_artillery.rar
    709 KB · Views: 82
I've had to do a couple of small bug fixes in R&R code while testing the "Super Forts" mod merge with my mod-mod. Schmiddie, maybe you can incorporate them as well?

I was getting the following assert error. Image
In xml\units\CIV4UnitClassInfos.xml:

Code: 
<UnitClassInfo>
	<Type>UNITCLASS_LIGHT_ARTILLERY</Type>
	<Description>TXT_KEY_UNIT_LIGHT_ARTILLERY</Description>
	<DefaultUnit>[I]UNIT_LIGHT_ARTILLERY[/I]</DefaultUnit>
</UnitClassInfo>

I had to change this DefaultUnit to UNIT_LIGHT_ARTILLERY_VETERAN

Similarly this was also done for Heavy Artillery. (i.e change UNIT_HEAVY_ARTILLERY to UNIT_HEAVY_ARTILLERY_VETERAN)

Also, in CvPlot.cpp a couple of bug fixes for some asserts that were failing, although I think these are minor. However, I'm a bit OCD about loose ends, so here they are.
Spoiler :

Code: 
CvPlot::changePlayerCityRadiusCount(PlayerTypes eIndex, int iChange)
{
    //R&R mod, vetiarvind, bug fix for city radius going below zero. - start
    if(m_aiPlayerCityRadiusCount[eIndex] < 0) 		
	m_aiPlayerCityRadiusCount[eIndex] = 0;		
   //R&R mod, vetiarvind, bug fix for city radius going below zero. - end
   
//an assert failed where radius could go below 0
}
CvPlot::changeVisibilityCount(TeamTypes eTeam, int iChange, InvisibleTypes eSeeInvisible)
{
                m_aiVisibilityCount[eTeam] += iChange;
		//R&R mod, vetiarvind, bug fix for visibilty going below zero. - start
		if(m_aiVisibilityCount[eTeam] < 0)
			m_aiVisibilityCount[eTeam] = 0;
		//R&R mod, vetiarvind, bug fix for visibilty going below zero. - end
                //an assert failed where visibility could go below 0
}
 
You must log in or register to reply here.

Similar threads

Anarcomu
  • Locked
Bug discussion before report (on Github)
Replies
8
Views
604
Recursive
Recursive
S
Desert War + American Revolution
Replies
0
Views
196
seems_legit
S
Leoreth
Preparing the v1.17 Release
2
Replies
24
Views
7K
MalayanGamer
MalayanGamer
raystuttgart
[Work Coordination] Todos for Release 4.1
2
Replies
24
Views
3K
raystuttgart
raystuttgart
blackbutterfly
[Scenario] Robot Revolution
Replies
0
Views
231
blackbutterfly
blackbutterfly
Top Bottom