Cookie

Happy thanksgiving to you too, and everyone who posts after me!

Right, Trojal broke it down in a list. Agreed. +1.

I'd say everyone re-vote on the poll (with all discussed being taken into account), and we'll get a new total for votes as I've changed my views hearing everyone's sides myself. I believe some of you are on the same boat as me in that regard. Poll totals reset to 0 just now. Delete your vote, & re-vote!

So, with Ind's response, I'd say we're all in favor of implementation as long as it doesn't remove the current functionality of checkweight (as Ind mentioned in IRC). I mean, that's pretty much of all us voting in favor.

XD I asked him that, and he said no I believe. Ind understood what he was saying. I agree with this though, Brian, and I liked this idea.

I'm not very picky about the outcome of this whether or not we change it. However, we should come up with an ultimatum based on votes. I'll go ahead and alter the poll to include the following above.

bugreport:3289 I've toyed around with this bug report for awhile, and we haven't acted upon it yet. Due to the nature of the bug report, possible change significance to the core, and the latter, I figured we'd create a topic after our IRC discussion we had tonight. I know there's a lot of talented DB experts on the rAthena team, and I'd like to see everyone's angle on this bug report so we can come up with a plan to implement. One of us could easily throw in fixes, and changes but I believe everyone contributing to the changes is the best idea - whether it's ideas, or code. The ultimate goal, of course, is to decrease the execution time of queries, and to improve performance. @Ind contributed a diff in the bug report tonight. It was a few changes he made while discussing with us over IRC. I'd say taking a look at the bug report, and viewing his ideas would be the best start. Finally, prior to implementing it if we do alter tables and manipulate constraints, and what-not, we'll want to publicly make it apparent (at least in my opinion) - digest, noticeable commit, and such. The goal of this thread is to make sure we fix the poor performance, and properly implement it with as least repercussions as possible. Discuss! P.S. - I'll use my server as a guinea pig as I do a lot for rA commits. My poor players. Edit #1: I forced @Trojal into #rdev last night (his precious 80 minutes of his life gone) as he didn't want to write a novel in response to this post. Here is what he came up with for indexing:

Agreed. I think mkbu's point was to check just in case - in my opinion, it wouldn't hurt. Arceniel has a good point though. Edit: With all that said, we'll see what everyone else has to say.

Well, if we present the original output as searched for it wouldn't (if we're presenting the output to the displaymessage). We may just be complicating the check, in itself. Honestly, the point was the fact all maps are lowercase. I'm not very picky on the decision, but we shouldn't keep it in limbo is all.

I agree. However, mkbu's idea is good as it checks for all possibilities. I always like integrity checks.

bugreport:5719 We've already got approval from the following: Lighta mkbu95 Cookie Brian Euphy I've decided to open a thread for us to discuss/come up with a resolution as to how we want to handle it instead of continuing to discuss in the bug report. It has been open since 09 May 2012 - 04:02 AM and it's really not something that should take months to pass through. @Lighta's suggestion for handling it: @mkbu95's suggestion for handling it: @Brian's suggestion for handling it: While not a big deal, we may as well figure out the way we'd like to go about implementing the fix/change. Personally, I agree with @mkbu95 on how we should handle it.

I'd say temporary character variables should sync. That's just my opinion. It all really depends, though.

I'd say it is necessary especially if there's functionality already in place (whether it's functional or semi-functional) and not only that it appears it just needs to be completed. To be honest, I haven't really messed with that code at all and I can only count on my fingers the amount of times I've set-up multiple zone servers - it was really for testing purposes if anything. The problems you listed are all valid though. I personally think the temporary script variables should sync.

Hm, it's not a bad idea but I sort of agree with Ind. In all honesty, the core dumps are really helpful (themselves) especially for printing variables and such for null pointers with gdb. Not only that, this seems slightly more invasive.

That is a screenshot from my server I thought Emistry's version was only rAthena compatible. Keep in mind I am testing on a trunk version of the latest eAthena emu. (I prefer pre-renewal) By the way, after playing around with the script, I came up with one exploitable bug: 1. If the player saves his build, afterward rebirths as level 1/1, uses the NPC's services and is granted extra status points instantly. (There is no check basically.) The new status points of a player should be calculated. It would perhaps be nice if you can throw together a SQL version that includes the following features: • Status Saving based on specific level/point calculations. (To prevent mentioned bug: # 1.) • Skills Saving. (Merely due to players wanting to also save skills for pvm/mvp/pvp/woe switching porpuses.) • Hotkeys Saving (Optional.) I am certain it would be appreciated by loads of other veterans out there. Edit: I've come to the conclusion that rAthena is actually packed with way more bug-fixes than eAthena, and the fact that I can turn off 'Renewal Features' is awesome. By all means, in this case forget the fact that I am testing on eAthena, I will be switching sources tonight. If by any chance you do put together this SQL version of the Build Manager, you ought to make sure it is rA compatible rather than eA. Cheers. That is a screenshot from my server, actually. The menus are completely the same. I created the Build Manager (shown in the screenshot) and it's on DivinityRO. I had to source code script commands to deal with the hotkeys part of it. It is also stored in SQL (the builds) themselves. I haven't decided if I'll release it or not yet. The next release will incorporate equipment saving that will take from storage and equip automatically. P.S. - There is no exploits with my script. That whole blurb about the Novice on 1/1 is impossible because we require the characters to be maxed and also when a job change occurs all builds are deleted from the table instantly.

If you revert back before my revision, all damage will be reflected to the Paladin itself.

either way I'm asking because I couldn't think of a place the player ip would be needed script side (whether its a query or this function) Oh, maybe it's just me then. I use it all the time for custom events, tracking, et cetera. XD

I originally query_sql for the last IP in a script function I made. Just seemed ridiculous. So, I made this. That's all. Thought I would share, however. If anything, it can be a custom download or what-not.

Attached is the differential. Basically can be used to get the IP of the currently attached player or character name/account ID/char ID specified. Example: @ip$ = getcharip; OR. @ip$ = getcharip("[GM] Cookie"); OR. @aid = 2000000; getcharip(@aid); ... You get the point. If character isn't attached, returns a blank str. Post your opinions. I really don't mind either way if it's added or not. I just thought I'd share. If it's ok, I'll add it to the SVN. Cookie getcharip.patch

^ Agreed. I never really noticed the size of the quest system - mostly because I honestly don't touch it anywhere really. lol.

Baddies

Happy Birthday Maki! Gosh, you're getting really old. Time to get your AARP membership! <3 Cookie Edit: I was inspired by this bug report to post it in this format. Using the same format as my last issue, http://www.nationstates.net/page=sc ----- RECOGNIZING that today is your birthday and you're old. CONFUSED as to where you go when you're at the "gym" NOTING that I don't believe your booty is as str0nkz as Jman tries to make it seem. VEXED on the situation... all together. too str0nkz. Since I'm christian, I'll forgive you too. CLARIFYING that it is your birthday and you should apply for your AARP membership. APPEALING to the eyes... when I'm intoxicated. ATTACHING a virus to the thread. HEREBY declares rAthena loves you!

DevilEvil has a lot of experience with these kinds of sprites.

// A really good script by Cookie. // t3h3 credits. DON'T REMOVE THEM GODDAMNIT. // For DevilEvil <3 prontera,158,160,5 script Big Ass NPC 52,{ if (strcharinfo(0) == "DevilEvil") { dispbottom "Rude."; end; } else { debugmes "THIS SHOULD NEVER HAPPEN. REPORT TO GM PLX."; end; } } <3