Éa III, Sword & Sorcery: Bugs/Crashes thread

Not sure if this should be posted here: Copper resource is utterly bugged now, it is totally invisible at all times. That means that the unimproved Copper tile looks like it has no resources and the half-built, built, and pillaged mines look like a mine of nothing at all - no slag heaps except the default small silver piles. I can take a look at the art files in case I can find the problem, but I suspect it's from using a Luxury Resource (which only has one quantity appearance) as a Strategic Resource (which can have more than one).
 
the copper bug is well known and has always been present. If you can find the problem it would be quite welcome, about time to be able to see that resource! (iirc though you can see it in the alternate view mode, I forgot its name)

@Pazyryk
did you have a chance to look at the LUA error? I lost yet another test game due to that.
 
If someone wants to track down the Copper problem, that would be much appreciated. I've spent maybe 15 minutes on it when it needs an hour I guess.

It's actually a re-color of Horem's "Tin" resource. So it is ART_DEF_RESOURCE_TIN. In ÉaII I was using the bace Civ5 "Copper" but it didn't display on hills. I think copper is just cursed no matter what I use.

IIRC, there were two fxsxml files for Horem's Tin resource that I thought might be the proper "constructed" resource:

mine_med_tim.fxsxml
med_mine_tin.fxsxml

I think I used the 1st one originally, then switched to the 2nd when that didn't work. The artdefs are all in CoreTables/ArtDefinesLandmarks.sql. The actual art resources are in the Media Pack in the folder Terrain/Copper or something like that.

The other thing I might be goofing up on are the tags ArtDefineTagHeavy, AltArtDefineTag, AltArtDefineTagHeavy in the Resources table (find in CoreTables.Terrain.sql). I've tried to follow other examples but it seems to be totally random whether these are left NULL or filled with the same value as ArtDefineTag.


Really, if an artist just provided me a new generic metal resource that functioned, then I can recolor it. I can't modify gr2 files to save my life, even just simple changes to referenced files. If I could, then I would just recolor iron or mithril (=aluminum) which both seem to display everywhere just fine. Cinnabar is also recolor of another of Horem's metals (Manganese iirc) and it seems to display everywhere OK.


@onedreamer, I'll take a look at your Lua log later tonight. It may be one of a dozen or so such errors that I've found and fixed in v7 (which has been running autoplay sessions every night for a week or more now ... usually getting up to turn 450+). I can't easily hotfix v6 anymore although I try to post manual fixes for things that come up for players.
 
I was just gonna ask if an Iron reskin was OK with you - I will have it to you by tomorrow night my friend! Hopefully this resolves the issue with Copper definitively. Can you PM me your email so I can send it to you? I don't want to upload such a minor thing for one mod and take up more space needed for fantasy units...
Or of course you could just copy all the iron files and recolor those... it would be much less buggy. Just make sure it's distinguishable from Cinnabar.
 
Forestry doesn't double the wood obtained by chopping.
 
@Pazyryk
did you have a chance to look at the LUA error? I lost yet another test game due to that.
I think this will fix it. In EaMain/EaUnits.lua, add the blue code in the line that threw the error (389):
Code:
local bMayBeSlowedByLongWall = iLongWallOwner and [COLOR="Blue"]iLongWallOwner ~= -1[/COLOR] and team:IsAtWar(Players[iLongWallOwner]:GetTeam())


Forestry doesn't double the wood obtained by chopping.
So you are getting 1 per chop (for 20 turns) with or without this tech? Just asking to make sure the base mechanic is working.
 
Forestry doesn't double the wood obtained by chopping.

more on Forestry. This tech seems screwed up. Apparently it adds timber (I haven't understood based on what math) from unimproved forests in range of a city (even in neutral and not necessarily in owned territory though) when you are neither pantheist nor theist and without even a timberyard or a sawmill built.

screenshot (no timberyards in the two towns) http://steamcommunity.com/sharedfiles/filedetails/?id=298068472
 
Posting here to say that the new Copper resource has been emailed to Paz - it's a reskin of Iron to a dark reddish-brown (one might even say "coppery":mischief:) color. I haven't heard back from him yet but it looked fine in Nexus so it should be fine ingame... hopefully that problem is now dead.
 
more on Forestry. This tech seems screwed up.
Was your 4 timber from recent chops? If you had done 2 chops in the last 20 turns and had Forestry, you would have 4 Timber.

I don't see anything in the screenshot indicating a bug, unless you give me more context.

Just so we're on the same page:

Timber (strategic) Each Timberyard provides 1 plus 1 per 2 sawmills (non-Pantheistic civs) or 1 per 8 unimproved forest or jungle (Pantheistic civs). Also gain 1 for 20 turns after forest or jungle chop on owned plots. Forestry tech doubles these amounts.

[Manual said something like 3 for 30 turns for a chop. Corrected to actual game numbers now. But I'm thinking about bumping up the turn number to 40 adjusted by game speed.]
 
Timber: oooops, I was completely confused and overlooked the part in bold, thinking the increase in chopping was production not the amount of timber. And yeah I had just cut 2 forests right after researching the tech. So Forestry works as intended (nice idea btw), pardon. 20/25 turns seems ok to me btw.


Nevertheless, it would be helpful to rule out (or rule in) PROMOTION_SLAVEMAKER once and for all. If someone wants to try that, delete (or comment out) the line in the Policy_FreePromotions table (find in CoreTables/Policies.sql). Then reload a game from before that policy was adopted. Then tell us what happens.


Still crashes. Been trying to fix this until now but no luck. I have high suspicions on this though (EaActions.sql):

Code:
--Non-GP alternate upgrades
INSERT INTO EaActions (Type,			Description,				UnitTypePrefix1,		UnitTypePrefix2,		UnitTypePrefix3,	TechReq,				UnitUpgradeTypePrefix	) VALUES
('EA_ACTION_UPGRD_SLAVES_WARRIORS',		'TXT_KEY_COMMAND_UPGRADE',	'UNIT_SLAVES',			NULL,					NULL,				NULL,					'UNIT_WARRIORS'			);

UPDATE EaActions SET PolicyReq = 'POLICY_SLAVE_ARMIES' WHERE Type = 'EA_ACTION_UPGRD_SLAVES_WARRIORS';

but if I remove it the mod goes fubar.

edit: I fixed it

Code:
('EA_ACTION_UPGRD_SLAVES_WARRIORS',		'TXT_KEY_COMMAND_UPGRADE',	'UNIT_SLAVES',			NULL,					NULL,				NULL,					'UNIT_WARRIORS'			);

UPDATE EaActions SET NormalCombatUnit = 1 WHERE UnitUpgradeTypePrefix IS NOT NULL AND Type [COLOR="Red"]!=[/COLOR] 'EA_ACTION_UPGRD_SLAVES_WARRIORS';
UPDATE EaActions SET PolicyReq = 'POLICY_SLAVE_ARMIES' WHERE Type = 'EA_ACTION_UPGRD_SLAVES_WARRIORS';

I changed the notequal condition in red to equal and crashes stopped.
 
Quicksilver: improving Cinnabar grants you 1 quicksilver, is this correct? From what I understood you had to build the furnace that would provide 1/2 (contradicting info on the manual) quicksilver from cinnabar.
 
Timber: oooops, I was completely confused and overlooked the part in bold, thinking the increase in chopping was production not the amount of timber. And yeah I had just cut 2 forests right after researching the tech. So Forestry works as intended (nice idea btw), pardon. 20/25 turns seems ok to me btw.
No problem, it's all very complicated... I certainly appreciate all the help you all provide tracking down bugs.

I changed the notequal condition in red to equal and crashes stopped.
You got it! What you've done is disabled the Slave -> Warrior upgrade by requiring the Slave to be a normal combat unit (which it isn't, so action is always disabled).

Your fix is a little messy because it removes that restriction from the other "alt upgrade" actions, which are intended to be normal combat units. (This has no effect though due to other restrictions.) A cleaner "patch" is just:
Code:
UPDATE EaActions SET NormalCombatUnit = 1 WHERE UnitUpgradeTypePrefix IS NOT NULL;

So now I just need to figure out why that action becoming available for Salves causes CTD. The "Sell Slave" and "Render Slave" actions work as far as I know (enabled when Slave in city with Slave Market or Slave Knackery).



Quicksilver: improving Cinnabar grants you 1 quicksilver, is this correct? From what I understood you had to build the furnace that would provide 1/2 (contradicting info on the manual) quicksilver from cinnabar.

In fact, Cinnabar = Quicksilver. Just like Grapes = Wine, Oysters = Pearls, and Sheep = Wool. It's just a "UI lie" that replaces the name of the resource on the map for some specific resources. So I'll call it Quicksilver since that is the actual resource name.

Quicksilver has TechReveal = Mining and TechCityTrade = Alchemy. The later is really the "can use" tag (Copper, Iron and Elephants also have differing "reveal" and "use" tags). That can be confusing because you can build a mine but not get the trade resource. You also don't get all the yield, since you are getting the raw resource yield plus raw mine yield but not the "mine on specific resource" yield.

Roasting Furnace requires (not "uses" but requires near city) Quicksilver to build. And it generates 2 Quicksilver.

I mentioned over on Balance thread that Quicksilver and Moly aren't really developed yet. Except there are the two buildings for Quicksilver that convert 1 of it to 1 Gold or 1 Silver.
 
So now I just need to figure out why that action becoming available for Salves causes CTD. The "Sell Slave" and "Render Slave" actions work as far as I know (enabled when Slave in city with Slave Market or Slave Knackery).

Those 2 buttons are your custom while this one is the normal upgrade button afaik. It could be hard coded (or hopefully somewhere else moddable) that civilian units can't have that option available.
 
OK, I found the d@#$ Slave Army bug ... possible after onedreamer narrowed down the action causing it.

It's generated by this line in EaMain/EaActions.lua:
Code:
			g_int2 = g_unit:UpgradePrice(g_int1)	--upgrade cost
That line fires to try to calculate upgrade cost for help text only when you click on the unit and the upgrade is allowed (from tech). Apparently running that line on a civilian unit causes a graphic CTD. Replace it with this:
Code:
		if g_eaAction.NormalCombatUnit then
			g_int2 = g_unit:UpgradePrice(g_int1)	--upgrade cost
		else
			g_int2 = 50
		end
I just tested and it works. Slaves upgrade to Warriors w/ slave promotion (-50% xp / -30 base morale unaffected by civ happiness) as intended.

Fixed in v7.

(@onedreamer, Return the line in EaActions.sql to what it was so that the action will work.)
 
maybe it was trying to calculate xp which are null or something like that?

Paz there's still a crash I think you didn't have a chance to examine, at post 477. Tell me if the save loads this time around.

- Lake Balisama natural wonder doesn't provide fresh water in the tiles around it. Maybe it should?
- Bjarmaland civ has no favored techs, is this intended?
- The Great Lighthouse doesn't seem to have an effect
- Sagittarii who are an upgrade to Bowed Cavalry show the same stats and cost. They should have the same stats as the footsoldier counterpart, Marksmen.
- Port seems to be limited to 1 per nation, I can't build any more after building the first in a current game.
- Armored Cavalry seems to have wrong prereqs because I can upgrade to it without the tech.
- I thought a certain line of techs were supposed to lower KM, but they don't.
- Rally Troops doesn't give XP to the Warrior GP.
- It seems that Berserkers gain the "treat rivers as roads" ability. Intended?
 
Something I wanted to mention, since in large battles it gets actually dangerous for Warriors: can you please ensure that when a Warrior Lead Charges an enemy he and the unit he is leading end up in the same tile at the end of the turn?
Examples of what happens when I fight now:
  • My Warrior leads a unit of Light Infantry against a Giant Spider. The Warrior slays the Spider on his own. He ends the turn in the tile formerly occupied by the Giant Spider. The Light Infantry follow him automatically and also end their turn in the tile occupied by the Warrior.
  • My Warrior leads a unit of Immortals against a unit of Heavy Infantry. The Warrior deals some damage but does not kill the Heavy Infantry. He returns to his original tile and ends his turn there. The Immortals then automatically charge in after the Warrior, finish off the Heavy Infantry, and end their turn in the tile once occupied by the enemy. Now the Warrior and the Immortals are in two different tiles...
Especially since Warriors tend to take a good bit of damage when charging Heavy Infantry, getting left behind like that in the middle of a siege or major battle is often fatal for the Warrior.
 
@Civtar, I'll add a little teleport code so the Warrior moves if the melee unit does (I had that there but I think I messed it up with some changes).

Also, Copper is fixed! It's in v7 and I saw it in autoplay session in various terrain. (Thanks Civtar!)


@onedreamer, I'll work through your 9-point list there. To be honest, I'm not sure if I will get back to that CTD. I'm really done (emotionally) with v6 and trying to get v7 out. It takes me 2-10 hrs to find these CTDs, and many of them (not all certainly) get resolved with each new version. There are literally dozens of code problems or potential problems fixed in v7 that aren't documented. Basically rebuilt systems where I saw some potential problems, such as city liberation/resurrected civ code and the GP "escape" code. (Let's hope more fixes than new problems...)
 
So I haven't been posting here but I've been knocking down many bugs every day. Gotten most listed above (should be noted in changelog when I update that).

One thing I did last week was implement a "strict.lua" system (see link in my sig). That has allowed me to find and fix literally dozens of mistakes in the code. Some had logical consequences, although many were obscure (area effect spells at the map X wrap, etc.) so maybe would never be reported here.
 
Back
Top Bottom