14-06-2003 05:49									#91
	Support Apolyton buy from Amazon

The crashbug which shows the ai stacktrace is due to the lack of an ai 'profile' in the relevant scneario files. If you want to bypass it, you can copy the ai sections of Delenda into the other scenarios civilisation section. I'll correct it so that it is not necessary, particularly if the -newai switch is not on, and adjust the scenario files as needed.

	14-06-2003 17:30									#92
	Get a bigger avatar today!

Thanks Guys! I got the diplo changes, Vovan, though I haven't implemented them yet. Thanks for the patch to make the scenarios work, Laurent. I am back to major RL for a bit, so other than critical support I won't be able to do much with the new stuff in the immediate future. In the next week or so, I'd like to have a version of the code settled down enough to send out to the scenario guys, so they can get back to working on them.

Cya,

Mark

	15-06-2003 14:40									#93
	Got spare money?

Vovan, can you check the isEnemy function? With your code added, everything is very peaceful. I didn't see why, but in game.military.lists.SquareData.getEncounter(), we check if the civs are enemies and Carthage and Rome aren't enemies. That's true of all scenarios, even though diplomatic status has been set to war in the scenario file. Can you check this? Also, it looks like you could use singletons for your diplomatic statuses rather than calling new War() every so often?
The good point is diplomacy has an effect on the game. I'll implement it so that you dont take territory of a civ you're not at war with.

	19-06-2003 04:18									#94
	unit transport Support Apolyton, buy Civilization 2

Hey guys, I am new to the team and lemme just say I'm thrilled to be working with all of you on this project. The first thing I have been looking into which seemed a good easy thing to start on is bug #166, to refresh your memory:

quote: --166 (Heffalump/Mark) It looks like a bug has crept into the unloading menu code. Below is the way it usually works. To unload: 1. put the ship on a coastal square 2. left-click on either a ship in the carrying TF or the carried TF and select the unload option. That's it. It looks like the bug is making those unload options not appear at first. This results in a very short set of options. A work-around is to select the transporting TF with a mouse click. This makes at least the unload option for the ship appear. Selecting the carried TF seems to make the unload option appear for those.

It's a simple fix to get to work the way Mark intended. But while looking into the code I noticed there's another bug here... it won't let you take a task force of ships and load more than one individual unit on them, even if they can fit. As a demonstration, load up Carthage scenario and grab the three trireme task force on sicily. Loading that lone legion is no problem, now sail over to another place with a lone legion and try to laod him: it won't let you. Now empty the ships, take two legions and combine them into one task force. Now you can load them both together. This too is a simple fix but I just wanted to let you know about it.

Now while working with this I thought there was ways I could improve it a little bit but I need to see what you all think. One thing is, it looks like if you have several units on a ship, and click the unload command, you dump them all off. I was thinking it might be nice if you could right-click the particular unit you want to unload and unload him individually, or right-click the ships to get an 'unload all' command. Let me know what you think.

-Tony

	20-06-2003 04:15									#95
	Re: unit transport Suffering from ads?

Hey Tony, an official welcome to the forum!

quote: Originally posted by TheDarkside One thing is, it looks like if you have several units on a ship, and click the unload command, you dump them all off. I was thinking it might be nice if you could right-click the particular unit you want to unload and unload him individually, or right-click the ships to get an 'unload all' command. Let me know what you think.

This sounds good to me, although maybe it should be by TF rather than by unit. However I'm not really up on that part of the interface and code, so there might be some bad ramification that I'm not thinking of to do it that way. Be best to see what Laurent and Gary think. However their web access is in short supply now, so if there isn't much time invested to do it, you could just try and see how it works.

Great to have you in the team!

	21-06-2003 16:34									#96
	Tired of ads?

There is one loaded land TF per naval TF, not one unit.
The most important thing is that a TF must be carried by a single naval TF, otherwise, you have headaches figuring out what happens when you split the naval units.
If you want to load several units on a ship, it's better to have them all in a single TF right now because the code behaves that way. I'd rather keep it this way because I think we have enough lists everywhere and there's no point adding a list where a single TF can work as well.
The point is we should be able to add units to the carried TF if the boats allow it.
The best would be to add the units to the carried TF, is the carrier has the capacity to do so, so that we can retain a single TF carried by the ship.

	22-06-2003 18:58									#97
	Support Apolyton buy from Amazon

Good points Laurent. Your approach sounds like a good one to me, at least for now. In the future I can see some players being annoyed by the single-TF limitation. What do you think Tony?

	24-06-2003 05:35									#98
	Suffering from ads?

OK that sounds like a good compromise. I will make new units (who can fit) added to the existing TF. However, what if you want to add another TF to a fleet which already has a TF? Should we allow this? What if we do allow it and merge the TFs, with the dominate TF being the one who already is loaded? Change the text in menu to say "Merge with task force already loaded" or something along those lines...

	24-06-2003 05:48									#99
	Avatar Enlargement: We've got the solution

Your take on it sounds good to me Tony.

	14-07-2003 17:23									#100
	Support Apolyton, buy Civilization: The Boardgame

I'm tracking lots of NullPointerExceptions when the new ai is enabled. Some are due to multithreading, so I have to add a few synchronized blocks where it makes sense. Others come from other bugs, ot maybe not bugs:
A civ may not have a capital. This can happen if it only has units, but no square, but maybe sometimes too when it had no square and, later, conquered a new one. I am not absolutely positive about that, but I know I shouldn't plan to take a capital if there is none.
What's the exact role of a civ capital by the way? Currently, taking cities or capitals is not that useful in itself, it is just a kind of heuristic which tells the ai that a square looks interesting. Being a heuristic, it lends itself to abuse easily, so I ask: what is a civ capital for?

	15-07-2003 07:20									#101
	Full PM-box? Change here!

Hi Laurent, sorry to hear about all the null pointers. I only have a few minutes now, but I'll say what I can. . .

Capital location is intended to be used primarily in the govt/social/riots models. Essentially it is the point of administrative control by the ruler, and so can be of importance in quality of administration, likelihood of revolt etc. It is also an obvious focal point for the civ, and so is important in morale. As you know, none of this is yet implemented. In addition capture of the capital can serve as a victory condition for a scenario. IMO we need to keep capitals.

Maybe we should have a virtual capital location for "capital does not exist"? That might just push the errors elsewhere though.

Cya,

Mark

	21-07-2003 09:20									#102
	Support Apolyton or Terrorists Win

If a civ loses its capital it should be highly prone to revolts/anarchy/incursions from other civs due to the breakdown of the government and paper-pushers. You should be able to copy a civ's maps if you capture the capital.

Ala Civ2 meets EU2 in that respect.

	26-07-2003 18:14									#103
	Increase the size of your Attachments

I fixed the diplomatic bug which prevented fights from happening.
I didn't make all the changes I would have liked to to the diplomatic code. Mostly the problem stems from the use of a new Clss.InnerClass() pattern instead of class.InnerDataMember pattern:
When comparing two diplomatic statuses, isEqual was called but not implementing. It shouldn't even be necessary to implement it if there was a single wr object (either a singleton of Diplomatic.War class or a static data member of Diplomatic class).
I think that the code will have to be updated smeday so that diplomatic status can be written as "war" in the xml file rather than "-1".