Fall Further 050 Bug Report Thread

[xienwolf]

If iCon is negative and just HAPPENS to exactly equal iAdjustedFoodDifference you can still wind up with a 0 net result (can't happen on iCon positive because the other is restricted to always be positive or 0). But yeah... I don't see any possible lore justification for having a population natively produce food. It would be a strange mechanic doubtless, and interesting to try and balance out, but it just wouldn't make much sense.... (Here, play a Civ of Super-Farmers! Oh wait! Lichen-encrusted Treants! Oops, you realized the power of using Conquest! The world... it asplode)

 

[xienwolf]

Finally got time to look over CvPlayerAI::AI_calculateUnitAIViability(). Turns out I was giving the function too much credit for use. It is ONLY used to keep the AI from building pirate AI ships when it is capable of building non-Pirate AI ships that are twice as strong. So it wouldn't have any effect on the AI failing to use Archers for city defense. There is some potential for the function to be useful for more checks when we get around to cleaning up city build choices though, so it'll be padded out better in the future release versions.

 

[Thunder_Gr]

Sorry, thought that I had posted the preferred method for that function as well. The preference would be instead of setting eLoopUnit = (UnitTypes)iI to just place everything after assignment of eLoopUnit in a "If (eLoopUnit != NO_UNIT)" block. Then it won't evaluate the NULL unit for combat strength and attempt to replace the currently selected "Best Unit" for the job.

I did take a closer look at the code.

It seems a

if (eLoopUnit==NO_UNIT) continue;

should be better. What do you think?

 

[xienwolf]

Not entirely certain what continue command does. Forces it to stop the current loop and move straight to the next value? If so, same thing as nesting everything in an IF statement really.

 

[Thunder_Gr]

Not entirely certain what continue command does. Forces it to stop the current loop and move straight to the next value? If so, same thing as nesting everything in an IF statement really.

continue is used to force any loop go to its evaluation statement without executing the body of commands that follow the statement. So, yes, effectively, in this situation, is like enclosing everything in an if block, but in an easier way, and without an extra block .


And, an actual bug:
Khad's "Redeemed" promotion does not allow for Heroic Strength and Twincast promotions!! It has to be a bug!

 

[Iceciro]

Of course they have all the same DLL, right? I was ready to post a warning about waiting for an official patch for multiplayer use, and use the DLLs provided only for single player..but I was too late, it seems.

Yeah, we all do.

Ehh, I probably would have tried it anyways if you did. We were needing a new DLL because the game was going back to it's old "crash everywhere" habits around turn 375 with all of us on a Large map (I/the group usually play Huge maps in FFH with no problems at all) and killed a really good game. Generally speaking it'd be a crash whenever one of the AIs called up to harass me, so I figured the new DLL might fix that for our next game. I know once or twice it crashed out when I tried to open an advisor's screen, too. It seems like there's a second, smaller memory leak that takes longer to bite, but does so all the same.

This is actually what's killing Fall Flat from being publicly released... If I can't play a stable game, it's harder to test things. The stability I was getting in AI Autoplay seems to be just contained to.... AI Autoplay. >_> If I'm actually playing I get crashes in the 350's and on.

 

[xienwolf]

Regarding Kahd: Code does EXACTLY what it is written to do, so that isn't a bug, that is a balance question. And I don't touch balance.

 

[Thunder_Gr]

It seems that the current "continuous cast" spell system is a bit..."unstable". What I mean:
When you cast haste, the unit that casted the spell, cannot cast anything at the next turn.
2 turns later, it appears that every unit capable of casting can cast whatever they want, the haste is preserved. The only need to keep everyone hasted is to have a unit capable to cast haste, but they can cast whatever they like...
So, this is a bit...unsettling, I dare say, and, epecially the fact that next turn the unit cannot cast, can be a major problem.

EDIT:

Regarding Kahd: Code does EXACTLY what it is written to do, so that isn't a bug, that is a balance question. And I don't touch balance.

The only Khad hero cannot be a real hero? Eeehhhmmm...OK, I will bring it in the balance thread, then...

This is actually what's killing Fall Flat from being publicly released...

Perhaps I could help if I join the list of your beta testers .

 

[xienwolf]

If you cast Haste this turn you should be quite capable of casting again the next turn. If that is not the case, then that is the broken piece of the puzzle. It is intended to work like Hope, Inspiration and the other temporary building setups.

 

[Iceciro]

Perhaps I could help if I join the list of your beta testers .

Beta is for the forums, alpha is what we're doing now. I have the same crashes in Fall Further too, so I'm not just sitting here hopping up and down because my mod doesn't work, sadly. That'd be easier for me to fix, if the issues were somewhere I screwed up I wouldn't be surprised to learn this is not a Fall Further issue either, but like the first crash, belongs to core part of the DLL and is just affecting Fall * because we do so much more in the same system.

In all seriousness, the fact that Diplomacy windows kill it is the worst part, because you can't get around that. Is there a fix for the diplomacy issue in the DLLs posted above? There's no way to tell Arendrel to stop bothering me every two turns about some lizardmen who are kicking her butt.... so crashes tend to abound.

 

[Asuhrie]

I regularly play games on Huge Map settings. Yesterday I played a huge game to about turn 200 when I got my ass kicked, so I went back to the create game screen to start a new one. However, now anytime I choose a huge map size, when the map tries to create itself, it gets stuck in an endless loop or something. The bar sits at about 15% (below that disk icon) and it says initializing, but it will never finish. Duel size seems to load fine, but even after starting a duel game Play Now! (ugh!) and then trying to start a huge map again, I encountered the same problem.

I figure it might have something to do with settings or whatnot. I don't know if there is any kind of settings file that might help you solve this issue, but if there is, I will supply it.

Get back to me by tonight though, because if I don't hear from you, then I am going to erase and reload Civ (I already reloaded FF and that did not work) - I'm really itching to get back at the Balseraphs - damn freaks.

 

[xienwolf]

How long have you let it sit? I know that sometimes my computer takes quite a long time to get the progress bar past the first little chunk, then it goes quickly through the rest.

 

[Asuhrie]

Yeah, it takes my computer awhile too. I didn't time it, but I'm sure I let it sit for at least 10 minutes one of the times. Longest I have ever seen on my computer wasnt anywhere near that.

 

[War Chicken]

I got a really strange thing going on here:

As you can see, I neither have anarchy nor anything else, but my city isn't producing, doing research or anything else.
Notice the unhappy people display in the upper part - it just displays 0
instead of something like 10 > 6

The last thing I did was building Thaumaturges Keep...

What is going on here? of have I found some mean bug I never noticed before.
If it has been reported earlier - sorry, but I was way too confused to read the whole thread.

Forget about it. That moron Auric cast stasis, and I was to dumb to notice.

 

[ICanHasName?]

As the Scions that one song just plays over and over with about a minute delay in between. Other civ's music doesn't play in the diplomacy window and in fact, everything except the little interface button sounds seems to be cut off after a fraction of a second (like the battle won/lost sounds, spellcast sounds, etc).

 

[MootPoint]

I'd need longer to look things over, and maybe to step through it with a debugger. But I would imagine that the main issue is units not being passed a valid mission assignment during their doTurn pass. Thus the ideal fix might be to install a second loop over all units to re-assign them missions, or isolating why one unit wasn't assigned a SKIP mission after failing to be assigned anything else.

Hmm... What about this, in CvUnitAI.cpp, in AI_update():

/*************************************************************************************************/
/**	Xienwolf Tweak							01/04/09											**/
/**					Clearing Asserts and helping the AI stop looping so much					**/
/**Near as I can tell, this is refusing to allow the unit to do ANYTHING if it winds up isolated**/
/**	I personally don't care for that, but it makes sense to keep the AI from trying to move the	**/
/**	Unit, so need to re-apply this once I figure out how to check for possible missions/spells	**/
/**				before canceling the unit's ability to make any movements						**/
/*************************************************************************************************/
/**								---- Start Original Code ----									**
//FfH: Added by Kael 12/22/2007
    CvPlot* pPlot = plot();
    CvPlot* pLoopPlot;
    bool bValid = false;
	for (int iDX = -1; iDX <= 1; iDX++)
	{
		for (int iDY = -1; iDY <= 1; iDY++)
		{
			pLoopPlot = plotXY(pPlot->getX_INLINE(), pPlot->getY_INLINE(), iDX, iDY);
			if (pLoopPlot != NULL)
			{
			    if (canMoveOrAttackInto(pLoopPlot))
			    {
			        bValid = true;
			    }
			}
		}
	}
    if (bValid == false)
    {
		getGroup()->pushMission(MISSION_SKIP);
        return false;
    }
//FfH: End Add

Stubbing this out could potentially explain why these units aren't getting the MISSION_SKIP option - maybe this code chunk needs to be reinstated at the end of the function, if no other valid AI moves are applicable?

 

[notque]

Hmm... What about this, in CvUnitAI.cpp, in AI_update():

If that's the problem it should be very easy to test. I was thinking about bringing that code back anyway since I need it to keep stranded units still for boat pickups.

 

[xienwolf]

Keep on forgetting about that one. Now that I merge regularly with an SVN I need to make a change in that so I see it on a daily basis and CAN'T forget to come back to it sometime. Also I've made tweaks in other locations which work nicely to fix the issue of these units failing to cast spells (though it will still result in these units piling up on 1 tile islands).

I'll clear the block on that function and see if it helps the posted WoC.

 

[MootPoint]

I've kept picking away at this one, and although I was hoping that my previous suggestion had merit, I think it's deeper than that.

While digging, I noticed this oddity: there's an indication that there's supposed to be a code mod here, but the commented out code is the same as the currently executing lines..?

CvSelectionGroup.cpp, line 3168:

/*************************************************************************************************/
/**	Alertness								11/30/08	Written: Pep		Imported: Xienwolf	**/
/**																								**/
/**			Prevents annoying accidental attacks when moving into non-visible tiles				**/
/*************************************************************************************************/
/**								---- Start Original Code ----									**
		if ((pLoopUnit->canMove() && ((bCombat && (!(pLoopUnit->isNoCapture()) || !(pPlot->isEnemyCity(*pLoopUnit)))) ? pLoopUnit->canMoveOrAttackInto(pPlot) : pLoopUnit->canMoveInto(pPlot))) || (pLoopUnit == pCombatUnit))
		{
			pLoopUnit->move(pPlot, true);
		}
/**								----  End Original Code  ----									**/
		if ((pLoopUnit->canMove() && ((bCombat && (!(pLoopUnit->isNoCapture()) || !(pPlot->isEnemyCity(*pLoopUnit)))) ? pLoopUnit->canMoveOrAttackInto(pPlot) : pLoopUnit->canMoveInto(pPlot))) || (pLoopUnit == pCombatUnit))
		{
			pLoopUnit->move(pPlot, true);
		}

 

[xienwolf]

Crap, I'll have to spend some time on that one. It is a part of very few bits I borrowed from an outside source and kept. Ideally, the commented out block doesn't match the original code (quick diff check against FfH will show that one true or not). I did only merge in part of the code however, so it might be that I retracted that change later on to fix some bugs (initially it misfired and kept you from being able to move in a manner that was NOT an attack if an enemy was next to you).


Anyway, the good news is that if the code IS the same as the base, then it shouldn't cause any problems I am quite certain that the code does do what it was designed to do still (to test, place a scout near the edge of your visible terrain, such that he can move into a tile he cannot see. Elven Scouts in the middle of a forest work great. Then place an elephant in the tile which you cannot see, and give the scout an order to move there. If he attacks the elephant, this merge has broken. If he moves 1 tile instead of the ordered 2 and asks for new instructions because his path is blocked, the merge is doing what it should)