They got the same issue.
I have one that we use on World of Greyhawk. It is persistent, through server resets, etc. You can customize, rename it, interact with hitching posts, etc. However, my DM Client/Toolset computer took a crap on itself and she’s currently at the shop. When I get everything back, hopefully by weeks end, I can share it with you, GoG.
3 Likes
Yeah that would be awesome.
Setting reminder to check up on this.
The vanilla system persistence is indeed bad and will probably fail because SetCampaign# functions doesn’t work properlly with oPC parameter afaik.
But did you try it? Did you set it properly? You are supposed to set local variable “bX3_STORE_MOUNT_INFO” int 1 on module and use script “x3_mod_def_hb” in module OnHeartbeat.
If you did that and it doesn’t work (which won’t suprise me at all), then I would try to rewrite the functions “HORSE_SupportStoreMountedPCInDatabase” and “HORSE_SupportDeleteMountedPCFromDatabase” in “x3_inc_horse” to store/delete variables on a “system item” in player inventory or store it into external database with NWNX or rewrite the vanilla db calls to not use oPC parameter but add some PC identifier into variable names. That should work. (Though the whole idea of storing the status of the horse into db in heartbeat is stupid and can be exploited).
1 Like
That wasn’t it - bX3_STORE_MOUNT_INFO - is an internal value stored on horse owner. I think the variable you meant was X3_ENABLE_MOUNT_DB. If you set that variable on the module, that is where the henchman system breaks in storing/retrieving horses IF the horse is dismounted (but still a henchman) if you log off the Server.
In any event, I managed a hack to workaround it, by changing these two functions in x0_i0_henchman (thank you Huntsman henchman tutorials):
/*
Call this function in the OnClientLeave event for the Server.
*/
void ps_StoreCampaignHenchman(object oPC)
{
object oHench;
string sHench;
int ret, iSlot, iMax = GetMaxHenchmen();
for (iSlot = 1; iSlot <= iMax; iSlot++)
{
oHench = GetHenchman(oPC, iSlot);
if (!GetIsObjectValid(oHench))
DBG_msg("No valid henchman to store");
else
{
DBG_msg("Storing henchman: " + GetTag(oHench));
sHench = "Henchman" + IntToString(iSlot);
ret = StoreCampaignDBObject(oPC, sHench, oHench);
if (!ret)
DBG_msg("Error attempting to store henchman " + GetName(oHench));
else
DBG_msg("Henchman " + GetName(oHench) + " stored successfully");
}
}
}
/*
Call this function in the OnClientEnter event for the Server.
The restored henchman will automatically be re-hired and will be
created next to the PC.
Any object in the module with the same tag as the henchman will be
destroyed (to remove duplicates).
*/
void ps_RetrieveCampaignHenchman(object oPC)
{
string sHench;
object oHench, oDupe;
location lLoc = GetLocation(oPC);
int iSlot, iMax = GetMaxHenchmen();
for (iSlot = 1; iSlot <= iMax; iSlot++)
{
sHench = "Henchman" + IntToString(iSlot);
oHench = RetrieveCampaignDBObject(oPC, sHench, lLoc);
DelayCommand(0.5, DeleteCampaignDBVariable(oPC, sHench));
if (GetIsObjectValid(oHench))
{
//------------------------------------------------------------------
//* PS 6/1/20: Yes, we are adding then removing the henchman as a
//* hacky workaround (see the file description above)
DelayCommand(0.5, AddHenchman(oPC, oHench));
DelayCommand(1.5, RemoveHenchman(oPC, oHench));
//------------------------------------------------------------------
oDupe = GetNearestObjectByTag(GetTag(oHench), oHench);
if ((oDupe != OBJECT_INVALID) && (oDupe != oHench))
{
AssignCommand(oDupe, SetIsDestroyable(TRUE));
SetPlotFlag(oDupe,FALSE);
SetImmortal(oDupe,FALSE);
DestroyObject(oDupe);
}
}
else
DBG_msg("No valid henchman retrieved");
}
}EDIT - And after multiple store/reload calls, it stops removing the horse henchman and reverts to the screwed up behavior described above.
Yeah sorry, I copied wrong variable name. It is indeed X3_ENABLE_MOUNT_DB.
Anyway, how exactly are you using it, or rather can you tell me how can I reproduce the issue? If I understand it correctly you allow your henchman to have his own henchmen (horse)?
Despite the horse system is something that would deserve complete rewrite, it somehow got into vanilla. If you give me details how to reproduce it I might be able to fix this.
1 Like
Ok, this is what happens:
- Paint a horse from the standard palette into an area. Make sure it has the XP2 HotU Henchman AI (according to the Horse Guide by Proleric).
- Load the module (I’ve been doing it as a Server - no local vault)
- Assign the Horse as a mount.
- DO NOT MOUNT the horse - its portrait should be in the party window
- Leave the Server.
- Re-enter the Server.
- You will get three possible results:
- The horse’s portrait appears in the party window but it is either a) noninteractive or b) has the menu options you would expect with a neutral creature as opposed to the menu options for a henchman.
Here’s a link to a copy of the mod with my hacky fix - which is bullet proof now.
Thanks I will look into it later.
Well that module I made above works great UNLESS you have two dismounted “horse henchmen” - in which case it all goes to @$%&.
So at this point some kind soul PLEASE PLEASE, set me up with a vanilla EE module that can actually do something in regards to persistence with henchmen?
This is all I’d like it to do:
- You can hire multiple henchmen
- You can persistently store multiple henchmen
- You can retrieve those henchmen when you log in
- Horses that actually work (be nice if it were Bioware’s horse system, but I’ll take anything that works with their models.
I know somewhere out there SOMEONE, a PW admin or scripter HAS this functionality. PLEASE, can you share it with me. I’m simply looking to do a Lan PW with my kids and pass a copy of the base code onto a friend. I’m not looking to hi-jack anyone’s PW with a cloned server.
Thank-you to whoever bails me out.
1 Like
Good luck…lol…I hope a good person on here can help you.
I do have one, but my Toolset Computer is taking a bit longer to fix than I anticipated. In the meantime, I fired up an old PC where I kept some legacy files since we haven’t really changed our horse system in about 10 years. The one problem I anticipate is dis-entangling it from the tapestry of the various server scripts – OnRest, OnDeath, OnDying, OnRespawn, Lesser Restore, Restore, Greater Restore, NPC mounting, OnModule Load, phenotypes based on weapon wielded, etc… When you run the same server for 16 years, things tend to get woven into the fabric after awhile…
Before I go down that road, let me just explain how it works and you can decide if you want to try it:
- It uses the default horse models
- It scales the horses to the size of your character model
- Horses can be saved to your character via a widget (Horse Whistle). You can restore the horse (like a Summons) as long as it is in the same area where you saved it.
- If you save your horse, you can still resummon it upon a server reset (by using horse whistle)
- If you become separated from your horse, the horse whistle will give you approximate distance and direction your horse is
- If you log out while on your horse, you will log back in on your horse, even through a reset
- You can rename your horse, or change your horses appearance (saddle, saddlebags, barding, etc). This is persistent.
- Phenotype will change to Jousting if wielding spear, lance or trident or halberd
- The speed of the horse is roughly equivalent to Expiditious Retreat
A few other flourishes:
- Saddle Bag system to reduce encumbrance (in the form of a Bag item in inventory, works only while mounted).
- Hitching Post: If mounted and clicked on, auto dismounts PC and anchors horse at post
- No Mounted PCs in underground/interior areas – feedback provided to PC
The system is persistent unless the following happens:
- Player logs out without saving horse via Whistle first, and the server resets.
- Known bug: Sometimes having a Summons out while your horse is also in your party (but not mounted), will result in not being able to mount the horse. Player work around is to rest and all is well.
Let me know if this is something that sounds like what you had in mind and I’ll do my best to put together some kind of package/erf.
2 Likes
Txpple fixed the final issue I was having. The issue wasn’t the horse scripts at all, it was in x0_i0_henchman. The fix is in the fourth post, here…
1 Like
I’m definitely interested in something like this. Is your code available on a repo somewhere? I’d love to see it. Thanks!
The code is in my last post - the one above your reply. Click the dropdown arrow next to the link.
Saw that, my post was in reply to DM Wise. Is that the same code he’s taking about?
Sorry, missed the @ DM_Wise tag - hate the way the Vault does that. No, his code is different. My code works in conjunction with the way they are implemented by Bioware in v1.69, which doesn’t require any fancy setup (beyond what you need to do anyway) and doesn’t use widgets to “summon” the horse.
Basically, it has these features:
- It uses the default horse models (Bioware Behavior)
- Horses scale to the size of the PC (Bioware behavior).
- Horses are added as henchmen and saved when the PC logs out.
- Dynamic adjusting of MaxHenchman to support additional horses.
- Supports Henchman horses across server resets.
- Horses are persistent across server resets.
- If you log out while on your horse, you will log back in on your horse, even through a reset.
- Many switches in the Module OnLoad event to tweak horse behavior (thank-you @Proleric).
- Supports the Horse’s Inventory to be used as Saddle Bags, storing horse inventory in a database. so the contents persists across server resets (Bioware behavior).
- Supports Hitching Posts (Bioware behavior).
There are no known issues.
The code is part of my Persistent World Base and will be published at some point in the future - once I have the custom content I plan on using/developing sorted out and in place.
1 Like
Any way I could get a glimpse? We’re looking at implementing horses in an older module and wanted to get a headstart. Might be able to help with any development that it still needs (if any). Unless, of course, those two are the only additions to the bioware system. If so, I’d probably need to adapt to external database vs campaign database.
That’s really the only changes. The rest is just setting up the module to properly use horses - see @Proleric 's guide in the Lexicon.
I just use the Bioware Database system, which has been greatly improved by EE converting them to SQLite.
1 Like
Thanks!