Quote:
Originally Posted by dagulus2
Don't know if this will help, but have you looked at how the code works for setting Beastlord Warders, as I am pretty sure they are set upon spawn to textures other than 0 and in the database they all share one entry (set to race 0).
|
I hadn't looked at the code for Beastlord warders, no. I knew that their race is chosen based on the race of their master, but I hadn't looked at how that works.
I just poked through it a bit, thanks to your suggestion, and it looks like it sets the the race and texture by changing the npctype before the pet object is created. But you're right, it does use textures other than 0 for some of them. So basically, it creates a basic NPCTypeStruct, the same as with bots, then it fills and modifies the values of the NPCTypeStruct, and then it creates the Pet object and eventually does an entity_list update to create a spawn based on the Pet object.
That suggests that if we were to change the NPCTypeStruct variable values *before* we create the Bot object, then it might work. The problem, though, is that in order for us to be able to save the texture as a variable, without completely changing the bot table structure to include it (and everything that goes with changing the structure), then we would have to either hard code the texture, or make the system choose a texture based on the database information. And then we would still need to change the face value to 0 for when we spawn the bot, but still have it save the original face value to the database when it makes updates through the Save() function.
Anyway, I played around with the code some more before I read dagulus2's reply, and tried the following...
I removed all of my previous code changes related to this issue, so bots were reverted back to "normal", and displaying generic human models for the non-standard races. I then edited the Spawn function only. I set it up to create two local variables, race and face, and to set the value of those variables by getting the data from the base Bot object (this would be the data retrieved from the database by the LoadBot function). I then checked for non-standard race. If race is non-standard, then set texture = face, helmtexture = face, gender = 2, and luclinface = 0. If the race is a standard race, then set texture = 0xFF, helmtexture = 0xFF, no other changes. All of this was added in *before* the Save() call, which means that when the Save() call is made, the database is updated with the new values (so we need to change face back again at a later point). Then, *after* the entity_list update, I added in a line to change luclinface = face to reset back to the original value that was in the database before we started, then I added a duplicate of the Save() call to update the database again.
Now in theory, it seems to me that should have worked. The basic process was to get the bot set up fairly normally, then set texture, helmtexture, gender, and face as necessary, and then, after the entity_list had been updated, reset the face value back to what it was and save it back to the database so that future spawns will not automatically revert to texture and helmtexture of 0. Following the code, it is the entity_list.AddBot function that actually creates and manifests the spawn in world, and the spawn is not a linked clone of the Bot object, but is a separate Spawn instance that was simply based on the Bot object. That being the case, any changes to the Bot object after the entity_list update should have no impact on the spawn itself.
That seemed to me like it *should* work to do what I want. Unfortunately, it does not seem to have actually worked. Instead, I still get a bot spawn that displays the default skin texture that would be expected with texture and helmtexture of 0.
I just don't get it, and it's really pissing me off. I'm thinking at this point that it might be easiest to change the #bot spawn command to accept a texture parameter. Then we can ignore the face value set in the database and always set it to 0 and leave it at 0 for non-standard races, but use the player-provided texture parameter to determine what texture and helmtexture to use. That way the texture doesn't have to be retrieved from the database or manipulated by the code in any way, we simply take the parameter and use it. I would have to include checks for invalid inputs, and ideally I would make it so that the texture and helmtexture parameters would be optional in the command input and only used if provided, but that shouldn't be too hard. The downside is that players would have to provide the texture and helmtexture parameters every time they spawn their bot if they want a non-standard race with a non-default texture, but since they can always write a social macro for the #bot spawn call, that shouldn't be an issue, and it would also allow them to change the texture of the bot if they get bored, without having to create a new bot. So I think I'll try that next.
If anyone has any other suggestions for something I could try, then I'd certainly like to hear it
Thanks,
Drake Phoenix