<!--QuoteBegin-alan_smithee+--><div class='quotetop'>QUOTE(alan_smithee)</div><div class='quotemain'><!--QuoteEBegin-->While you're answering questions, CCC:
I love that you know/told us how to do this. I was astounded when it worked last night, and I made a short cave location with an "opening" at the other end... So, thank you for your wiki.
I'm running into a little trouble now with a door that refuses to recognize what it's supposed to do (I've got some new underground locations beneath FdF: Start in the church and go through a door into an underground prison... one of the cells leads to a dungeon... at the end of the dungeon is a short segment of cave, after which is that underground church ruins... and that is SUPPOSED to lead to another dungeon, which emerges out a well elsewhere in town, via a "randitem" location), but that may have nothing to do with the "reload/randitem" thing.
My question is this: Since defining "randitem" as a reload does indeed remove that randitem's "pickup" property, I'd like to hexedit whichever one I'm using to be "randitemx," and then define that label alone as a reload spot... but can I define more than one exclusive reload spot, to have, say, "randitemx, y, z", and leave all other "randitems" as pickup spots?<!--QuoteEnd--></div><!--QuoteEEnd-->
Great that I was able to help, t'was a pleasure <img src="http://www.piratesahoy.com/forum/style_emoticons/<#EMO_DIR#>/smile.gif" style="vertical-align:middle" emoid="
" border="0" alt="smile.gif" /> That underground to FdF sure sounds like a great innovation and I would love to see it in Build12 <img src="http://www.piratesahoy.com/forum/style_emoticons/<#EMO_DIR#>/smile.gif" style="vertical-align:middle" emoid="
" border="0" alt="smile.gif" /> But I would like to caution expectations: I am not the expert on PotC, i am just dabbling a little with the code. I learned C coding only last winter, largely from NK, and I started to work with locations a few weeks ago. So others here know more than I do in some areas, e.g. the initialization.
That said let's see if I can help. As I know nothing about hexediting locatornames I can't say if your idea could work, but if you are able to change the locators in some modeldefinition that would certainly be the best solution (if it works pls write a tutorial <img src="http://www.piratesahoy.com/forum/style_emoticons/<#EMO_DIR#>/wink.gif" style="vertical-align:middle" emoid="
" border="0" alt="wink.gif" /> ). I would solve your problem by messing with the code again this way:
This section in "characterscharacters_events.c" determines the group and the name of the locator the player steps on
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->void chrCharacterEntryToLocator()
{
aref loc = GetEventData();
aref chr = GetEventData();
string group = GetEventData();
string locator = GetEventData();
...
Depending on which locatorgroup this yields the code "switches" to "cases", i.e. codesections that perform the action supposed to run for this locator:
switch(group)
{
case "reload":
chrWaitReloadIsNoLink = false;
...
...
Log_SetActiveAction("Reload");
}
}
break;
case "camdetector":
// CCC VC not connected with the locatormod-->
if(LOC_CAMERA)
...
else { locCameraFollow(); }
// CCC <--
break;
case "item":
Item_OnEnterLocator(loc, locator);
break;
case "randitem":
RandItem_OnEnterLocator(loc, locator);
break;
case "box":
Box_EnterToLocator(loc, locator);
break;
}
if( CheckAttribute(chr,"Quests.LocatorCheck." + group) )
{
chr.Quests.LocatorCheck.(group) = locator;
QuestsCheck();
}
}<!--c2--></div><!--ec2-->To turn a certain randitemlocator in your FdF cave into a reloadlocator you could tell the game:
If I am in FdF_cave and step on randitem_2 switch to the "reload" code instead of "randitem"
Translation into C:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if( mc.location == "FdF_cave" && locator == "randitem_2"){group = "reload";} //new code to turn randitem into reload in FdF cave
switch(group)
{
case "reload":
chrWaitReloadIsNoLink = false;
...<!--c2--></div><!--ec2-->
This works fine and has the advantage that it affects only the one locator that you defined in the IF condition.
Remember that this enables only exits. Entries (emerge positions) must be dealt with in characters_login.c
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if(TeleportCharacterToLocator(chr, chr.location.group, chr.location.locator)==0)
{
if((CheckAttribute(chr, "index") != false) &&
(GetMainCharacterIndex() == sti(chr.index)))
{
//----------- ccc To enable entry to `non-reload`-group locators
if(chr.location.locator=="randitem1") chr.location.group = "randitem";
else{if(chr.location.locator=="box1") chr.location.group = "box";}
else{chr.location.group = "rld";} //default locatorgroup, for forts
TeleportCharacterToLocator(chr, chr.location.group, chr.location.locator);
//------------ ccc end
Trace("Main character <" + chr.id + "> error teleportation by location: " + chr.location + " on locator: " + chr.location.group + "::" + chr.location.locator);
}else{<!--c2--></div><!--ec2-->
Though I have so far been unlucky with emerging on box or randitem locators. I always end up outside of the model (walled in alive or hanging on the ceiling <img src="http://www.piratesahoy.com/forum/style_emoticons/<#EMO_DIR#>/smile.gif" style="vertical-align:middle" emoid="
" border="0" alt="smile.gif" /> ). Probably because the locators I tried are too close to the wall. Has anyone had more success?