Think

Your issue is likely to be memory corruption anywhere on the code (that is, not just that file). Roll back all changes until the moment you had this issue and then analyze them carefully or spend a long while tracking what's being done to your items and under which conditions this will end up happenning. Good news is, it crashes every day, so it must be easy to reproduce.

Trigger on kill, and then loop through quest members with something like... local pids = {party.get_member_pids()} for i, pid in next, pids, nil do q.begin_other_pc_block(pid) --stuff with the other player... pc.functions() will act as if it's another char q.end_other_pc_block() end As for the problem with killing in party, party_kill is only triggered for the leader when either the leader or someone on the group kills anything. Some kill trigger with party conditions (but without party flags, is it really intended that progress is shared?) seems about right though.

%%A is not a thing ([Hidden Content]). This will just do (like Denis said), there's no need to complicate it more than it:

I am confused as to how this is supposed to work: - weekend will hold the weekday as number (e.g 6) - day will hold % + weekday's full name (e.g %Saturday) - or simply '%', not quite sure how it's parsed. (ref for what the os.date yields: [Hidden Content]).

return day > 4 or day == 0 greater than 4 and 0 Ahem, 5 and 6 are greater than 4.

so 5, 6 and 0 are valid weekend days. How long do your weekends last? Mine have two days!

You can use this one and modify it for your needs:

Unless someone has specific experience on crashes with those serverfiles or are magicians, without syslog/syserr we're all clueless. If you have core files, you can also try to debug them yourself.

Well, yes, so long it doesn't keep increasing forever You can check your player.item_award table, there you will have all the ids that the database is loading.

That's item_award loading for things not yet associated to an ingame item, completely normal thing.

Did you just change game without changing database?

The quest is just a test, I'm not sure why you'd want to use it (To quickly see if its working, I hope? You can easily extend any other quest to test, though). As for why it doesn't work, I suppose you didn't add the parenthesis after npc.is_pc()

@Rideas your function will forever try to re-equip new arrows each time an arrow is shot, provided only one arrow of type 79503 is equipped. If you want to prevent vnum 79503 from reducing arrows, you are better off with an if(...) return; at the very beginning.

You really shouldn't have more than 3, I think 4 are as many pages you can have without overflowing the datatype.

... no. You don't need to do anything in UseArrow, you don't even need to keep the UseArrow function.

I have no idea what you are trying to say. Are you using Google Translate? Hotkeys are generally keyboard shortcuts ([Hidden Content]) and there's no antiflag against those, nor I see how you'd use seals with hotkeys.

Delete the reference to that, then! That sounds like a half-done removal of the license check.

Well, I would just remove the whole shutdown_manager (unless you have an use for it, which I doubt?). If you don't know how to do that, I'm afraid I can't help you too much, my suggestion is to delete the files, try to compile, and start deleting all no longer existing references that will display as errors in the compilation process.

Seems like you are mixing in things from different branches, unless you made the changes which broke this. Either define gShutdownEnable/gShutdownAge(config), or if it's defined, make sure it's visible to shutdown_manager, or remove all references of them.

Some reading, please o.o idk how you'd screenshot not seeing something? @ontopic, did you make the change on SetPlayerProto before or after this line? thecore_memcpy(m_aiPremiumTimes, t->aiPremiumTimes, sizeof(t->aiPremiumTimes)); It should be afterwards, as it is all unitialized memory otherwise and might or might not work.

Do you have a valid cube.txt file, /cube command is not disabled, and no errors on syserr when you open it?

You will need to tell the client that your quiver has a REAL_TIME flag in its socket and it's not some stone or something like that (which is what is expected on weapons). Edit uiTooltip

The entry map to the dungeon must have the map you are jumping to in its own MAP_ALLOW.

You can't run a select (or a wait) if your quest is set to show up on login. The game will ignore it. If it should show up on login, you can circumvent that with a timer for 3s that then launches whatever you want to run on login.

with this: and your problem on everything that gives damage is solved by now! Unless you added/removed points prior to those, that definitely does not do anything. And if you added/removed points prior to those, then that's not the only thing you should be changing!