EmperorFool
Deity
Are you using the SVN.RAR nightly snapshot to install BUG? If so, you must remove the old CustomAssets folder because in this case files were removed.
Bug Reporting
- Thread starter alerum68
- Start date
I see. I was copying from svn tree web site - I now remember there was an extra file on my system that wasn't in the tree. Thanks.
Cross Cowboy
Warlord
- Joined
- Jan 15, 2008
- Messages
- 253
Having issues with HiTM and just wanted to know if anyone can look at the Python Log and see if anything stands out. Im not sure its anything to do with BUG at all, but just trying to eliminate anything I can. Thanks much!
EmperorFool
Deity
The log seems to end prematurely. Are you getting Python exceptions? If so, post them. If not, post the PythonDbg.log and PythonErr.log files. Make sure logging is turned on in CivilizationIV.ini: LoggingEnabled must be 1.
Cross Cowboy
Warlord
- Joined
- Jan 15, 2008
- Messages
- 253
I hope these are the 2 you wanted.
EmperorFool
Deity
Everything looks fine in the debug log, and there are no errors present in the error log. What exactly is not working?
Cross Cowboy
Warlord
- Joined
- Jan 15, 2008
- Messages
- 253
It seems most Vista users (including myself) are getting random ctds. I get them every game, so I was just doing some checking to try and eliminate options. If everything looks great in the files, thats one less thing we now need to consider. i appreciate you taking the time to check them out! Thanks so much!
EmperorFool
Deity
What I can say is that Python will not cause a CTD. You can write Python code that will call one of the API functions which call into the SDK (C++), and that can cause a CTD. So you can write Python code that will cause a CTD, but it won't be the Python that actually CTDs.
For example, a car can crash. If the driver is impaired or can't drive well, they may crash the car. However, the person doesn't crash--the car does. The person is just the cause of it. Does that make sense?
If HiTM uses a custom DLL, create a debug version with assertions turned on in it. This should then tell you what is the ultimate source of the crash. Usually it's an array bounds violation. For example, giving a player tech # -1 or checking if a city has the NO_RELIGION (-1) religion.
For example, a car can crash. If the driver is impaired or can't drive well, they may crash the car. However, the person doesn't crash--the car does. The person is just the cause of it. Does that make sense?
If HiTM uses a custom DLL, create a debug version with assertions turned on in it. This should then tell you what is the ultimate source of the crash. Usually it's an array bounds violation. For example, giving a player tech # -1 or checking if a city has the NO_RELIGION (-1) religion.
Cross Cowboy
Warlord
- Joined
- Jan 15, 2008
- Messages
- 253
Thanks so much Emperor, Grave is now thinking its a Vista issue. Thanks for answering my question on this, you wouldnt by chance know where a fix for ctds for Vista users would be at would you? 
EmperorFool
Deity
You wouldnt by chance know where a fix for ctds for Vista users would be at would you?
I haven't worked with Vista, but I believe the suggestion you got to build a debug version with asserts turned on is your best bet.
I installed BUG 3.6 and then I installed BAT 1.1. I installed BUG 3.6 for multi-player (meaning Program Files\...\Mods). BAT 1.1 installed standard (meaning My Documents...\Mods).
I started a game using the BAT mod and chose 12 civs total with me being American civ. Once the game started I hovered over my initial Warrior and noticed that it stated that the upgrade for this unit was the Incan UU Quechua. I exited the game.
I started another game but this time loading only BUG 3.6 mod. Same setup 12 civs, I am American. I hovered over my initial Warrior and it again said the upgrade for this unit was the Incan UU Quechua. I exited the game.
I started the game again with no Mods, same setup 12 civs, me being American civ. I hovered over my initial Warrior and no upgrade for this unit was listed.
I believe this is a bug and that the upgrade for this unit as an American civ should not be the Incan UU Quechua.
Please let me know about this.
I started a game using the BAT mod and chose 12 civs total with me being American civ. Once the game started I hovered over my initial Warrior and noticed that it stated that the upgrade for this unit was the Incan UU Quechua. I exited the game.
I started another game but this time loading only BUG 3.6 mod. Same setup 12 civs, I am American. I hovered over my initial Warrior and it again said the upgrade for this unit was the Incan UU Quechua. I exited the game.
I started the game again with no Mods, same setup 12 civs, me being American civ. I hovered over my initial Warrior and no upgrade for this unit was listed.
I believe this is a bug and that the upgrade for this unit as an American civ should not be the Incan UU Quechua.
Please let me know about this.
I can say for 99.9% certain that BUG doesn't touch files that control that. The reason that it's not displayed when you played without BUG as showing unit upgrades is a feature. Have you tried actually upgrading the unit? If it does upgrade to a Quechua, it sounds to me like you (or someone else on your PC) has been experimenting with changes in your core files and hasn't changed them back. If I were you, I would try re-installing Civ and the expansion packs and see if the error persists. I can almost guarantee that it won't 
EmperorFool
Deity
mcorey is talking about the PLE unit hover, which BUG/BAT do add. I'll have to double-check, but I believe it's only telling you the UUs that replace the unit for other civs. The upgrade display will show you the cost to upgrade and be colored depending on whether or not you can afford it.
Thanks everyone for responding. This may not be an issue as I may have misinterpreted what BUG/BAT is doing.
To clarify where I am hovering it is over the unit button on the main screen. I have the BUG options checked for health (green) and movement (blue) displayed on the button. I would attach an image if I knew how to get one out of BTS.
Also, I did uninstall BAT and uninstall BUG and it did not occur. I reinstalled BUG 3.6 and it came back. Also I ran through some turns to get to the point where I can upgrade the Warrior and the Incan UU was not offered as an option.
So again this may not be a problem, but thought I post to make sure. Thanks.
To clarify where I am hovering it is over the unit button on the main screen. I have the BUG options checked for health (green) and movement (blue) displayed on the button. I would attach an image if I knew how to get one out of BTS.
Also, I did uninstall BAT and uninstall BUG and it did not occur. I reinstalled BUG 3.6 and it came back. Also I ran through some turns to get to the point where I can upgrade the Warrior and the Incan UU was not offered as an option.
So again this may not be a problem, but thought I post to make sure. Thanks.
r_rolo1
King of myself
There seems to be a small issue with the Field of view feature. Not sure if already reported....
ruff_hi
Live 4ever! Or die trying
This behaviour was noted during discussion of the field of view (FoV) feature when I was adding it to BUG. We tried to eliminate it but there is nothing we can do. If you check the HOF mod (where we lifted the FoV from), they do not reset the city screen value when cycling thru cities - you stay zoomed out / in for every city.
Yamps
Deity
I've posted a bug report on SourceForge.net about WHEOOHRN notification, but it's actually a different kind of bug:
WHEOOHRN notification without Writing - ID: 2758701
Transcription:
Response by EmperorFool:
The tracker is closed now on SourceForge, but this actually means that there is a bug with CTRL + click. (IMO at least.) It's not normally possible to access the trade screen without that shortcut if Writing is not discovered, there is no "We would like to make a trade proposal" text to reach the trade screen. I don't think this is intended behavior for the shortcut, to override sth that's not normally possible. (Why is there a requirement of Writing to get the "We would like to make a trade proposal" message?)
However, I realize that this is a core game bug, not a BUG issue. I think this is significant, in particular it enables you to REX and get back with cottages and delay Writing. You'll know with CTRL+click if sb is out there to get you.
WHEOOHRN notification without Writing - ID: 2758701
Transcription:
There is a notification in the scoreboard that AI (Napoleon) is planning a
war even though neither of us have Writing. Without BUG, it wouldn't be
possible to tell that he is planning a war.
This is in BUG 3.5.7.1, save attached.
Thank you for your efforts!
Response by EmperorFool:
The tracker is closed now on SourceForge, but this actually means that there is a bug with CTRL + click. (IMO at least.) It's not normally possible to access the trade screen without that shortcut if Writing is not discovered, there is no "We would like to make a trade proposal" text to reach the trade screen. I don't think this is intended behavior for the shortcut, to override sth that's not normally possible. (Why is there a requirement of Writing to get the "We would like to make a trade proposal" message?)
However, I realize that this is a core game bug, not a BUG issue. I think this is significant, in particular it enables you to REX and get back with cottages and delay Writing. You'll know with CTRL+click if sb is out there to get you.
EmperorFool
Deity
Writing isn't a requirement for the button as it appears if you can trade a resource. It seems to me the intent of hiding the button is simply a convenience: it only shows it if you have something to trade so you don't waste your time in the early game. As soon as you have an agreement or resource to trade, the button appears.
In any case, changing this would clearly violate the UG mantra, even if it seemed to be the game designers' intent. Furthermore, it would require a fix in the DLL--not Python.
In any case, changing this would clearly violate the UG mantra, even if it seemed to be the game designers' intent. Furthermore, it would require a fix in the DLL--not Python.
Yamps
Deity
I see, possible deals get the option. I did test gifting Writing in WB, it gave the option to reach the trading screen. That has to be because Writing enables OB, that's a trading option that gets it. I guess they didn't think that reaching the trade screen with a shortcut when there are no trading options is a problem. Well, it sure is useful. It doesn't feel quite right though that a shortcut gives you info that you can't otherwise get, it can be pretty nasty if you don't know the trick and you get attacked unexpectedly.
Anyway, thank you for your explanation!
It doesn't feel quite right though that a shortcut gives you info that you can't otherwise get, it can be pretty nasty if you don't know the trick and you get attacked unexpectedly. Anyway, thank you for your explanation!
I'm posting this in the Bug Reporting page but it is more of a minor complaint than anything.
I've noticed that when using BUG, particuarly in the later parts of the game, the lag that happens when you select units becomes unbearable. When there are stacks of 20+ units, picking one out of the stack takes more than a second just to select. More than 1 second for click to response is terrible obviously because we naturally can make mouse movements/clicks at a much higher speed.
I'm not sure what exactly causes the massive lag, but I am fairly certain it is something in BUG because when I load up the same savegame without BUG it once again becomes almost instant response clicks.
So firstly, what is the likely cause of this lag? Can it be disabled in BUG? If not, what steps could be taken to reduce the lag that's happening. The lag is bad enough that it's preferable to unload BUG and go with the barebones interface.
I don't want to finish on a negative note so once again I want to remind you all this is a great mod!
I've noticed that when using BUG, particuarly in the later parts of the game, the lag that happens when you select units becomes unbearable. When there are stacks of 20+ units, picking one out of the stack takes more than a second just to select. More than 1 second for click to response is terrible obviously because we naturally can make mouse movements/clicks at a much higher speed.
I'm not sure what exactly causes the massive lag, but I am fairly certain it is something in BUG because when I load up the same savegame without BUG it once again becomes almost instant response clicks.
So firstly, what is the likely cause of this lag? Can it be disabled in BUG? If not, what steps could be taken to reduce the lag that's happening. The lag is bad enough that it's preferable to unload BUG and go with the barebones interface.
I don't want to finish on a negative note so once again I want to remind you all this is a great mod!
Similar threads
