unit progression

The weekend is young. Last night I built my first sdk, and updated JRouteNative to BTS 3.19. Today I am going to do some work on Fury Road and then I will fix the bugs related to loading and unloading in all terrain transports.

You recently put up a new sdk which has the CAR mod integrated. Does this also have the AI for the homeworld screen by koma? I would like to make sure we do not lose any features as we go forward. I will make my bug fixes on top of your CAR mod source code.
 
@ keldath (or koma), I can't compile the current sdk. I get a small number of link errors:
Spoiler :

Creating library Final_Release\CvGameCoreDLL.lib and object Final_Release\CvGameCoreDLL.exp
CvDLLPython.obj : error LNK2019: unresolved external symbol "void __cdecl CyCityPythonInterface2(class boost::python::class_ &)" (?CyCityPythonInterface2@@YAXAAV?$class_@VCyCity@@Unot_specified@detail@python@boost@@U2345@U2345@@python@boost@@@Z) referenced in function "void __cdecl DLLPublishToPython(void)" (?DLLPublishToPython@@YAXXZ)
CvInfos.obj : error LNK2019: unresolved external symbol "public: void __thiscall CvXMLLoadUtilityModTools::setLocationName(class CvString *,char const *)" (?setLocationName@CvXMLLoadUtilityModTools@@QAEXPAVCvString@@PBD@Z) referenced in function "public: virtual bool __thiscall CvInfoBase::read(class CvXMLLoadUtility *)" (?read@CvInfoBase@@UAE_NPAVCvXMLLoadUtility@@@Z)
CvInfos.obj : error LNK2019: unresolved external symbol "public: void __thiscall CvXMLLoadUtilityModTools::StringArrayExtend(class CvString * *,int *,class CvString * *,int,class CvString)const " (?StringArrayExtend@CvXMLLoadUtilityModTools@@QBEXPAPAVCvString@@PAH0HV2@@Z) referenced in function "public: void __thiscall CvCivilizationInfo::copyNonDefaults(class CvCivilizationInfo *)" (?copyNonDefaults@CvCivilizationInfo@@QAEXPAV1@@Z)
CvInfos.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CvXMLLoadUtilityModTools::isDuplicate(int,int *,int)const " (?isDuplicate@CvXMLLoadUtilityModTools@@QBE_NHPAHH@Z) referenced in function "public: void __thiscall CvHandicapInfo::copyNonDefaults(class CvHandicapInfo *)" (?copyNonDefaults@CvHandicapInfo@@QAEXPAV1@@Z)
CvXMLLoadUtilitySet.obj : error LNK2019: unresolved external symbol "public: void __thiscall CvXMLLoadUtilitySetMod::loadModControlArray(class std::vector > &,char const *,int)" (?loadModControlArray@CvXMLLoadUtilitySetMod@@QAEXAAV?$vector@VCvString@@V?$allocator@VCvString@@@std@@@std@@PBDH@Z) referenced in function "private: void __thiscall CvXMLLoadUtility::LoadDiplomacyInfo(class std::vector > &,char const *,char const *,char const *,class CvCacheObject * (__thiscall CvDLLUtilityIFaceBase::*)(char const *))" (?LoadDiplomacyInfo@CvXMLLoadUtility@@AAEXAAV?$vector@PAVCvDiplomacyInfo@@V?$allocator@PAVCvDiplomacyInfo@@@std@@@std@@PBD11P8CvDLLUtilityIFaceBase@@AEPAVCvCacheObject@@1@Z@Z)
CvXMLLoadUtilitySet.obj : error LNK2019: unresolved external symbol "public: class CvString __thiscall CvXMLLoadUtilityModTools::deleteFileName(char const *,char)" (?deleteFileName@CvXMLLoadUtilityModTools@@QAE?AVCvString@@PBDD@Z) referenced in function "private: void __thiscall CvXMLLoadUtility::LoadDiplomacyInfo(class std::vector > &,char const *,char const *,char const *,class CvCacheObject * (__thiscall CvDLLUtilityIFaceBase::*)(char const *))" (?LoadDiplomacyInfo@CvXMLLoadUtility@@AAEXAAV?$vector@PAVCvDiplomacyInfo@@V?$allocator@PAVCvDiplomacyInfo@@@std@@@std@@PBD11P8CvDLLUtilityIFaceBase@@AEPAVCvCacheObject@@1@Z@Z)
CvXMLLoadUtilitySet.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CvXMLLoadUtilityModTools::isModularArt(char const *)" (?isModularArt@CvXMLLoadUtilityModTools@@QAE_NPBD@Z) referenced in function "private: bool __thiscall CvXMLLoadUtility::LoadModLoadControlInfo(class std::vector > &,char const *,char const *)" (??$LoadModLoadControlInfo@VCvModLoadControlInfo@@@CvXMLLoadUtility@@AAE_NAAV?$vector@PAVCvModLoadControlInfo@@V?$allocator@PAVCvModLoadControlInfo@@@std@@@std@@PBD1@Z)
CvXMLLoadUtilitySet.obj : error LNK2019: unresolved external symbol "public: void __thiscall CvXMLLoadUtilitySetMod::setModLoadControlDirArray(bool)" (?setModLoadControlDirArray@CvXMLLoadUtilitySetMod@@QAEX_N@Z) referenced in function "private: void __thiscall CvXMLLoadUtility::ModularLoadingControlXML(void)" (?ModularLoadingControlXML@CvXMLLoadUtility@@AAEXXZ)
Final_Release\CvGameCoreDLL.dll : fatal error LNK1120: 8 unresolved externals


Starting with an empty directory, I copy all the 3.19 CvGameCoreDLL files, and then unpack the dunesdk-1.3.9.exe on top of it. Then I setup the project using refar's makefile and make. It goes and compiles all the files fine; but there are some unresolved references.

Is it possible that there are 1-2 updated files missing from the dunesdk-1.3.9 archive?
 
I figured it out. Your Makefile has paths to your compile tools, so I was using my Makefile with my own paths. But your Makefile also has bunch of other changes compared to the original one from refar. So I put my paths into your Makefile and it is working.
 
I can't compile the sdk, getting same error as David (link error). I am using codeblocks and vc++2003, changing the make file won't help me... any suggestions? :(
 
You have compile/linked it before, right? Can you go back to those same files and compile/link ok? The changes I made were pretty small ones, and I don't *think* keldath has made big changes. Perhaps his merge of the CAR mod threw you off. The difference between the refar makefile and the keldath makefile was adding a couple of source files such as CyCityPythonInterface2. Does that help any?
 
Thank you David! I added the missing source files manually to my project and it seems to produce now a valid CvGameCoreDLL. :goodjob:
 
Wasp (was light hornet). Strength 8. +50% vs hornet. Fighter abilities. Range 5.
Firefly (was assault hornet). Strength 10. Range 6. Bomber abilities. Does collateral damage. Requires crystals.
Locust (was medium hornet). Strength 12, +50% vs hornet, fighter, can intercept, range 7. Requires crystals.
Dragonfly (was heavy hornet). Strength 18. Bomber, does collateral damage. Range 8, Requires stradvium.
Stealth hornet. Strength 22. Bomber abilities, does colleteral damage. Range 9. 80% evades interception. Requires stradvium, requires crystals.

I want to get the upgrade paths for these sorted.

At the moment we have:

Wasp -> Locust -> Dragonfly -> Cielago (Stealth Hornet)
Firefly has no upgrade option.

Shouldn't there be a fighter path and bomber path? Like this:

Wasp -> Locust
Firefly-> Dragonfly -> Cielago

Also, I'd like to add a descriptive word to the names to indicate the purpose e.g. Wasp Interceptor, Firefly Bomber, Cielago Stealth Bomber
 
Something else that bugs me now that we have the worm rider graphic on scouts, etc.

Can we rename the Riding the Worm tech and the Worm Rider unit? Worm Rider is something that young Fremen kids can do so it is not really a good name for a Fremen warrior UU.

The current requirement for Riding the Worm is Mind Training and Sand Worms and it leads to Water of Life. How about calling the tech Fremen Ways and the unit Naib's Chosen, which is still a name I like, or something else with a bit more Fremen flavour?
 
Sounds nice imo
 
Can we rename the Riding the Worm tech and the Worm Rider unit? Worm Rider is something that young Fremen kids can do so it is not really a good name for a Fremen warrior UU.

The current requirement for Riding the Worm is Mind Training and Sand Worms and it leads to Water of Life. How about calling the tech Fremen Ways and the unit Naib's Chosen, which is still a name I like, or something else with a bit more Fremen flavour?

IIRC (and I may not), 12-year olds can ride on the worm, but not be the first to mount one.

Some renames seem reasonable.

I don't like "Fremen ways" as a tech name; everythnig the Fremen do are Fremen ways; its not like the Fremen don't have any ways until the midgame.
Maybe "Deep Desert Adaptation".

I've also suggest that mind training should be removed as a requirement for riding the worm - and maybe add it to water of life instead.

"Naib's chosen" sounds decent. And put a national limit 10 on it (like the Sardaukar legionaries and noukkers) to make them feel more elite and reduce spam.

It also feels wrong for Fremen to have a Shield Fighter (Fremen using shields?), and Crysknife fighter seems like it should be strong, not a weak raider.

How about we rename the strength 4 crysknife fighter to "Raider", or "Fremen Raider".
And then give Fremen a UU version of the Shield fighter that is identical, but call it Crysknife Fighter.

If we end up doing as I hope and removing scorpions, hornets, thopters and suspensors from Fremen, then they will need some more UUs.

I definitely think we need some variation in the worm graphics though; you can't identify *which* worm riding unit is in a stack by looking at it.
Adding some figures along the back of the worm would also make it feel more like a bunch of warriors, rather than just 1 guy.
 
I've been poking around the sub-forum and so far haven't found a forum to post this question/request.

Simply put is that I feel that scouts & thopters have it to easy. I say this only because in the books, there were many places in the desert that was just too much of a pain to get to. Now as someone who has been deployed to a very arid terrain, I can say that Dune would be hell on machines so seeing these scout thopters whizzing around Dune w/o any problem seems far-fetched and not really true to the book.

So here is my thoughts. I would think that if it's possible to code, would be that after 2 turns or so outside your cultural boundaries, units start taking damage every turn. Now that I think about it, I think perhaps it should be more of taking damage outside any cultural boundary or otherwise attacking other factions wouldn't happen. So sending your scout thopter our on a 'world tour' would mean you'd end up with a dead thopter pretty soon.

I mean I get the impression (it's implied) that when the Harkonen go after Muad'Dib's deep desert seitch, that they got the Guild to drop their troops via orbital insertion instead of actually flying all that way (which would most likely be detected). Again the books point out that there was areas of Arrakis that were unknown because the Fremen bribed the Guild to give inaccurate satellite pictures.

So by putting limits on scouts, you force players to have to do 'leap-frog' sort of scouting and many parts of the map might be "Here Be Dragons" sort of unknown which would benefit a second Fremen civ mentioned in another forum, especially going along with the idea that they would have benefits or abilities that would allow the faction to survive with less rocky ground. (As I mentioned in another forum, they might be sort of like the Pirates of SMAC:AC)

Also another quick observation is perhaps the code from FF/Orbis could be used to fiddle around with the Goblin Fort and turn it into a Smuggler's Cove where you could 'buy' units. Of course I think this would mean there would have to be a minor Smuggler's Civ you could be at peace with to work, but it would also be another spawning point for 'barbarians" as well as giving a burst of money (represented by spice from the smugglers) if you took it by force.
 
I say this only because in the books, there were many places in the desert that was just too much of a pain to get to.

Like what?

Consider the Arrakis mapscript. The places on the planet that are too much of a pain to get to are off-map; the map basically represents only the planet's arctic circle.
There aren't really any places inaccessible to thopters, but it takes time and fuel and mostly there isn't any value in going there (on earth, you *could* go out into the middle of the Sahara desert.... but why would you?).
And thopter can still only move a few tiles at a tile, so it is a pain for them to go long distances.
And there are storms that can destroy thopters if they get caught in them.
As for Fremen scouts, there isn't really anywhere the Fremen can't go; they can ride worms all the way from the north pole to the palmeries of the south pole (20 thumpers).

I would think that if it's possible to code, would be that after 2 turns or so outside your cultural boundaries, units start taking damage every turn

I think this would destroy the AI. The AI, on two separate islands, has to cross some open terrain to get to you, but their entire strike force gets damaged or destroyed on the way over because they don't understand that areas outside culture cause damage?
That sounds really bad for gameplay.

Or: you conquer an enemy city, it goes into revolt, and loses its cultural radius - so now any units in the surrounding tiles start taking damage?
I mean I get the impression (it's implied) that when the Harkonen go after Muad'Dib's deep desert seitch, that they got the Guild to drop their troops via orbital insertion instead of actually flying all that way (which would most likely be detected)
The Harkonnen don't; its the Sardaukar. And yes, its implied that its orbital insertion, but of course, if you have most of your forces in space, why wouldn't you just land right there?
That doesn't mean that you couldn't get there by flying, it just means its easier not to.
And again, all those central regions with the worst storms are not represented on the Arrakis map.
Again the books point out that there was areas of Arrakis that were unknown because the Fremen bribed the Guild to give inaccurate satellite pictures.

Well, they bribed the guild to not let anyone put satellites up. So nobody knew that they should bother trying to explore there. It doesn't mean they couldn't. And again, those regions are off-map.

So by putting limits on scouts, you force players to have to do 'leap-frog' sort of scouting

Why is this a desirable goal? Scouting isn't really that important in this game.

second Fremen civ mentioned in another forum
We removed the second Fremen civ a while back.

Also, the value of colonizing an area is primarily determined by its water resources. There is no gain in colonzing small rocks in the desert with no water, even for Fremen.
Also another quick observation is perhaps the code from FF/Orbis could be used to fiddle around with the Goblin Fort and turn it into a Smuggler's Cove where you could 'buy' units

Why? Nobody really hires smugglers as mercenaries in any of the Dune books, and we already have a cash-for-units mechanic with the Homeworld screen.
 
I would think that if it's possible to code, would be that after 2 turns or so outside your cultural boundaries, units start taking damage every turn.

That's an interesting idea. There is a related concept in HOTK, where certain terrain types -- swamp and marsh -- cause damage every turn. That is something the AI doesn't plan for, but it represents unforgiving terrain. In HOTK, it doesn't matter if the area is inside cultural borders or not. In general, maintenance isn't something that the Civ games try to model, but we can keep it on the list of possibilities.

I mean I get the impression (it's implied) that when the Harkonen go after Muad'Dib's deep desert seitch, that they got the Guild to drop their troops via orbital insertion instead of actually flying all that way (which would most likely be detected). Again the books point out that there was areas of Arrakis that were unknown because the Fremen bribed the Guild to give inaccurate satellite pictures.

We played around with a few ideas on this, which you can see in the older "spacer guild mechanics" thread. I tried a few things with satellite surveillance and orbital dropships. I couldn't get anything that seemed "fun", but we can certainly discuss more about that.
 
A possibility for dropships:
You could create an "Orbital insertion" unit from the Homeworld screen for like 250 gold, which was a transport with a large capacity (6?) that could paradrop in a 50 tile radius, and then died after dropping. So you're simulating paying the guild to (allow you to) drop a bunch of your troops somewhere from orbit.

AI wouldn't use it though.
 
Back
Top Bottom