Epic EMU did some work on pets zoning, can look what they did here:

https://github.com/epicemu/Server/bl...oning.cpp#L329

Thank you!

I've used <SetPet(0);> as kinda my mulligan. (I've had a few)

Trying to learn some other ways but...

I think I figured the pet rules to work as they should. It took way too long to figure out but, I learned a bit more about the system.

Everything appears to work although client crashed twice during testing. I logged into the emu well over a dozen times.

I am unsure if these rules will trump suspended minion AA. I will need to test that another time.

I put a couple very simple lines into two places and reverted everything I did previous.

The first occurs within the <deletenorent> code. I searched this area when I originally tried to do this a day or two ago but, was unsure of code to put in. It was also suggested by Uleat.

The following was put in just before what appears to send the client to the new coords, when zoning. This was a little more tricky because I didn't know how the zoning process worked. I ended up turning on all the logsys features to sleuth it out. Rencro made mention of this although at the time, I couldn't make sense of it.

If this could be improved, please let me know.

Thanks for your help.

I would probably move your 'log persistence' check to here: https://github.com/EQEmu/Server/blob...cket.cpp#L1628

.. you could even make the database.LoadPetsInfo(this) call an else clause of the con check (PetLogPersistence == true)

I'm not 100% sure..but, that may clear up your client crashes too. (Looks like the profile packet was already sent to the client - with pet info - and you
were deleting the pet on the server afterwards.)

Mixing system methodologies can lead to issues down the road if you need to make changes, or if changes are made, to a code section.


The 'zone persistence' is probably ok (didn't look at the actual location) .. but, consider what you want to default behavior to be in case of a server crash, client ld, etc...

(Some) players will find a way to manipulate your best thought plans..even accidental actions can lead to exploitable discoveries.

Yes, the pets actually show up on the UI for a fraction of a second after logging in. I have been watching what happens in the DB the entire time and...

...seems to be true, for the log part.

The zone part deletes the entry immediately.

I will make it better. It's not exactly how I want even though it functions.

I'll check this out a little later, let it sit for a bit.

Thanks for your help.

EDIT: I tried as many variations as there are in that exact location you recommended Uleat. Although, I did not try anything after moving the bit to \zoning.cpp. I think I've let it sit long enough.

I reverted the bit in \client_process.cpp.

I could use a bit of assistance with something most would consider basic.

I need to insert something that checks the no rent code.

This is as far as I got:
This is some of the no rent code:
More than hints please.

Thanks

I'm not seeing the end goal clearly defined...

You're wanting to check a client's norent items inside of a load pets function?

Looks like he's wanting pets to poof like No Rent items. By the code snippet above, it looks like the best thing would be to move the "if PetLogPersistance==false { SetPet(0); }" bit to just after the "RemoveNoRent(false);" line within the "if (deletenorent) { }" block.

Thanks for the replies.

Ah, I was thinking of going back to that. Thank you.

There are some basic understandings I am missing. Hopefully I'll get it soon and more will open up.

Ok.

I added a rule check <\zone\client_packet.cpp(1677)>
...and reverted this section <\zone\client_process.cpp(844)>

As far as client crash from previous, I am uncertain what was causing it but, the wireless connection it had previous was not good. Getting to login server was difficult. I fixed that and logged a character with a pet (+30 minutes). I did not see the pet window but the pet was still an entry in the DB, like previous.

I will review what you said about this Uleat.

Thanks

EDIT: something isn't right with the norent check - I'll check back but, I've had enough for now

SetPet() is an inherited function from the class Mob: https://github.com/EQEmu/Server/blob.../pets.cpp#L542

SetPet(0), when called from the Client class, is essentially doing this:
There are no Client class-based methods performed at this level and all that is occurring is that you're setting the memory reference for the client's pet to nullptr.

This is ok for other mob-derived classes that don't save their pet buffs, inventories, etc... (they still clean-up as required, though)

But, for client, you should to handle it somewhere at the Client class level..meaning database clean-up, and deletion of any possible pet instances from memory..otherwise,
you will end up with a memory leak (allocated..but, no longer used memory that is not released back to the system - the losses add up)

(If you handle the action before creating an actual in-memory reference, then you won't need to worry about the clean-up.)

I appreciate the explanations. I wouldn't have known if you didn't say anything about it. I will digest this in the coming days and try to apply this if I can.

I reverted everything that was working with PetLogPersistence. The issue previous was simple and something I overlooked as I quickly wrote it in as I was out the door.

I went back to \zone\client_process.cpp and added queries to the code.

The results are a little better. The entries are deleted until zoning or casting a new pet when new ones are made. I attempted to add database.SavePetInfo(this); <void ZoneDatabase::SavePetInfo(Client *client)> but the result wasn't desireable. (because of <PetInfo *petinfo = nullptr;> happening first maybe?)

The pet window still appears for a short time and the pet=0 entries are non-existent for the char logged 30+ minutes after initial login. (/q resets the entries - unsure if this = LD)


If I knew how to set these queries up in zonedb.cpp and make the connections to it from client_process, I would have. This really isn't that difficult, the concept, the web of connections. It's the syntax or C++ grammar that is the pain in the ass, the huge hindrance for me. I can figure out how the EQEmu system works just by exposure and asking questions where the answer is fairly simple, as has been mentioned.

Thanks

I wanted to see if there was an existing method to 'delete' pets from clients..but, the only one I found only deleted the inventories and buffs..so, I'm not sure where that
is handled...

(I mean, when a pet dies, it is deleted, right? Otherwise, it would respawn when a client enters the world.)

Is there just a Pet->Death()? lol

Well, I followed case GETLOST: back, and SavePetInfo() .. nothing I saw removed the actual pet instance.

I dunno? :P


I know I'm missing something...

There is a depop in \spawn2.h and \spawn2.cpp:

I saw this while sifting through potential options.

There is different depop for zone.

A bit of progress, not much though.

No entry being created like it does when zoning and using <SetPet(0);>

\zonedb.cpp - last 1/2 commented out, unsure what to do to make it create a new blank entry

When the part /* */ is uncommented it only removes `spell_id` in the DB - pet_struct maybe?
\client_process.cpp
Thanks

Added to \client_process.cpp - it's a little smoother, adds the blank row and saves it. The client still shows the pet window momentarily. I would prefer to put <memset(&m_petinfo, 0, sizeof(struct PetInfo));> in the DeletePetInfo part and then run w/e queries are needed to fill in the blanks allowing the removal of <database.SavePetInfo(this);> below.

I would prefer this whole process done a little earlier. Just a guess but, somewhere near <case ServerOP_SyncWorldTime:> (\zone\worldserver.cpp(744).

This also leaves out what Uleat said before about memory loss? which I have no clue about.

\client_process.cpp(841)

Last one for a bit:

The two lines below SetPet, <Mob* mypet =......etc.>, gives the same resulting appearance as <SetPet(0);>. (takes a moment to depop) I am unsure if one is better than the other.

\client_process.cpp(841)

A little more progress on the pet thing.

The entire delete/save process (creating a new blank entry in table `character_pet_info`) for the DB in one spot. This eliminates running a couple unneeded queries from using the <SavePetInfo> function.

The pet window still appears on client. I don't know if this is avoidable by doing the norent check somewhere earlier in the process. It's not a big deal unless there is a cleaner/more efficient way to do this.

\client_process.cpp
\zonedb.cpp
As an aside: While going through this process I noticed some queries are ran anywhere between 2-6 times from this maybe? <database.QueryDatabase(query);>

I understand my tinkering may have caused some of this but, I'm curious to know the purpose of this.

Thanks

EDIT:

Not sure if I mentioned this before. I had to add the line below when I created the item in \zonedb.cpp. Can't take it for granted.

\zonedb.h

Good day.

I created a rule to force training of certain melee skills. The intention is to only force training if the skill is acquired after level 1.

For Riposte below,

\zone\attack.cpp(412)
I'm concerned about what will happen when the rule is true and the character does not have <SkillRiposte>. Do I need some kind of escape from this if it goes beyond <else if>? There is quite a bit more code after what is quoted above.

This question applies to several similar issues I had concern about.

Thanks

If there's nothing left to process in the function after your 'else if' and the exclusion can be caught with an 'else' or another 'else if' statement, you can simply handle it with a 'return' statement.

Otherwise, you might consider putting your post-con check code inside of a single con check that meets all of the requirements for that code to be processed.

Thank you sir.

I understand this.

I'm a little fuzzy on this.

I can't find it but I thought I saw an instance where <else> was used with nothing between { } except spaces.

EDIT: Here but this may not apply to my issue.

Just wasted code space..though it may be there, with a remark, to indicate what is happening to arrive there or an area for future implementations.

The compiler will probably optimize out that particular else clause since there is nothing being processed.

Gotcha, thanks.

I've tried a different approach with no success, so I try here:

I'm trying to come up with a script which, I hope, will summon a corpse using the necro spell, id = 3 (summon corpse).

I've looked at the Dragons of Norrath and the guild lobby quests and they will no do what I want them to do. I want to summon a corpse with the same behavior as the NEC spell "summon corpse".

Everything appears to work except self targeting. Since the npc is targeted at the end of the script and the spell is self (player) cast, the text stating "Your target must be a group member for this spell." appears. I've also tried to change the actual spell effect code.

Below is what I have so far with <location of target code> to indicate where I think it should belong.


If anyone knows how to accomplish what I am trying to do, please share.

Thanks

I do not even know why I am trying to help you at this point, but whatever.

You never explained WHY the guild summoner scripts could not be modified to do what you want. I mean they summon all of the players corpses. How does that not work?

I'm sorry if I hurt you, provocating. I can tell you for certain, I do not feel the same way. Grudges aren't healthy.

If I knew how to alter <EVENT_SUMMON();> to only work in specific zones or with specific corpses, I would not be asking the question.

Maybe it's clarification I need. I don't have much knowledge of scripts and this is why I asked the question to begin with, hoping, someone could clarify this.

$client->SetTarget($client);

That's all that was needed in the .pl file.

Thanks

PS. Could use a writer.

Feel free to try this have no idea where npc location or for what zone i had no way to test this perl script.

a_dungeon_necromancer.pl

Thank you Noport.

I added a mechanic to <channelchance> and am wondering if it looks right or if it could be done better. It may be a little confusing but the purpose was learning as much as adding this code. It's an exercise in futility trying to channel at lower levels and the added mechanic mitigates this a bit. It also reinforces those who practice skills when they level, like the old days.

Also, the <distance_moved> and <distancemod> formulas do not do as advertised. The idea seems proper but the implementation is off. I will add to this my results when I get to it.

The big thing I am wondering is if the code in the header is returning the value for the previous level max skill. This mechanic seems to work upon initial testing.

\zone\client.h(695)
\zone\spells.cpp(1105) - <void Mob::CastedSpellFinished>
Thanks

EDIT: here is a visualization of the behavior http://prnt.sc/8s311y

The blue line is the current, unadjusted channelchance. The lower red function is the formula I added. The upper red function is max skill channelchance after adding the the formula.

I think I misinterpreted this. Disregard.