Note: Because this mod may be helpful to all who currently make new locations or islands I have uploaded a work-in-progress version of this mod.(FTP server, folder cccXperimentMods, NewOxbayAndRandLocs.zip) It basically works (at least on my codebase) but there may be loose ends and many dialogs and miniquests are still missing. Please do not use this preliminary mod if you want your game to be perfect ! I will resume working on this in a few weeks, I hope.
By now we have the knowledge to enlarge the PotC gameworld with new locations, locationtypes, towns and even new islands. But it would be a lot of work and probably a heavy tax on the program to make dozens of individual houses/junglelocations for each new town/island. A possible solution would be a generator that creates RANDOM locations to fill the empty spaces automatically. Random means that you can't tell in advance which location you will find after an exit, and the location will also not be permanent. That means that using ONLY random locations doesn't make much sense. But one could compose a town out of a few permanent questlocations (and maybe the stores) and many random locations.
(BTW, the same is valid for townpopulations: as soon as you create a location of the type "town" or "house" the VC mod will fill it automatically with citizens and occupants. I plan to add generated tavernkeepers and merchants etc. as well, so that as soon as someone makes a town it will automatically be populated, and only a few individual keycharacters need to be created)
Here is a first raw experimental housegenerator that connects EVERY unused door in a town with a house (so that you will never stand in front of closed doors anymore if you need help, shelter or plunder <img src="http://www.piratesahoy.com/forum/style_emoticons/<#EMO_DIR#>/smile.gif" style="vertical-align:middle" emoid="
" border="0" alt="smile.gif" /> )
In the file characters\characters_events.c you find the function void chrCharacterEntryToLocator(), which runs whenever a character steps on a locator. If the player steps on a locator of the "reload" type (exits) that has NO connection with another location this code displays the "closed padlock" icon:
case "reload":
chrWaitReloadIsNoLink = false;
....
if(result != 1)
{
chrWaitReloadIsNoLink = true;
if(result == 0) Log_SetActiveAction("Closed");
break;
}
....
To make the player aware that the formerly closed door leads now to a random location we display some screenmessage like:
chrWaitReloadIsNoLink = true;
if(result == 0) Log_SetActiveAction("Closed");
logit("You could pry this door open, but you never know what's waiting behind!"); // ccc random locs
break;
If the player now presses the action key this function further down runs:
void chrCharacterKeys()
{
string controlName = GetEventData();
....
if(noReload)
{
if(chrWaitReloadLocator != "")
{
PlayStereoSound("knock");
}
return;
}
//trace(" &&&&&&&&&&&&&&&&&&&&&&&&&&& ");
...
chrWaitReloadIsNoLink = false;
}
What is of interest to us is the command 'PlayStereoSound("knock");', which plays the knock sound if a door is closed. Instead of doing that we'll call a function that we will name 'GoToRandomLoc()'
void chrCharacterKeys()
{
string controlName = GetEventData();
....
if(noReload)
{
if(chrWaitReloadLocator != "")
{
// ccc random locs PlayStereoSound("knock");
GoToRandomLoc() // ccc random locs
}
return;
}
//trace(" &&&&&&&&&&&&&&&&&&&&&&&&&&& ");
...
chrWaitReloadIsNoLink = false;
}
Into that GoToRandomLoc() function we will put the code for our future Random Location Generator. For convenience's sake I currently put it at the end of this characters\characters_events.c file. Over time we can add to this locationspecific code that sends you to houses if you are in a town, or jungles outside, or bedrooms, kitchens or studies from the entrance hall of a mansion, or into a maze if you are in a dungeon... Once again, PotC offers almost unlimited possibilities.
But for a simple start we'll just teleport the player to one of 14 random locations which I put into locations\init\cccRandomLocations.c :
void GoToRandomLoc() // ccc random locs
{
string randloc = "randomhouse"+rand(13); // selects a randomlocation
DoQuestReloadToLocation(randloc, "reload", "reload1" ,""); // teleport to rancloc
Log_SetActiveAction("Nothing"); // deletes padlock icon
}
So every formerly unused door now leads to some location if you press your ACTION KEY (F3 doesn't work ). If we use for those random locations some bigger houses, residences, shops etc. the random towns will even be more interesting than Akella's little huts.
So much for getting in. What will happen if you try to leave one of those new random locations? Right, because the doors of those can not be connected to any "normal" location (which one?) you will get to the next randloc, and from there to the next... Kind of an open ended game , but surely not really what we want. In order to allow the player to return from the random locations to the "normal" location he came from we must find a way to store from where he entered. The solution, as so often, are attributes. We add the names of the location and locator where the player entered as attributes ".lastlocation" and ".lastlocator" to the maincharacter.
Remember that we added the "pry open" screenmessage in void chrCharacterEntryToLocator() ? Well, I messed with that function not only for that message but because it already determines all the data we need: the maincharacter "mc", the locatorname "locator" and the location ID "loc.id". We save all that as attributes to the player mc , also the townsack attribute for townbased functions.
if(result != 1)
{
chrWaitReloadIsNoLink = true;
if(result == 0) Log_SetActiveAction("Closed");
logit("You could pry this door open, but you never know what's waiting behind!");
if(!CheckAttribute(loc, "randloc")) // not in random locations
{
mc.lastlocation = loc.id; // last "normal" location before random loc
mc.lastlocator = locator; // last locator in "normal" loc
if(CheckAttribute(loc,"townsack") ) mc.lasttownsack = loc.townsack;
}
break;
}
So we have now stored from where we entered the randlocs. Now we need to make a returnprocedure. For that I made an assumption. Please check it carefully in case I made a mistake there, which is quite possible. (If you are not in the mood for checking my twisted logic skip the next two paragraphs )
Assumption:
1. If a location has a locator with the name "reload1" it is usually the main entry. Therefore there will be almost no unconnected "reload1" locators in the "normal" locations.
2. For random locations, which WE create, we can ensure that "reload1" WILL always be the first entry point.
3. The first ENTRYpoint is also the point where one would expect the EXIT back to the former "normal" location.
1+2+3: An unconnected "reload1" is usually a locator from where the player wants to return to to a normal location.
Does that make sense? .... Well, never mind, a bit of playtesting is better than any theorizing. Should I be wrong we'll just relabel one locator in each random location as "return_spot"
BTW, you may wonder why I make so much fuss about the right return spot. Well, if you have as random location only a shabby hut it's easy: the one and only door is the return spot. But this shall also work for vast mansions with one room after the other. Or for the jungles of Cuba, where your buccaneer expedition marches through a dozen junglelocations before reaching some inland town, goldmine or palace/temple. So the random teleport procedure must somehow determine whether the player wants to march further inland(i.e. yet another randloc) or if he wants to abort his expedition(back to last normal loc, which will be in one leap the way I write it, no marching through all the locs again)
Whatever, i wrote my "return to normal" procedure so that it is triggered if you step on a UNCONNECTED "reload1" locator. It will then teleport you back to the stored ".lastlocation":
if(chrWaitReloadLocator != "")
{
// ccc random locs PlayStereoSound("knock");
if(chrWaitReloadLocator != "reload1") { GoToRandomLoc(); } // ccc random locs
else { DoQuestReloadToLocation(mc.lastlocation, "reload", mc.lastlocator ,""); }
}
Semi-random locations
I presume that every new town we will make shall have a tavern and a shop. Therefore I included an "inn" and a "tradepost" in the preliminary loactiongenerator. The owners will be generated by the new VC version as well. These locations will appear at random occaisionally "Welcome to my new tavern. I have just opened up in these rooms."
But the player will expect the tavern/shop behind the door under the tavern/shop sign. So we must ensure that whenever a player activates this door the tavern/shop will be used and not another random location.
Which is easy if we tell the location generator which locator in which townmodel shall lead to a tavern/shop. E.g. in the Oxbay townmodel the locator "reload13" leads to the tavern. So we can include a command that tells the generator "if the current model is town_Oxbay AND the locator is reload13 then teleport to tavern".
Point to point marches via random locations
What this system so far can not provide is travelling between two normal, defined locations via randlocs. But with some tricks, which i'll (try to) eplain another day (worn out now) this will be possible too. E.g. we make the island of Cuba with only two defined locations, Santiago and Havanna, and you march from Santiago through some random jungles(with a few surprise settlements or forts) in order to reach Havanna finally and surprise its defences from the landside.
By now we have the knowledge to enlarge the PotC gameworld with new locations, locationtypes, towns and even new islands. But it would be a lot of work and probably a heavy tax on the program to make dozens of individual houses/junglelocations for each new town/island. A possible solution would be a generator that creates RANDOM locations to fill the empty spaces automatically. Random means that you can't tell in advance which location you will find after an exit, and the location will also not be permanent. That means that using ONLY random locations doesn't make much sense. But one could compose a town out of a few permanent questlocations (and maybe the stores) and many random locations.
(BTW, the same is valid for townpopulations: as soon as you create a location of the type "town" or "house" the VC mod will fill it automatically with citizens and occupants. I plan to add generated tavernkeepers and merchants etc. as well, so that as soon as someone makes a town it will automatically be populated, and only a few individual keycharacters need to be created)
Here is a first raw experimental housegenerator that connects EVERY unused door in a town with a house (so that you will never stand in front of closed doors anymore if you need help, shelter or plunder <img src="http://www.piratesahoy.com/forum/style_emoticons/<#EMO_DIR#>/smile.gif" style="vertical-align:middle" emoid="
" border="0" alt="smile.gif" /> )In the file characters\characters_events.c you find the function void chrCharacterEntryToLocator(), which runs whenever a character steps on a locator. If the player steps on a locator of the "reload" type (exits) that has NO connection with another location this code displays the "closed padlock" icon:
case "reload":
chrWaitReloadIsNoLink = false;
....
if(result != 1)
{
chrWaitReloadIsNoLink = true;
if(result == 0) Log_SetActiveAction("Closed");
break;
}
....
To make the player aware that the formerly closed door leads now to a random location we display some screenmessage like:
chrWaitReloadIsNoLink = true;
if(result == 0) Log_SetActiveAction("Closed");
logit("You could pry this door open, but you never know what's waiting behind!"); // ccc random locs
break;
If the player now presses the action key this function further down runs:
void chrCharacterKeys()
{
string controlName = GetEventData();
....
if(noReload)
{
if(chrWaitReloadLocator != "")
{
PlayStereoSound("knock");
}
return;
}
//trace(" &&&&&&&&&&&&&&&&&&&&&&&&&&& ");
...
chrWaitReloadIsNoLink = false;
}
What is of interest to us is the command 'PlayStereoSound("knock");', which plays the knock sound if a door is closed. Instead of doing that we'll call a function that we will name 'GoToRandomLoc()'
void chrCharacterKeys()
{
string controlName = GetEventData();
....
if(noReload)
{
if(chrWaitReloadLocator != "")
{
// ccc random locs PlayStereoSound("knock");
GoToRandomLoc() // ccc random locs
}
return;
}
//trace(" &&&&&&&&&&&&&&&&&&&&&&&&&&& ");
...
chrWaitReloadIsNoLink = false;
}
Into that GoToRandomLoc() function we will put the code for our future Random Location Generator. For convenience's sake I currently put it at the end of this characters\characters_events.c file. Over time we can add to this locationspecific code that sends you to houses if you are in a town, or jungles outside, or bedrooms, kitchens or studies from the entrance hall of a mansion, or into a maze if you are in a dungeon... Once again, PotC offers almost unlimited possibilities.
But for a simple start we'll just teleport the player to one of 14 random locations which I put into locations\init\cccRandomLocations.c :
void GoToRandomLoc() // ccc random locs
{
string randloc = "randomhouse"+rand(13); // selects a randomlocation
DoQuestReloadToLocation(randloc, "reload", "reload1" ,""); // teleport to rancloc
Log_SetActiveAction("Nothing"); // deletes padlock icon
}
So every formerly unused door now leads to some location if you press your ACTION KEY (F3 doesn't work ). If we use for those random locations some bigger houses, residences, shops etc. the random towns will even be more interesting than Akella's little huts.
So much for getting in. What will happen if you try to leave one of those new random locations? Right, because the doors of those can not be connected to any "normal" location (which one?) you will get to the next randloc, and from there to the next... Kind of an open ended game , but surely not really what we want. In order to allow the player to return from the random locations to the "normal" location he came from we must find a way to store from where he entered. The solution, as so often, are attributes. We add the names of the location and locator where the player entered as attributes ".lastlocation" and ".lastlocator" to the maincharacter.
Remember that we added the "pry open" screenmessage in void chrCharacterEntryToLocator() ? Well, I messed with that function not only for that message but because it already determines all the data we need: the maincharacter "mc", the locatorname "locator" and the location ID "loc.id". We save all that as attributes to the player mc , also the townsack attribute for townbased functions.
if(result != 1)
{
chrWaitReloadIsNoLink = true;
if(result == 0) Log_SetActiveAction("Closed");
logit("You could pry this door open, but you never know what's waiting behind!");
if(!CheckAttribute(loc, "randloc")) // not in random locations
{
mc.lastlocation = loc.id; // last "normal" location before random loc
mc.lastlocator = locator; // last locator in "normal" loc
if(CheckAttribute(loc,"townsack") ) mc.lasttownsack = loc.townsack;
}
break;
}
So we have now stored from where we entered the randlocs. Now we need to make a returnprocedure. For that I made an assumption. Please check it carefully in case I made a mistake there, which is quite possible. (If you are not in the mood for checking my twisted logic skip the next two paragraphs )
Assumption:
1. If a location has a locator with the name "reload1" it is usually the main entry. Therefore there will be almost no unconnected "reload1" locators in the "normal" locations.
2. For random locations, which WE create, we can ensure that "reload1" WILL always be the first entry point.
3. The first ENTRYpoint is also the point where one would expect the EXIT back to the former "normal" location.
1+2+3: An unconnected "reload1" is usually a locator from where the player wants to return to to a normal location.
Does that make sense? .... Well, never mind, a bit of playtesting is better than any theorizing. Should I be wrong we'll just relabel one locator in each random location as "return_spot"
BTW, you may wonder why I make so much fuss about the right return spot. Well, if you have as random location only a shabby hut it's easy: the one and only door is the return spot. But this shall also work for vast mansions with one room after the other. Or for the jungles of Cuba, where your buccaneer expedition marches through a dozen junglelocations before reaching some inland town, goldmine or palace/temple. So the random teleport procedure must somehow determine whether the player wants to march further inland(i.e. yet another randloc) or if he wants to abort his expedition(back to last normal loc, which will be in one leap the way I write it, no marching through all the locs again)
Whatever, i wrote my "return to normal" procedure so that it is triggered if you step on a UNCONNECTED "reload1" locator. It will then teleport you back to the stored ".lastlocation":
if(chrWaitReloadLocator != "")
{
// ccc random locs PlayStereoSound("knock");
if(chrWaitReloadLocator != "reload1") { GoToRandomLoc(); } // ccc random locs
else { DoQuestReloadToLocation(mc.lastlocation, "reload", mc.lastlocator ,""); }
}
Semi-random locations
I presume that every new town we will make shall have a tavern and a shop. Therefore I included an "inn" and a "tradepost" in the preliminary loactiongenerator. The owners will be generated by the new VC version as well. These locations will appear at random occaisionally "Welcome to my new tavern. I have just opened up in these rooms."
But the player will expect the tavern/shop behind the door under the tavern/shop sign. So we must ensure that whenever a player activates this door the tavern/shop will be used and not another random location.
Which is easy if we tell the location generator which locator in which townmodel shall lead to a tavern/shop. E.g. in the Oxbay townmodel the locator "reload13" leads to the tavern. So we can include a command that tells the generator "if the current model is town_Oxbay AND the locator is reload13 then teleport to tavern".
Point to point marches via random locations
What this system so far can not provide is travelling between two normal, defined locations via randlocs. But with some tricks, which i'll (try to) eplain another day (worn out now) this will be possible too. E.g. we make the island of Cuba with only two defined locations, Santiago and Havanna, and you march from Santiago through some random jungles(with a few surprise settlements or forts) in order to reach Havanna finally and surprise its defences from the landside.
" border="0" alt="par-ty.gif" />
" border="0" alt="me.gif" /> I was just talking to someone about the marrying mod, and thought the very same thing, it could use a bit of an overhaul. Give the wifey something more to do - nag you about things, ask you to run an errand for ya, that kind of thing... <img src="http://www.piratesahoy.com/forum/style_emoticons/<#EMO_DIR#>/whippa.gif" style="vertical-align:middle" emoid="
" border="0" alt="whippa.gif" /> <img src="http://www.piratesahoy.com/forum/style_emoticons/<#EMO_DIR#>/laugh.gif" style="vertical-align:middle" emoid="
:" border="0" alt="laugh.gif" />
k" border="0" alt="huhh.gif" /> 
" border="0" alt="wink.gif" />
" border="0" alt="yes.gif" /> We are currently renovating garden and carport, so I meet such a questgenerator every day: "Darling, the lawnbales will be deliverd on tuesday. Make sure the well is ready by then." "The rooftiles and pavement stones come on Thursday. Where shall they be stored?" "How about a pergola with white roses spanning over the gravelpath?"
" border="0" alt="dunno.gif" />