Fixed Correcting "Early Explorers" Period

[Grey Roger]

This is the syntax for that preprocessor function:

Preprocessor_Add(string label, string text)

You can use whatever label (referred to as, for example, "#senemy#" in a dialog file) and whatever text (for example "GetNationDescByType(iNation)") in a code file.
For a character's firstname, try GetMyName(CharacterFromID("Francois Moulin"))
There is also GetMyLastName, GetMyFirstNames (with "nickname"), GetMySimpleName, GetMyFullName (with rank, e.g. "Lieutenant"), GetMyRespectfullyName (with title, e.g. "Sir").
I hope that helps.

I tried that, specifically this:

Preprocessor_Add("AntoineChamfort", GetMySimpleName(CharacterFromID("Antoine Chamfort")));

"Francis Moulin_dialog.h" now contains references to "#sAntoineChamfort#". And he still shows up as "Antoine Chamfort", he's not being given a Spanish name. It's not the pre-processor's fault because I put a test line into "Francis_moulin_dialog.c":

logit("Chamfort's name : " + GetMySimpleName(CharacterFromID("Antoine Chamfort")));

and that still shows "Antoine Chamfort", not a replacement Spanish name.

 

[Pieter Boelen]

That's pretty strange. Can you upload the file you think should be correct?
I won't be near my game files until Sunday evening, but I'll check this as soon as I can.

 

[Grey Roger]

Here's the questbook file:

 

[Pieter Boelen]

Here's the questbook file:

Can you also post the dialog.c and dialog.h files where his name should show up properly but doesn't?
And a savegame at that point would help too.

 

[Grey Roger]

And here are the other files. I've added pre-processor lines outside the main 'switch' block in both "quests_side.c" and "Francois Moulin_dialog.c" so that they should be called whenever those files are accessed. The 'logit' line is not in this version of "Francois Moulin_dialog.c" - as I recall, I had it in case "begin_3", which is where Francois mentions Chamfort by name.

I've removed specific references to "French" so that you're after an officer, not a French officer. That ought to work regardless of who owns the place!

If I can't get this working based on current nationality of Port au Prince, another way is simply to do what I did for the sword, have a few extra lines in "Francois Moulin_dialog.h" and "Moulin.txt" referring to some Spanish name, then have "quests_side.c" and "Francois Moulin_dialog.c" pick the right lines based on a check if current period is "Early Explorers". But I'd prefer to do it properly based on current nationality so that it also works if, for example, Port au Prince is British because I've got the Sovereign of the Seas moored in port. (I wonder what this code will do if the current nationality of Port au Prince is Personal...)

 

[Pieter Boelen]

And here are the other files. I've added pre-processor lines outside the main 'switch' block in both "quests_side.c" and "Francois Moulin_dialog.c" so that they should be called whenever those files are accessed. The 'logit' line is not in this version of "Francois Moulin_dialog.c" - as I recall, I had it in case "begin_3", which is where Francois mentions Chamfort by name.

I'm not sure having the pre-processor line far away from its use is going to work. So far I have had the impression that it doesn't.
But I'll test that early next week.

I've removed specific references to "French" so that you're after an officer, not a French officer. That ought to work regardless of who owns the place!

Always the simplest solution! If there are no specifics used, it also can't be wrong. Same reason why the game's loading screens no longer show town names.

If I can't get this working based on current nationality of Port au Prince, another way is simply to do what I did for the sword, have a few extra lines in "Francois Moulin_dialog.h" and "Moulin.txt" referring to some Spanish name, then have "quests_side.c" and "Francois Moulin_dialog.c" pick the right lines based on a check if current period is "Early Explorers". But I'd prefer to do it properly based on current nationality so that it also works if, for example, Port au Prince is British because I've got the Sovereign of the Seas moored in port. (I wonder what this code will do if the current nationality of Port au Prince is Personal...)

The characters are initialized at the start of the game. So if the town turns personal during the game, the character would still remain as-is with his original name and model from game start.

There are personal nation soldiers, though, so it isn't impossible. And I think personal nation names are just random, but do work.

 

[Grey Roger]

The characters are initialized at the start of the game. So if the town turns personal during the game, the character would still remain as-is with his original name and model from game start.

Oh well, in that case things become a lot simpler! It also probably explains why this line appears to have no effect:

ch.model = GetRandomModelForTypeExSubCheck(true, "Soldiers", "man", GetTownNation("Port au Prince"));  // PB

Antoine Chamfort still always appears in French uniform. I'm guessing that "SideQuest.c" is run even before the code which translates the town to its current nationality as defined by "Periods.c", so Antoine Chamfort is still Antoine Chamfort and he's still in French uniform because Port au Prince is French until told otherwise. It also means that there's no point trying to be clever and account for changes of nationality of the town later. So, after a bit of re-arranging to put everything conditional upon period (and therefore nationality) into one block, what I now have in "SideQuest.c" is this:

   if (GetCurrentPeriod() == PERIOD_EARLY_EXPLORERS)
     {
     ch.name = TranslateString("","Antonio");
     ch.lastname = TranslateString("","Chamot");
     GiveItem2Character(ch, "blade47");
     ch.equip.blade = "blade47";
     ch.nation = SPAIN;
     ch.model  = GetRandomModelForTypeExSubCheck(true, "Land_Officers", "man", SPAIN);
     }
   else
     {
     ch.name = TranslateString("","Antoine");
     ch.lastname = TranslateString("","Chamfort");
     GiveItem2Character(ch, "bladeC6");
     ch.equip.blade = "bladeC6";
     ch.nation = FRANCE;
     ch.model  = GetRandomModelForTypeExSubCheck(true, "Land_Officers", "man", FRANCE);
     }

So in "Early Explorers" he gets a Spanish version of his name and a more appropriate sword. And in all periods he gets an officer's uniform - Chamot / Chamfort is not a common soldier! Since this sorts out his name in advance, the dialog files can keep the "#sAntoineChamfort#" references. I've tested this by engaging cheatmode, starting new test games in both "Early Explorers" and later period, boosting my level to 15, and heading straight for <insert Port au Prince name>. As far as I'm concerned, this part of the "Angelique Moulin" quest is now fixed.

I've also defined "old_journal2", both in "initItems.c" and "ItemsDescribe.txt". This will be needed partly because the revised journal will have revised directions to the sword, and partly because the current journal has entries dated 1595, which as far as Francis Drake is concerned is several years into the future. "old_journal2" has the same dates but in 1495, presumably from someone following in Columbus' footsteps, or possibly one of Columbus' colleagues. (That way it's still in the past even if you take "Early Explorers" to the limit, which is 1500.)

Next: find somewhere suitable to bury the sword in "Early Explorers". I'm having second thoughts about Cartagena. Hiding it on the beach used by every smuggler trying to get contraband into one of the biggest ports in the Caribbean is probably not a good idea. Cuba has several beaches with exits inland that, unlike the beach near Cartagena, do actually work, so I'm rather inclined to use somewhere in the jungle accessed from one of those.

 

[Pieter Boelen]

Oh well, in that case things become a lot simpler! It also probably explains why this line appears to have no effect:

ch.model = GetRandomModelForTypeExSubCheck(true, "Soldiers", "man", GetTownNation("Port au Prince"));  // PB

Antoine Chamfort still always appears in French uniform. I'm guessing that "SideQuest.c" is run even before the code which translates the town to its current nationality as defined by "Periods.c", so Antoine Chamfort is still Antoine Chamfort and he's still in French uniform because Port au Prince is French until told otherwise.

I was afraid that might be the case.
We might still be able to do it automatically by putting the change in Periods.c instead together with some of the other quest code that I put in there.
These lines might do it:

ref ch = CharacterFromID("Antoine Chamfort");
SetModel(ch, GetRandomModelForTypeExSubCheck(true, "Land_Officers", "man", GetTownNation("Port au Prince")));

You may have to check the syntax again, because I'm not near my game yet to check.
Something like that should work, though.

I've also defined "old_journal2", both in "initItems.c" and "ItemsDescribe.txt". This will be needed partly because the revised journal will have revised directions to the sword, and partly because the current journal has entries dated 1595, which as far as Francis Drake is concerned is several years into the future. "old_journal2" has the same dates but in 1495, presumably from someone following in Columbus' footsteps, or possibly one of Columbus' colleagues. (That way it's still in the past even if you take "Early Explorers" to the limit, which is 1500.)

Good thinking. We don't need no Back to the Future here. Unless we're deliberately putting in an easter egg of sorts.

Next: find somewhere suitable to bury the sword in "Early Explorers". I'm having second thoughts about Cartagena. Hiding it on the beach used by every smuggler trying to get contraband into one of the biggest ports in the Caribbean is probably not a good idea. Cuba has several beaches with exits inland that, unlike the beach near Cartagena, do actually work, so I'm rather inclined to use somewhere in the jungle accessed from one of those.

Perhaps more jungle locations can be added to the Cartagena shore? But that's probably more trouble than it's worth.
Any location would technically do; as long as it works and is accessible.

 

[Levis]

I wouldn't mind if we add a few more beaches along the main coastline and add some jungle locations to them. Would make discovering the spanish main more interesting.

 

[Pieter Boelen]

I wouldn't mind if we add a few more beaches along the main coastline and add some jungle locations to them. Would make discovering the spanish main more interesting.

That is a tough one, I'm afraid. @Armada had a very hard time getting the coast around Cartagena to make any sense and line up with the worldmap.
Problem is that the coastal "islands" in CoAS that we used are 180 degrees wrong, so they have to be rotated and the coordinates made to match up sensibly.
While that isn't so hard to use the extra locators surrounding Cartagena, if anything further along the coast is needed, that would also require a new island model which should be added to the worldmap invididually.

So could it be interesting? Sure. But would not be easy to accomplish. So then the question is whether it is worth it.
I figure until there is something that needs to make use of those extra locations, such as a quest or a gameplay feature, there is little point in having it.
More content doesn't make for more or better gameplay until it is used, after all.

 

[Grey Roger]

I was afraid that might be the case.
We might still be able to do it automatically by putting the change in Periods.c instead together with some of the other quest code that I put in there.

And scatter the quest code around even further? It's already a challenge finding where everything which controls a quest is located without it going into even more places. Chamfort's nationality, name, costume and equipment are going to have to be defined somewhere - may as well do it in the file where nationality, name, costume and equipment are supposed to be defined.

Perhaps more jungle locations can be added to the Cartagena shore? But that's probably more trouble than it's worth.
Any location would technically do; as long as it works and is accessible.

Another thought, if this is so close to the Columbus expedition that the journal's author was probably part of it: one of the beaches on Turks Island, alias San Salvador, could work. So could Hispaniola. (At one point the Pinta went off on an unauthorised expedition of its own on a course that could have taken it to Tortuga. If the exit from Tortuga town leads to anywhere other than the location cloned from Speightstown exit, that could work, though the town wouldn't have been there when the sword was buried so writing the directions would be tricky...) On the other hand, if I'm going to work Columbus into this (which is probably necessary if the date on which the sword was buried is to be earlier than 1500 and therefore definitely before anyone playing "Early Explorers" gets there) then Cartagena is out because Columbus never went near that area.

 

[Pieter Boelen]

And scatter the quest code around even further? It's already a challenge finding where everything which controls a quest is located without it going into even more places. Chamfort's nationality, name, costume and equipment are going to have to be defined somewhere - may as well do it in the file where nationality, name, costume and equipment are supposed to be defined.

As long as nobody decides to change the nationality of that town again for some reason, because that solution isn't quite generic.
Of course we have been using a lot of non-generic solutions lately, which means that perhaps we should just define the periods correctly now and not touch them again in the future.

For Periods.c, indeed it doesn't make all that much sense to have quest code there, but I needed to do it so I don't see much of an issue of adding some more stuff there.
That is also where Arabella Silehard's last name is overridden to match with the actual governor of Jamaica, because that differs in each period and pretty much is never actually Silehard.
You could just add a common in the character init file to indicate that the entry is further modified in Periods.c so at least it should be clear to anyone who looks at it in the future.

I'm pretty sure GetCurrentPeriod() does work in the character init files. That means perhaps we can read out the town nationality in a more direct way from the period code.
But that would require some figuring out and probably isn't quite worth it....

 

[Grey Roger]

As long as nobody decides to change the nationality of that town again for some reason, because that solution isn't quite generic.
Of course we have been using a lot of non-generic solutions lately, which means that perhaps we should just define the periods correctly now and not touch them again in the future.

If it's going to be historically accurate, Port au Prince should be Spanish in "Early Explorers", French for most of the rest, and independent in "Napoleonic" - good luck with that. Anyway, if Port au Prince is going to change hands again and someone notices that the "Angelique Moulin" quest is once again inconsistent with a certain period, the easy solution would be to replace the "if... else..." with a "switch(GetCurrentPeriod())" block.

I'm pretty sure GetCurrentPeriod() does work in the character init files. That means perhaps we can read out the town nationality in a more direct way from the period code.
But that would require some figuring out and probably isn't quite worth it....

"GetCurrentPeriod" certainly does work in the character init files, at least in "SideQuest.c", because that's how I determine whether the officer should be Spanish Antonio Chamot or French Antoine Chamfort.

 

[Pieter Boelen]

If it's going to be historically accurate, Port au Prince should be Spanish in "Early Explorers", French for most of the rest, and independent in "Napoleonic" - good luck with that.

Indeed I ran into that one about an independent Hispaniola when I tried to put in the Henri Caesar character yesterday.
My current simple solution was to claim that the player has to make it independent during actual gameplay.
It should be quite possible to have a town set as PERSONAL_NATION at the start of the game. But then the game will think it is actually yours.
That might not be the best idea, though perhaps an extra check could be implemented to distinguish player owned towns and friendly independent towns (I don't think they could be hostile).
Might open up some gameplay potential....

"GetCurrentPeriod" certainly does work in the character init files, at least in "SideQuest.c", because that's how I determine whether the officer should be Spanish Antonio Chamot or French Antoine Chamfort.

periods[GetCurrentPeriod].Towns.PortAuPrince.nation or something like that might not be impossible.
That would read from the actual structure set up in Periods.c .

 

[Armada]

That is a tough one, I'm afraid. @Armada had a very hard time getting the coast around Cartagena to make any sense and line up with the worldmap.
Problem is that the coastal "islands" in CoAS that we used are 180 degrees wrong, so they have to be rotated and the coordinates made to match up sensibly.
While that isn't so hard to use the extra locators surrounding Cartagena, if anything further along the coast is needed, that would also require a new island model which should be added to the worldmap invididually.

Yeah, this was enough of a pain for just one CoAS location. We still see issues between DirectSail and the World Map for Cartagena because of how the engine handles large 'islands', too, and this would only get worse with more mainland locations.

It is doable to import more locations, and my recent Maya tutorial should make at least rotating the model fairly easy, but the locators and World Map positions are the real killer.
I would definitely back Pieter's suggestion of adding new shore and jungle locations to Cartagena, though, which would at least add some more variety.

 

[Pieter Boelen]

@Grey Roger: I'll be updating my own game version tonight, so do you have any "latest" files to share by any chance?

Also, is there anything you still need help with figuring out? I might be able to spare a bit of time this evening to have a look at some files if needed.

 

[Grey Roger]

Done!

The sword's new home in "Early Explorers" will be a couple of moves inland from Punta de Maisi on Cuba. I had a look round with visible locators enabled to see which exits I was following, then checked "PROGRAM\Locations\init\Cuba.c" to figure out which locations I was visiting. Where I ended up was "Cuba_Jungle_03", which has the advantage of being the same type of jungle location as the one on Antigua where you'd find the sword anyway, so it's still on "citizen010", just on a different island. Then I edited "quests_side.c" to set the win condition depending on period, started a new test game, blitzed through the quest, and now I'm the proud owner of a second-hand, recently excavated Dragon's Head.

This should contain the lot. I've yet to try the quest in a later period to check that I haven't accidentally done anything to mess it up, but it certainly works in "Early Explorers". I haven't done anything with the new sword from @Bartolomeu o Portugues because I never got the interface pictures, but it ought to be easy enough to knock up entries in "initItems.c" and "ItemsDescribe.txt", then edit "quests_side.c", specifically case "jelaifini", replace "blade34+2" with whatever the new sword is called.

 

[Grey Roger]

Who's this?



He appears to be some sort of British naval character, but he has no business being on the deck of a 16th century galleon when that sort of uniform didn't exist! Also, it's most annoying having an intimate encounter with his left shoulder immediately after switching to 1st person view... (He's going to look even more out of place on any non-British ship if that's the default appearance for a helmsman now. )

 

[Pieter Boelen]

The sword's new home in "Early Explorers" will be a couple of moves inland from Punta de Maisi on Cuba. I had a look round with visible locators enabled to see which exits I was following, then checked "PROGRAM\Locations\init\Cuba.c" to figure out which locations I was visiting. Where I ended up was "Cuba_Jungle_03", which has the advantage of being the same type of jungle location as the one on Antigua where you'd find the sword anyway, so it's still on "citizen010", just on a different island. Then I edited "quests_side.c" to set the win condition depending on period, started a new test game, blitzed through the quest, and now I'm the proud owner of a second-hand, recently excavated Dragon's Head.

Very clever!
Did you ever figure out how to use console to display your current location? It should be really quite easy.
If you can't find the relevant switch value, this line should do the trick too:

LogIt(pchar.location);

This should contain the lot. I've yet to try the quest in a later period to check that I haven't accidentally done anything to mess it up, but it certainly works in "Early Explorers". I haven't done anything with the new sword from @Bartolomeu o Portugues because I never got the interface pictures, but it ought to be easy enough to knock up entries in "initItems.c" and "ItemsDescribe.txt", then edit "quests_side.c", specifically case "jelaifini", replace "blade34+2" with whatever the new sword is called.

Maybe @Jack Rackham or @Bartolomeu o Portugues can have a look at implementing that one?
At least the current state should be functional then.

He appears to be some sort of British naval character, but he has no business being on the deck of a 16th century galleon when that sort of uniform didn't exist! Also, it's most annoying having an intimate encounter with his left shoulder immediately after switching to 1st person view... (He's going to look even more out of place on any non-British ship if that's the default appearance for a helmsman now. )

I think that is one of the custom added details that @Jack Rackham added to the Golden Hind.
There are two other characters there, one near the cabin railing and one in the crow's nest.

 

[Jack Rackham]

Those charcaters could easy be removed/moved/changed. I'll look at it when I get time.