KirieZ

Hello, I think you have uploaded the wrong file here it is a card collector.txt, not endless tower. On a side note, doing this change in setunitdata: case UDT_DMOTION: //setunitdata_check_bounds(4, 0, USHRT_MAX); <---comment out then add setunitdata_check_min(4, 0); break; is not increasing the limit. You just disabled the safety check and is letting the compiler set whatever value it wants (there is a logic to what is setting but this is a bit level and I don't know 100% how to expain/whether it is consistent on all compilers). These variables are not big enough to support values higher than ~65000 (USHRT_MAX). It doesn't error out because the code is doing a cast, and it will simply ignore part of the value and go ahead with whatever the casting resolves to. (Which will be between 0 and ~65000). From an online compiler, 96,000 will actually become 30,464 and 120,000 will actually be 54,464. Try doing a getunitdata after you set it and you will see the real value. To go over 65k at least the variables needs to be changed from short to int, I am not sure if this would be enough or this would cause issues in other parts, but unless this is done, you can't set a value higher than 65k (and that's why you see this error in vanilla herc)

I've never done it and this answer may not be totally accurate... But I think the following is what you need to keep in mind: 1. NEMO probably won't be able to patch it, you will have to do by hand 2. The hardest part is not using the client, but usually each official server uses a different combination of packets. For example, if packet A was added in kRO in 2015, and packet B in 2016. For another server it may be the case that packet B was added in 2020 and packet A never came. Thus, relying in PACKETVER config will most of the time not work. So you will certainly need knowledge on how to customize packets read/sent by herc -- specailly clif.c and related packet structures (and their counterparts in char/login server) PEEK or BPE (Links to their topics below) may help you find the list of packets currently defined for the client. I did not test BPE for that, but I do remember PEEK being able to extract packet length table -- which would include the packet ID too. For packet structures (if any of them changed for any reason -- should not be the case, usually only versions change) that will be harder. If you need a different structure, I think you have 2 options: 1. Reverse engineer the client and find where it sends the packet you need with some reverse engineering tool (IDA, Ghidra, etc) 2. Capture the packet and find the data by trial and error and guessing -- A good amount of guessing is needed here, and you may get some thing wrong I am not sure if I can give much more info than that. But I guess it is better than nothing If you are really going this route, do know that it is some quite advanced stuff with barely any public info

Yes, you are right about the cause. Your case seems to be causing a similar effect of a server crash, when it gets terminated in an abnormal situation. I am not sure if there is really something that can be done in this case... while you could create a script command to force saving the character data for this case, you would still have it open for others. I think the best option would be to: 1. When doing a production server normal shutdown, always do it properly. Kick all players (even better: do something to prevent them from logging back in) and wait some time (I think ~5 minutes would be more than enough). I think if map server is shut down separately first, it will send all data to char, but this is something that would need to be done manually 2. If there was a server crash, which could cause those dupes, you probably need to either review your logs of the last few minutes and check if actions are needed, or rollback to a recent backup if you think it would be safer

Most likely your db is too new for your code. Try copying this commit: https://github.com/HerculesWS/Hercules/commit/bb5064f4f8e63364ddc8cb7523ebc3a7def905ed

The error is due to the main NPC not being in a map. As it is not in a map, Herc most likely didn't initialize unit data for it (since it would be useless). Either put it in a map or add a check to not apply unitdata for it. Here is how to do the 2nd option: OnInit: if (strnpcinfo(NPC_MAP) == "") // Not in a map, can't set view data end; setunitdata(getnpcid(), UDT_GROUP, 1); setunittitle(getnpcid(), "Goddess Statue"); end;

That's weird... cvc was implemented together with the clan system, not having cvc would mean you don't have the clan system too. I do recommend updating though, since it is there since 2017. But here is the PR that introduced it: https://github.com/HerculesWS/Hercules/pull/1718

This seems somewhat undocumented, but there is a "cvc" mapflag that should make a clan vs clan. https://github.com/HerculesWS/Hercules/blob/stable/src/map/map.c#L5428 does that work for you? or there is a specific reason why you need to use gvg?

what if you simply use "getnpcid()" without the NPC name? or use the full name. I am assuming your duplicates have a hidden or unique name added to them, so this getnpcid is not picking it and all of them are targeting the main one. Try to either use just "getnpcid()" (which should target the current NPC), or if this doesn't work, use strnpcinfo to get the full name instead of the display name

How are you setting the title/group for the first one? OnInit should be called in every duplicate, so you could just use it to set the title/group

Is that from rA? does areamonster there sets this variable? this does not happen in herc: https://github.com/HerculesWS/Hercules/blob/stable/doc/script_commands.txt#L695 Ah, the answer went up and I didn't saw it 😅 Glad you got it working

I am not sure what exactly is wrong, but as far as I can tell, this code doesn't make much sense... I have only skimmed through the initial part, but: $@mobid is an empty array, and is being copied into .@GID (Thus, .@GID would be an array too?), but then .@GID is passed to getunitdata, which doesn't expect an array... and getunitdata result is not used at all.. So I am really not sure what it is trying to do

I think your options are: 1. Recreate the script command in herc, shouldn't be that hard, I believe this info is available, just need to make a script command to get it 2. Save a dynamic global variable using the instance ID as suffix using setd between instance_create and instance_init. Once the instance starts, you can copy the value from the global variable into an instance variable. Something like that: // create instance .@instanceId = instance_create(...) // Make global var setd(sprintf("$@instance_type_%d", .@instanceId), 1 /* whatever you need to store */); // Init it instance_init(...) // ------ // This is called on instance_init OnInstanceInit: .@varName$ = sprintf("$@instance_type_%d", instance_id()); 'instanceType = getd(.@varName$); setd(.@varName$, 0); // Clean up so you don't mess up future id reuses end; References: - OnInstanceInit: https://github.com/HerculesWS/Hercules/blob/stable/doc/script_commands.txt#L1151 - instance_create: https://github.com/HerculesWS/Hercules/blob/stable/doc/script_commands.txt#L9730 - instance_init: https://github.com/HerculesWS/Hercules/blob/stable/doc/script_commands.txt#L9793

message expects 2 parameters: https://github.com/HerculesWS/Hercules/blob/stable/doc/script_commands.txt#L4810 parameters should be separated by "," looks like your script has a ";" instead. so just change to "," messsage strcharinfo(0), ".... Note: best-practices/standards would also suggest using () around script commands, e.g. message(....) and use constants instead of magic numbers where possible (strcharinfo(PC_NAME) instead of strcharinfo(0))

I can't give much details, but will give you some ideas: Most likely you have changed the part that sends the data from server to client, (clif->something), but once the player clicks something in the client, client tells the server the items it is buying, and server needs to process it. At that time, the code are probably still looking for cash. So it is like you are telling a lie to the client saying it they have N amount of cash (where N is Zeny) but once it tries to pay you go "hmm you don't have all that money -- because you are now looking for their cash" The communication from client to server also starts at clif.c, but those will be in clif->ParseXXX functions. You are probably missing this part. If you can't find which parse function is being used just by looking at their names, you can use packetlogger plugin (see staff plugins repo in hercules org) to log the packets coming and from their ID you can get to the right parse function. Hope this helps

I don't know the details about anaconda's pack, but eden group is only available in Renewal. Is your server running in Renewal mode? "hercules_pre" gives a feeling about being pre-renewal, but again, I am not sure about how this pack works.