Dune Wars Mod

hey guys,
im half drunk.....

so i read some of what you wrote,

there are good ideas for spice economy, ill refer to your discussion later ,

but for now,

ive released version 1.1,

it has tons of changes from version 1.0.

i added acorporation system, that each civ has a unique corporation that can be founded on gamestart,
these corps consume only spice and ment to be the main part of conomy - the more spice res you have the more income youll get, its probably for now low and inbalanced,
with your reports,
we can make somthing out of it.
thanks to johny smith for the idea.

by the way,
the best way to have a good soice system - is to have a quantitive resource code,
we can do much if we have that,
if anyone one you guys can get us an sdk coder, me and you guys have great ideas,
that can make this mod very unique in civ4.

gnite y'all,
sorry for the spelling errors....i drunk one too many beers...


p.s

delivirator -
awesome model! can wait to see it live.
 
I have tried out version 1.1, and it is working great. I will try some autoplays overnight and tomorrow.

I have added the spice blow event and the three levels of spice that I mentioned are produced. The fallout feature and "scrub fallout" are returned to normal now that I know how to add a feature to RevDCM.

I have added the foot unit for spice collection (thanks to mechaerik). It's just a worker now, but I can add the collection promos and AI code onto it later. Will this be the first unit art which is unique to Dune Wars? I think all the other unit art is from pre-existing future unit packs. Admittedly, it is just merging an existing flavor unit with a different existing anim, but we must start somewhere.

No post would be complete without some ...

New issues

79. The action to build a grove still says "Build a Foundry"

87. Weather Scanner building still gives +1 food in desert. It should give +1 gold. Same with Fedaykin monument.

93. Deep desert gives one food. It should not give anything.

94. Now that the windtrap feature is integrated, the Wind Trapping tech and its wonder, Windtrap, should be renamed or something.

95. Offworld Trading should allow trade routes on Desert Waste. It is possible for somebody to get this tech without getting hovering, which would lead to trade routes on deep desert but not desert waste. That will not be very helpful.

96. Minor nations start with hovering tech. This is the last leftover from when hovering was a tier 1 tech.

97. A few techs are spelled incorrectly, which I missed before: Wierdling => Weirding; Refining Technics => Techniques; kindjal, breeding program and Tachyon Net need capital letters.
 
I have made a lot of progress on the spice blow and collector. I have a first version which I will do some autoplays upon, and release hopefully this afternoon. It will be "patch 1.1.1".

* Spice blow working, three spice resources: dense spice (blue), spice (green), and trace spice (yellow). They will deteriorate randomly and get replaced by new blows. Cities can work spice for a lot of gold. We can keep this, even if we don't keep the collector mechanic. The first screenshot below shows the spice blow, some nearby spice, and a collector. The collector is shown collecting, even though he is not on a spice plot; this is a prototype shot.

* Spice collector working, but not automated, and the AI will not build it. (Sigh, I forgot about that in my original plan.) If you move the collector unit to a spice plot, its collection bag will fill up automatically, and when you move it to a city, it will sell automatically. No action buttons and no automation for the search and return part yet. The entire mechanic may not be interesting or may cause too many RTS flashbacks.

* Mechaerik was kind enough to relink some units for me. It bothers me that primitive Dune starts out with mechanical units. There was an Egyptian Rifleman unit which looks sort of like a Fremen, so I have replaced the settler, worker and scout with Fremen he created. The second screenshot below shows the new settler. The scout and collector look similar. Identical actually, but we can reskin them later.
 
david,

wow - really cool work - i like everything about it, the spice blow and the new spice res.

its so awesome.

so now - spice wont be replaced upon map generation? only via spice blows? is there a systematic to the place that spice blow will appear - meaning - will it appear mostly near cities? or random places on the map then?
i love the deteriorate idea!
cant wait to see this in action.

the models looks cool ,
but, i m not sure how to implement this - its most important that the ai will use this action - to automate those units to bring gold to the cities backand forth from spice res - and also it should know which of the new spice res is better - if it has blue spive and trace spice how will it know which to harvest first?
maybe some sdk is needed here?
but still having an rts system can be an awesome new breeze to civ 4.

we should make it that most of the game economy will rely on working the new spices,
meaning lowering the trade routes from buildings, reduce bonuses from buildings, and increase unit support cost.

also,
i think we can a make that money will have greater impact on the game rather then buying stuff and from just get accumilted for harsh times -
i was thinking to adda gold cost to some units - so some key units will also cost gold in addition to hammers - i have the code already in dune core, i used it to create a mecenary system on overlord, the ai knows how to use them - and not to buy these units with all his money.
thus by this economy will have greater impact, and this means - more emphasis on obtaning spice,

what do you think about this?


ive looked at the fuel mod by grey fox, maybe i will be able to use it to do something with the spice, i dunno yet - some form of compiling spice.

but anyway,
good wrk david, im anxious to see your new developments.

also hope you can give some feedback on the new unique corporations system.
 
Shai-Hulud is starting to shape up nicely and I haven't done any texture work yet. I've attached the files for the current version shown below so that you can have a play. I've included a readme with the necessary XML entries. I created some correct colour sand/dust effects based on koma's textures because they are pretty much vital. Haven't quite got the dust triggering in the right place and time yet. Most of the animations are pretty much placeholder for now - the fortify one has had the most work as that is when the worm breaks through the sand. Just use WB to give yourself a few worms and keep hitting F to see the action! There's still a long way for this unit to go - it's the sort of thing you can keep on refining - but for now I'm happy that I've managed to animate the thing from scratch. :)

attachment.php


attachment.php
 

Attachments

  • worm_anim1.jpg
    worm_anim1.jpg
    64.1 KB · Views: 303
  • worm_anim2.jpg
    worm_anim2.jpg
    45 KB · Views: 300
so now - spice wont be replaced upon map generation? only via spice blows? is there a systematic to the place that spice blow will appear - meaning - will it appear mostly near cities? or random places on the map then?

For the spice bonuses, I set all the mapscript generation random numbers to zero. (You probably know this does not require changing the mapscript.) So it will only appear due to blows. Currently, it just picks random ocean squares. If players think the idea works but the placement is "unfair", we can put more thought into that.

i m not sure how to implement this - its most important that the ai will use this action - to automate those units to bring gold to the cities backand forth from spice res - and also it should know which of the new spice res is better - if it has blue spive and trace spice how will it know which to harvest first?

I did not explain, but my concept is that the three spices are just different "density" of the same stuff. After a few turns, "dense" deteriorates to "spice", "spice" deteriorates to "trace spice", and "trace spice" vanishes. I did not change the techs and buildings to correspond to this, but basically all three should be treated the same.

also hope you can give some feedback on the new unique corporations system.

I did not use corps much in the Fury Road mod or when I play vanilla. I can see the AI founds them; I played far enough into one game to found one myself. I looked at the economy after a 400 turn autoplay and the AI's were not getting too much money out of them. I will experiment more, today and tomorrow. I am running a few games of vanilla RevDCM on archipelago to see how the economies compare; but I am not really an expert at tuning this kind of stuff and I don't really know what I am looking at.

deliverator said:
Shai-Hulud is starting to shape up nicely and I haven't done any texture work yet. I'm going to upload what I've done soon for you to have a play.

Want!
 
I have made a lot of progress on the spice blow and collector. I have a first version which I will do some autoplays upon, and release hopefully this afternoon. It will be "patch 1.1.1".

* Spice blow working, three spice resources: dense spice (blue), spice (green), and trace spice (yellow). They will deteriorate randomly and get replaced by new blows. Cities can work spice for a lot of gold. We can keep this, even if we don't keep the collector mechanic. The first screenshot below shows the spice blow, some nearby spice, and a collector. The collector is shown collecting, even though he is not on a spice plot; this is a prototype shot.

* Spice collector working, but not automated, and the AI will not build it. (Sigh, I forgot about that in my original plan.) If you move the collector unit to a spice plot, its collection bag will fill up automatically, and when you move it to a city, it will sell automatically. No action buttons and no automation for the search and return part yet. The entire mechanic may not be interesting or may cause too many RTS flashbacks.

This sounds cool. This RTS style resource collection is definitely an interesting area to explore in a Civ mod.

I'm having the usual problem where I spend all my time creating graphics so I don't really get to play beyond making sure my units aren't broken.

I've attached the worm files to the previous post... :)
 
wow!!!!!!!!!!!


what an amazing art work! though its not complete - its still amazing!


david,
yes, your right, just set them to zero.

now its clearer with the spice, very cleaver. each will have different money value right?

the corps do not generate much money still, i wanted to get dome feed before raising them up more.


delivirator,
indeed,
with everyones help in here, with the proper tools we can create here a big big mod with unique stuff.
thank you guys for making this mod with me.
 
I'm having the usual problem where I spend all my time creating graphics so I don't really get to play beyond making sure my units aren't broken.

I've attached the worm files to the previous post... :)

I ran it. It will be amazing when it's done! The wormsign is pretty subtle when it is moving; a small dark spot. The most visible thing is the unit flag. Still, that seems ok. The part of the attack which breaks the surface must go by pretty fast; what I see is a worm which has already come up and it smacks back and forth a few times. I guess the attack animation goes several times, once for each attack, until one side wins.

In other news, I have found that my patch 1.1.1 somehow causes CTD's very frequently. This is highly disappointing, since it is only units, plus about 600 lines of python. Every game crashes around turn 150-180, except duel size games. When I undo my changed files, I can autoplay a number of games with no crashes, so it must be in my changes. Anyway, I won't release the patch until I figure that out.
 
I ran it. It will be amazing when it's done! The wormsign is pretty subtle when it is moving; a small dark spot. The most visible thing is the unit flag. Still, that seems ok.

The small dark spot that shows when the worm is idle is actually the unit shadow - I'm not sure how to hide that. I'm definitely going to do something better for the wormsign states (the Idle, Fidget and Run anims) - perhaps just with dust and effects, but maybe I could have another mesh for the surface of the sand so that I can have a moving lump of sand. I looked at the sandstorm and something along those lines might work for the wormsign state. I might see if I can get the two things in the one NIF. More challenges!

The part of the attack which breaks the surface must go by pretty fast; what I see is a worm which has already come up and it smacks back and forth a few times. I guess the attack animation goes several times, once for each attack, until one side wins.

The downside of the breakthrough happening on Fortify is that Fortify is fixed to happen in 0.5 seconds. I would have like that to be slower, but it is a limitation of the game unfortunately. The Fortify Idle animation is the wiggle after it surfaces. Place your own worms in World Builder and fortify them to see the whole thing. The attack animation is not fully working yet, but yes it is tit-for-tat, Strike animations and Hurt animations until one side wins.

If you look at this chart for the minimum required animations you should understand why I chose to put the breakthrough on Fortify. If it doesn't happen there then the worm would be up and down like a yoyo! (The number in the bottom right of each box is the number of frames you get to play with for each animation - fps is fixed at 30.)
 

Attachments

  • animation_structure.jpg
    animation_structure.jpg
    66.5 KB · Views: 154
- imported the drop ship from Planetfall and made changes in sdk suggested by jdog5000 and maniac (thanks!).

There are a couple extra changes you should do.

CvGameCoreUtils.cpp pathdestvalid

Code:
		if (pSelectionGroup->getDomainType() == DOMAIN_LAND)
		{
			int iGroupAreaID = pSelectionGroup->getArea();
			if (pToPlot->getArea() != iGroupAreaID)
			{
				if (!(pToPlot->isAdjacentToArea(iGroupAreaID)))
				{
					return FALSE;
				}
			}
		}

change the first line to:

Code:
if (pSelectionGroup->getDomainType() == DOMAIN_LAND && !pSelectionGroup->canMoveAllTerrain())

There is no canMoveAllTerrain() CvSelectionGroup function in unmodded Civ. You can copy it from Planetfall. Do a Windows Grep search on the Planetfall SDK files, and you'll find the necessary code right away.

In pathValid, do this modification:

Code:
	if (pSelectionGroup->getDomainType() == DOMAIN_SEA && !pSelectionGroup->canMoveAllTerrain())
	{
		if (pFromPlot->isWater() && pToPlot->isWater())
		{
			if (!(GC.getMapINLINE().plotINLINE(parent->m_iX, node->m_iY)->isWater()) && !(GC.getMapINLINE().plotINLINE(node->m_iX, parent->m_iY)->isWater()))
			{
				return FALSE;
			}
		}
	}

Also I changed this city AI code

Spoiler :
Code:
		if (NULL != pWaterArea && (bAssault))
		{
			UnitTypes eBestAssaultUnit = NO_UNIT;
			kPlayer.AI_bestCityUnitAIValue(UNITAI_ASSAULT_SEA, this, &eBestAssaultUnit);
			if (eBestAssaultUnit != NO_UNIT)
			{
				iBestSeaAssaultCapacity = GC.getUnitInfo(eBestAssaultUnit).getCargoSpace();
			}

			int iUnitsToTransport = kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ATTACK_CITY);
			iUnitsToTransport += kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ATTACK);
			iUnitsToTransport += kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_COUNTER);

			int iTransports = kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ASSAULT_SEA);
			iTransports += kPlayer.AI_totalAreaUnitAIs(pWaterArea, UNITAI_ASSAULT_SEA);

			int iEscorts = kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ESCORT_SEA);
			iEscorts += kPlayer.AI_totalAreaUnitAIs(pWaterArea, UNITAI_ESCORT_SEA);

			//The way of calculating numbers is a bit fuzzy since the ships
			//can make return trips. When massing for a war it'll train enough
			//ships to move it's entire army. Once the war is underway it'll stop
			//training so many ships on the assumption that those out at sea
			//will return...

			if ((iEscorts < ((1 + 2 * iTransports) / 3)) && (GC.getGame().getSorenRandNum(2, "AI train escort sea") == 0))
			{
				if (AI_chooseUnit(UNITAI_ESCORT_SEA))
				{
					AI_chooseBuilding(BUILDINGFOCUS_DOMAINSEA);
					return;
				}
			}

			UnitTypes eBestAttackSeaUnit = NO_UNIT;
			kPlayer.AI_bestCityUnitAIValue(UNITAI_ATTACK_SEA, this, &eBestAttackSeaUnit);
			if (eBestAttackSeaUnit != NO_UNIT)
			{
				if (GC.getUnitInfo(eBestAttackSeaUnit).getBombardRate() > 0)
				{
					int iAttackSea = kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ATTACK_SEA);
					iAttackSea += kPlayer.AI_totalAreaUnitAIs(pWaterArea, UNITAI_ATTACK_SEA);

					if ((iAttackSea < ((1 + 2 * iTransports) / 2)) && (GC.getGame().getSorenRandNum(2, "AI train attack sea") == 0))
					{
						if (AI_chooseUnit(UNITAI_ATTACK_SEA))
						{
							AI_chooseBuilding(BUILDINGFOCUS_DOMAINSEA);
							return;
						}
					}
				}
			}

			if (iUnitsToTransport > (iTransports * iBestSeaAssaultCapacity))
			{
				if (AI_chooseUnit(UNITAI_ASSAULT_SEA))
				{
					AI_chooseBuilding(BUILDINGFOCUS_DOMAINSEA);
					return;
				}
			}

			int iCarriers = kPlayer.AI_totalUnitAIs(UNITAI_CARRIER_SEA);

			if (iCarriers > 0)
			{
				UnitTypes eBestCarrierUnit = NO_UNIT;
				kPlayer.AI_bestCityUnitAIValue(UNITAI_CARRIER_SEA, this, &eBestCarrierUnit);
				if (eBestCarrierUnit != NO_UNIT)
				{
					FAssert(GC.getUnitInfo(eBestCarrierUnit).getDomainCargo() == DOMAIN_AIR);

					int iCarrierAirNeeded = iCarriers * GC.getUnitInfo(eBestCarrierUnit).getCargoSpace();

					if (kPlayer.AI_totalUnitAIs(UNITAI_CARRIER_AIR) < iCarrierAirNeeded)
					{
						if (AI_chooseUnit(UNITAI_CARRIER_AIR))
						{
							return;
						}
					}
				}
			}

			if (iCarriers < (kPlayer.AI_totalUnitAIs(UNITAI_ASSAULT_SEA) / 4))
			{
				if (AI_chooseUnit(UNITAI_CARRIER_SEA))
				{
					return;
				}
			}

			int iMissileCarriers = kPlayer.AI_totalUnitAIs(UNITAI_MISSILE_CARRIER_SEA);

			if (iMissileCarriers > 0)
			{
				UnitTypes eBestMissileCarrierUnit = NO_UNIT;
				kPlayer.AI_bestCityUnitAIValue(UNITAI_MISSILE_CARRIER_SEA, this, &eBestMissileCarrierUnit);
				if (eBestMissileCarrierUnit != NO_UNIT)
				{
					FAssert(GC.getUnitInfo(eBestMissileCarrierUnit).getDomainCargo() == DOMAIN_AIR);

					int iMissileCarrierAirNeeded = iMissileCarriers * GC.getUnitInfo(eBestMissileCarrierUnit).getCargoSpace();

					if ((kPlayer.AI_totalUnitAIs(UNITAI_MISSILE_AIR) < iMissileCarrierAirNeeded) ||
						(bPrimaryArea && (kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_MISSILE_CARRIER_SEA) * GC.getUnitInfo(eBestMissileCarrierUnit).getCargoSpace() < kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_MISSILE_AIR))))
					{
						if (AI_chooseUnit(UNITAI_MISSILE_AIR))
						{
							return;
						}
					}
				}
			}
		}[/spoiler]
to this:
Spoiler :
Code:
		if (bAssault)
		{
			int iUnitsToTransport = 0;
			int iTransports = 0;
			UnitTypes eBestAssaultUnit = NO_UNIT;
			kPlayer.AI_bestCityUnitAIValue(UNITAI_ASSAULT_SEA, this, &eBestAssaultUnit);
			if (eBestAssaultUnit != NO_UNIT)
			{
				iBestSeaAssaultCapacity = GC.getUnitInfo(eBestAssaultUnit).getCargoSpace();
			}

			if (NULL != pWaterArea || eBestAssaultUnit != NO_UNIT)
			{
			iUnitsToTransport = kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ATTACK_CITY);
			iUnitsToTransport += kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ATTACK);
			iUnitsToTransport += kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_COUNTER);
			}

			if (NULL != pWaterArea)
			{
				iTransports = kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ASSAULT_SEA);
				iTransports += kPlayer.AI_totalAreaUnitAIs(pWaterArea, UNITAI_ASSAULT_SEA);
			}
			else if (eBestAssaultUnit != NO_UNIT)
			{
				iTransports = kPlayer.AI_totalUnitAIs(UNITAI_ASSAULT_SEA);
			}

			if (NULL != pWaterArea)
			{
			int iEscorts = kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ESCORT_SEA);
			iEscorts += kPlayer.AI_totalAreaUnitAIs(pWaterArea, UNITAI_ESCORT_SEA);

			//The way of calculating numbers is a bit fuzzy since the ships
			//can make return trips. When massing for a war it'll train enough
			//ships to move it's entire army. Once the war is underway it'll stop
			//training so many ships on the assumption that those out at sea
			//will return...

			if ((iEscorts < ((1 + 2 * iTransports) / 3)) && (GC.getGame().getSorenRandNum(2, "AI train escort sea") == 0))
			{
				if (AI_chooseUnit(UNITAI_ESCORT_SEA))
				{
					AI_chooseBuilding(BUILDINGFOCUS_DOMAINSEA);
					return;
				}
			}

			UnitTypes eBestAttackSeaUnit = NO_UNIT;
			kPlayer.AI_bestCityUnitAIValue(UNITAI_ATTACK_SEA, this, &eBestAttackSeaUnit);
			if (eBestAttackSeaUnit != NO_UNIT)
			{
				if (GC.getUnitInfo(eBestAttackSeaUnit).getBombardRate() > 0)
				{
					int iAttackSea = kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_ATTACK_SEA);
					iAttackSea += kPlayer.AI_totalAreaUnitAIs(pWaterArea, UNITAI_ATTACK_SEA);

					if ((iAttackSea < ((1 + 2 * iTransports) / 2)) && (GC.getGame().getSorenRandNum(2, "AI train attack sea") == 0))
					{
						if (AI_chooseUnit(UNITAI_ATTACK_SEA))
						{
							AI_chooseBuilding(BUILDINGFOCUS_DOMAINSEA);
							return;
						}
					}
				}
			}
			}

			if (eBestAssaultUnit != NO_UNIT)
			{
			if (iUnitsToTransport > (iTransports * iBestSeaAssaultCapacity))
			{
				if (AI_chooseUnit(UNITAI_ASSAULT_SEA))
				{
					if (NULL != pWaterArea)
					{
					AI_chooseBuilding(BUILDINGFOCUS_DOMAINSEA);
					return;
					}
					/*if (GC.getUnitInfo(eBestAssaultUnit).is can move all terrain()) YYY
					{
						AI_chooseBuilding(aerospace complex);
						return;
					}*/
				}
			}
			}

			if (NULL != pWaterArea)
			{
			int iCarriers = kPlayer.AI_totalUnitAIs(UNITAI_CARRIER_SEA);

			if (iCarriers > 0)
			{
				UnitTypes eBestCarrierUnit = NO_UNIT;
				kPlayer.AI_bestCityUnitAIValue(UNITAI_CARRIER_SEA, this, &eBestCarrierUnit);
				if (eBestCarrierUnit != NO_UNIT)
				{
					FAssert(GC.getUnitInfo(eBestCarrierUnit).getDomainCargo() == DOMAIN_AIR);

					int iCarrierAirNeeded = iCarriers * GC.getUnitInfo(eBestCarrierUnit).getCargoSpace();

					if (kPlayer.AI_totalUnitAIs(UNITAI_CARRIER_AIR) < iCarrierAirNeeded)
					{
						if (AI_chooseUnit(UNITAI_CARRIER_AIR))
						{
							return;
						}
					}
				}
			}

			if (iCarriers < (kPlayer.AI_totalUnitAIs(UNITAI_ASSAULT_SEA) / 4))
			{
				if (AI_chooseUnit(UNITAI_CARRIER_SEA))
				{
					return;
				}
			}

			int iMissileCarriers = kPlayer.AI_totalUnitAIs(UNITAI_MISSILE_CARRIER_SEA);

			if (iMissileCarriers > 0)
			{
				UnitTypes eBestMissileCarrierUnit = NO_UNIT;
				kPlayer.AI_bestCityUnitAIValue(UNITAI_MISSILE_CARRIER_SEA, this, &eBestMissileCarrierUnit);
				if (eBestMissileCarrierUnit != NO_UNIT)
				{
					FAssert(GC.getUnitInfo(eBestMissileCarrierUnit).getDomainCargo() == DOMAIN_AIR);

					int iMissileCarrierAirNeeded = iMissileCarriers * GC.getUnitInfo(eBestMissileCarrierUnit).getCargoSpace();

					if ((kPlayer.AI_totalUnitAIs(UNITAI_MISSILE_AIR) < iMissileCarrierAirNeeded) ||
						(bPrimaryArea && (kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_MISSILE_CARRIER_SEA) * GC.getUnitInfo(eBestMissileCarrierUnit).getCargoSpace() < kPlayer.AI_totalAreaUnitAIs(pArea, UNITAI_MISSILE_AIR))))
					{
						if (AI_chooseUnit(UNITAI_MISSILE_AIR))
						{
							return;
						}
					}
				}
			}
			}
		}[/spoiler]
 
(EDIT: this patch is now obsolete, see patch 1.1.2 at this post.)

Well, here is unofficial patch 1.1.1. This was one of the most painful debugging sessions I have ever had, and I never did find why the problem is happening. Eventually I narrowed it down to *using* the new windtrap feature I had added. If I do everything else except use that, no crashes. As soon as I use it, the game will crash later on. No idea why. I will blame it on some coding of RevDCM which seems very dependent on the contents of featuresinfo.

As a result this patch is still using fallout as the fresh water trigger.

Main features of this patch:

* Spice blows produce spice. Spice blows randomly appear in the deep desert. After a few turns the blow disappears, and spreads spice into the nine adjacent squares. There are three densities of spice resources: dense spice (blue), spice (green), and trace spice (yellow). Dense will randomly deteriorate to spice, spice deteriorates to trace, and trace disappears. Cities can work spice for a lot of gold.

* Spice collector unit. The spice collector has move 2 and can move into coast, so the AI builds it but only uses it as a scout. Each turn the collector stands on a plot with a spice resource, its collection bag will fill up automatically, and when you move it to a city, it will sell automatically. A full load brings 40 gold. There are no action buttons, and no automation yet for the search and return part. The entire mechanic may not be interesting or may cause too many RTS flashbacks.

* Mechaerik was kind enough to relink some units for me. It bothers me that primitive Dune starts out with mechanical units. There was an Egyptian Rifleman unit which looks sort of like a Fremen, so I have replaced the settler, worker and scout with Fremen he created. We can make them look different with skins, later.

Minor changes:

* A few of the other features such as spice tubers accidentally created fresh water. Removed.

* Perhaps I am showing my age, but I watched Space: 1999 when it was originally aired. I fixed the "light carryall" (Eagle) unit to have a black cockpit instead of cyan.

* Several of the hover and transport units did not have bCanMoveAllTerrain set.

You can download it from this link.
 
I haven't really been following the mod much (I don't like some of the directions it is going), but please no green/blue/yellow spice. Frank Herbert doesn't decribe how alot of stuff looks, but he always described spice as a cinimmon/dark orange/brown in spice form and rust colored in the gas form.
The worm looks really cool.
 
Maniac,
thank you! i hope koma can do this, cause im not sure i can.

davidlallen,
thanks man,
but why do you have a ctd with the windtrap? in version 1.1 that uses the windtrap...
maybe its one of the features you added in patch 1.1 -something with the fallout scrub?..?

im certain the ctd isnt revdcm related, i play tested countless turns with my core code and mods i added to revdcm and maybe had 1-3 ctds that was passable after reload.

maybe its something with the scrub, i really think its linked.
ill check it.


Ajidica,

what dont you like buddy?

you cant have a civ4 mod as a 100% dune loyal...we gotta improvise where we can tp give the mod some meat into it.

i like the looks of the blue spice, but - with that one i tend to agree - orange spice yellow orange and redish spice should be better.
 
I haven't really been following the mod much (I don't like some of the directions it is going), but please no green/blue/yellow spice. Frank Herbert doesn't decribe how alot of stuff looks, but he always described spice as a cinimmon/dark orange/brown in spice form and rust colored in the gas form.
The worm looks really cool.

Changing the color took just a few seconds. If we make everything brownish, nothing will be visible on the map. Perhaps we can have a compromise. I tend to view all the unit art which is in the mod so far, just as placeholders.

I don't think the mod is taking any particular "direction", at least not on purpose. Please tell us what you think does not fit, and we will change it. We'd love to get more text entered for the civilopedia, too, if you are interested.
 
but why do you have a ctd with the windtrap?

Yes, that is exactly the question I struggled for 12+ hours yesterday to answer, and failed. All I can say for sure is that if I add any kind of feature into xml\terrain\civ4featureinfos.xml, and then use it in the game I get weird behavior. The behavior can be having the feature vanish, or making the game crash. This does not happen in vanilla civ but happens in any variant of RevDCM. I have posted on the RevDCM bug thread several times. Jdog5000 gave a partial solution but it does not fix everything.

For an easy example, just clone one of the features from the featureinfos file and put it at the end, say, "Forest Clone". Then go into WB and place it, and click "next turn". It vanishes. This is one of the strange behaviors. You can see this in a plain RevDCM game, you don't even need dune.
 
I haven't really been following the mod much (I don't like some of the directions it is going), but please no green/blue/yellow spice. Frank Herbert doesn't decribe how alot of stuff looks, but he always described spice as a cinimmon/dark orange/brown in spice form and rust colored in the gas form.
The worm looks really cool.

I was going to suggest the same thing about spice colour. I'm happy to change it once I get this worm into a releasable state. I think between having different shades of orange/brown and varying the density (trace - a few spots, dense spice - much denser!) we can make it obvious enough without breaking the Dune desert vibe.
 
I think having a deeper color the more rich spice patch is would work. Although everything is brown, it is a desert.
As to the direction the mod is taking, for me it just feels like its going more down the game route than the books route, but you're right, you can't have it based entirely on the game.
 
Back
Top Bottom