Trade Route Screens, Tutorials, Questions, etc.

As to the no 'euro' screens for a world mod, i plan to take a different view of it (sorry off topic but sort still on topic) My plan is to make 'Trade Centres' (Think Venice, Jerusalem, Hong Kong, Ivory Coast, Native Mexico) for each continent, and then you can become a successful 'merchant' by having a 'freight service' taking resources from one trade hub to another, of course if you produce these goods yourself on the various continents, your profit margins will become even higher. Then selling to a 'local market' (an actual city) would bring you again even higher profits. So as your civ evolves and grows your options for profit and greater profit margins increase. Also if I can do it, the trade centres would change in prices and impotance as new products become available and the world advances, so you would also have to be prepared for shifting markets.

The screen to screen trading system is one of my favourite parts of M:C, so in my plans for a World mod, I fully intend to have this as I personally find it really enjoyable.

In conclusion, Kailric and Night, I like the way you are thinking. Me likes Xml tags, less need for poop, more fun with hammer!!
 
Firaxis made a fantastic design, which is likely the best possible design for modding one could come up with. What we are doing now is following the design idea Firaxis came up with. M:C didn't have the need to follow this strictly, but now with multiple mods sharing one source code the demand for following the design strategy is more important and we are "just" doing what Firaxis planned us to do in the first place.

The design criteria is to make the DLL so flexible that we could go without DLL modifications for say a year without feeling the need to change as all the wanted changes can be done in XML alone. A good DLL modder works hard to make himself unneeded :lol:
 
Nightinggale said:
The design criteria is to make the DLL so flexible that we could go without DLL modifications for say a year without feeling the need to change as all the wanted changes can be done in XML alone. A good DLL modder works hard to make himself unneeded :lol:
Click to expand...

That is the goal;)

Just another update so I can keep up with my own progress. Again, working on the Spice Route, it seems to be mostly fully functional just with XML settings. I've added "Description" and "Help" text to the EuropeInfos.xml. So, now when you mouse over the trade route Button it gives you the same info as the old command button.

Also, I've added in "PythonTradeScreen" to the xml. This allows you to choose witch Python trade screen to use when it auto opens the Trade Screen when your units arrive. The future plans are to make it so there is only one TradeScreen that needs to be modded but that is out of the scope of my current goals. As of now you will still need to add in new Python Screens if you want more screens than what the mod currently has. However, adding new screens will be somewhat a copy and paste procedure with a few python changes along with appropriate art.

Next step in the Trade Route conversion is to add in the AutoCrossOcean commands.
Edit: Note to self: I still need to fix the Load Unit function when you Summon a unit at the Spice Route Screen. You can Summon the Unit and it appears in the Screen, but it will not load on your ships. Purchasing goods seems to work just fine, however.

Edit: This gives me the Idea that we should add in XML options in EuropeInfos for "bDocks", "bSummons", etc. This way we can configure the screen to have Dock, Summon, etc options just from the XML.
 
Kailric said:
Just another update so I can keep up with my own progress. Again, working on the Spice Route, it seems to be mostly fully functional just with XML settings. I've added "Description" and "Help" text to the EuropeInfos.xml. So, now when you mouse over the trade route Button it gives you the same info as the old command button.
Click to expand...
As you haven't pushed your changes so far I can't tell how you did it, but do remember that those two are part of BasicInfo and are defined for all infos. They are also handled by BasicInfo::read() and that stuff meaning they are done even if you don't write it manually in CvInfos.cpp
Also they are already used in the code. I think Description is used in Pedia and stuff like that.

Kailric said:
This allows you to choose witch Python trade screen to use when it auto opens the Trade Screen when your units arrive.
Click to expand...
I have heard about code, which seems to be dark magic. Maybe it was all written in "witch Python" :lol:
 
Lib.Spi't said:
Other than that...Yay!
Click to expand...

Thanks for cheering me on. Go code go!

Nightinggale said:
As you haven't pushed your changes so far I can't tell how you did it, but do remember that those two are part of BasicInfo and are defined for all infos. They are also handled by BasicInfo::read() and that stuff meaning they are done even if you don't write it manually in CvInfos.cpp
Also they are already used in the code. I think Description is used in Pedia and stuff like that
Click to expand...

Yeah, I basically just now figured that out or remembered again about that. I started to add new code for the Button and then realized that I may could do that and yep, it works for Buttons too.

I plan to add code for a New Route Picture popup and also a Movie.
 
Nightinggale said:
So you basically figured out how to use basic info. That's great and a huge step forward :lol:
Click to expand...

Always with a funny punch ;)

Ok, I have worked out most of the bugs in the Spice Route... now, I have come to a predicament. I write this in order to better understand for myself...

Currently, when creating the map the code CvMapGenerator::addEurope() cycles through all the available Europes in the EuropeInfos. It gets all relevant EuropeInfo info and then loops through every plot on the map making the relevant checks. It checks for the direction of the Europe and then makes a check based on the direction of whether the WidthPercent matches the EuropeInfo criteria. If so it then checks for MinLandDistance, if so it then declares the plot a Europe.

My predicament is that for some Trade Screens there are two access points. Such as EuropeEast and EuropeWest. This adds a bit of confusion as both of these are actually the same "Europe" with the same prices and so when I do a kPlayer.getHasTradeRouteType((EuropeTypes)i) in a loop the loop will check for both EuropeTypes, thus having two positive results. This will add unwanted side effects such as the Spice Route price being listed twice.

I am sure there is more than one way to fix this, but one way I thought of is to eliminate EuropeWest all together and add a new XML tag for AlternateDirection, and then add code to apply Europe Status to this Alternate access point for one Europe(Trade Screen). I looked through the code and the only real use for the EuropeWest tag is when your Ships are docked at the Spice Route and you can send them home either West or East. Python does a check to see if the unit can sell West. This check can easily be modded and have it based on XML settings. I feel this will greatly reduce the confusion for building Trade Screens.

AI is another matter, I will continue to allow AI to access the default Europe Trade Screen only, either through the Spice Route or Silk Road. Getting them to use multiple trade screens is an expansion unto itself so for now this will suffice. They don't actually use the screens just the prices listed there anyway. I may have to add a new tag for "AI only" so that players know to leave say, EuropeEast, alone for the AI to use.
 
Kailric said:
I am sure there is more than one way to fix this, but one way I thought of is to eliminate EuropeWest all together and add a new XML tag for AlternateDirection, and then add code to apply Europe Status to this Alternate access point for one Europe(Trade Screen).
Click to expand...
Wouldn't it be better to make an array of "Directions" instead? This way it will work even if somebody decides to have 3 for the same tradescreen. It might make more sense to have a lot of them if we add more options later. We shouldn't pick a design, which prevents future additions if it can be avoided.

The array would work like say yield demand for buildings and units. Easy to set up for any modder.
 
Kailric said:
My predicament is that for some Trade Screens there are two access points.
Click to expand...

In my modmod of the fantastic M:C I didn’t also find it realistic to access the same place from both west and east and also going past Lapland to buy silk.

Therefore I edited CIVEuropeInfo.xml to lock north and south gateways and changed the EUROPE_WEST <Type> with the Silk_Road <Tradescreen>, so that I had two different areas to be reached by sea.

Both areas appeared on each side of the map, each one with their distinctive colour but I couldn’t advance any further because sea units couldn’t travel west. I couldn’t find where to remove the “Travel” button from land units and add it to sea units. I thought it was hardcoded.

I also agree that these changes will enhance the mod and I really look forward to this work you are doing: bringing more trade routes code to XML.
 
Trade Winds said:
I thought it was hardcoded.

I also agree that these changes will enhance the mod and I really look forward to this work you are doing: bringing more trade routes code to XML.
Click to expand...

Yep, mostly all hardcoded. but that is changing. Ok, another predicament, and maybe the last major hurtle (again I write this for my own notes as well to share). I have worked out (in my head at least) how to deal with one Trade Screen being accessed from different points. Now, what about different Trade Screens being accessed from the same point. Since we are not using the command system, which would make this part simple, we have to code a way to differentiate the Trade Screens from the same plot.

The problem is that each plot can only have one Trade Screen assigned to it. Again, we can bring in an Array and change the existing code to use that instead. Functions like getEurope() and isEurope() would have to be rewritten as well as their places in the code. There isn't a whole bunch of places where these are used but it would take me considerable more time to do this. So, for now, in order to get a version posted for people to test I will leave it at one plot, one Europe (Trade Screen).

However, I will be adding in all directions. As of now there are only 4; N,S,E,W, but I am planning to add in NE, SE, etc, bringing the total directions to 8. So, in essence modders will have 8 access points not including land based plots like Cities. I haven't got this part coded yet, but in theory it should work:mischief:

If anyone has any ideas on multiple Trade Screens from the same plot let me know.
 
From an XML point of view I would say that we shouldn't set up Europe to use more than one trade screen. However if Europe 1 and Europe 2 both has EAST set, then they will just happen to have the same access plots. The code to "merge access" shouldn't be defined in greater detail in XML than this.

As for direction of access, we should view the map as a numpad.
7|8|9
4|5|6
1|2|3
Say we have Europe 1 using 3, 6 and 9. Europe 2 will then use 2 and 3. With this setup 3 will then automatically have plots for both Europes.

A setup where 3, 6 and 9 is needed to set what is currently east will also give way more options to XML.

I'm not sure on how to code this in the DLL yet. However I'm quite sure we should be able to work out something and I might come up with an idea once Kailric pushes new code to github.
 
Some of the code in question is void CvMapGenerator::addEurope()

Code: 
if (kEurope.getDirectionValid(iDir))
						{
	switch ((DirectionTypes)iDir)
	{
	case DIRECTION_EAST:
		bEurope = (pPlot->getX_INLINE() > (100 - iWidthPercent) * GC.getMapINLINE().getGridWidthINLINE() / 100);
		break;
	case DIRECTION_NORTHEAST:
		bEurope = (pPlot->getX_INLINE() > (100 - iWidthPercent) * GC.getMapINLINE().getGridWidthINLINE() / 100 && pPlot->getY_INLINE() > (100 - iWidthPercent) * GC.getMapINLINE().getGridHeightINLINE() / 100);
		break;
	case DIRECTION_WEST:
	       bEurope = (pPlot->getX_INLINE() < iWidthPercent * GC.getMapINLINE().getGridWidthINLINE() / 100);
		break;
	case DIRECTION_NORTH:
	       bEurope = (pPlot->getY_INLINE() > (100 - iWidthPercent) * GC.getMapINLINE().getGridHeightINLINE() / 100);
		break;
	case DIRECTION_SOUTH:
			bEurope = (pPlot->getY_INLINE() < iWidthPercent * GC.getMapINLINE().getGridHeightINLINE() / 100);
			break;
	default:
		FAssertMsg(false, "Invalid direction");
		break;
}
}

This is the code that defines the directions. I have added NE for testing. Adding all directions like this will require us to change the code so that say DIRECTION_EAST only covers the middle east side and leaves a space open for NE and SE. Then in the XML if you want your Trade route to be the whole Eastern side you will need to add E,NE, and SE for the Directions.

I've added a default color tag in the XML so that you can define what color the route shows on the plots. There is still a bunch of work to do. :eek:
 
An idea just popped into my head. We can store a bitmap of Europe access in CvPlot. This way we have a 32 bit array, which tells which Europes can be accessed from the plot in question.

If there is no access, then the int will be 0.

Check for a specific
Code: 
bool check (EuropeInto eEurope) const
{
[indent] return (iEuropeBitmap >> eEurope) & 1;[/indent]
}

Set a specific
Code: 
void set(EuropeInto eEurope, bool bPresent)
{
[indent]if (bPresent)
{
iEuropeBitmap |= (1 << eEurope);
} else {
iEuropeBitmap &= ~(1 << eEurope);
}
[/indent]
}

Savegames will then save a single int like saving any other var. No need to make a fuss about writing code to handle an actual array. The sideeffect is that there will be a hard limit of 32 Europes. I think that should be enough. If not, then we can use a 64 bit int instead at a minor performance loss.
 
Another bug. Not really sure to post it here, as it was the plotgropus commit.

This is when my peddler at the silk market tries to sell 300 grapes:

Assert Failed

File: CvGameTextMgr.cpp
Line: 9221
Expression: eYield == NO_YIELD || kPlayer.getSellToEuropeProfit(eYield, iAmount * (100 - iCommission) / 100) == iGross
Message:
 
Nightinggale said:
An idea just popped into my head. We can store a bitmap of Europe access in CvPlot. This way we have a 32 bit array, which tells which Europes can be accessed from the plot in question.
Click to expand...

Ok, I'll save that till later. You may have to do that part as bit arrays are still new to me.

Trade Winds said:
Another bug. Not really sure to post it here, as it was the plotgropus commit.

This is when my peddler at the silk market tries to sell 300 grapes:

Assert Failed

File: CvGameTextMgr.cpp
Line: 9221
Expression: eYield == NO_YIELD || kPlayer.getSellToEuropeProfit(eYield, iAmount * (100 - iCommission) / 100) == iGross
Message:
Click to expand...

This assert has already been posted at the bug thread, you can find the bug thread here, it will tell you which ones have already been found http://forums.civfanatics.com/showthread.php?t=505306.
 
You must log in or register to reply here.

Similar threads

Chrisy15
Trade Route Bug - Disappearing Trade Units and Self-Generating Trade Routes
Replies
0
Views
97
Chrisy15
Chrisy15
A
  • Poll
[Vote] (7-44) Remove Notification When a Trade Route from Another Player is Plundered
Replies
9
Views
428
azum4roll
A
Slyceth
Trade route overhaul proposal brainstorming
Replies
5
Views
735
Boombar
B
Alekseyev_
Change player data in multiplayer save?
Replies
2
Views
206
Alekseyev_
Alekseyev_
Legen
  • Locked
[Complex] (7-NS) Alternative Carthage adjustments
2
Replies
39
Views
1K
Legen
Legen
Top Bottom