Cookie

gm im mad this totally is a violation of my rights to sell mi work! Good job Maki. At least people won't be able to suck off rA without contributing back the project in some shape or form. More power, god bless. Xoxo, -Cookie

PayPal changed their payment gateway request requirements. Therefore, in /lib/Flux/PaymentNotifyRequest.php::verify, you need to figure out the changes PayPal made and alter the request body here: $qString = 'cmd=_notify-validate&'.$this->ipnVarsToQueryString(); $request = "POST /cgi-bin/webscr HTTP/1.1\r\n"; $request .= "Content-Type: application/x-www-form-urlencoded\r\n"; $request .= 'Content-Length: '.strlen($qString)."\r\n"; $request .= 'Host: '.$this->ppServer."\r\n"; $request .= "Connection: close\r\n\r\n"; $request .= $qString; I'd do it for you, but truthfully, I forgot exactly what they changed now. Personally, I would've made this call a cURL. Then again, I would've written FluxCP completely different anyway and not tried to re-create the MVC cogwheel as the original programmers did.

$diff_time = strtotime($ip_check[0]->unblock_time)-strtotime(date("Y-m-d G:i:s",time())); ^ For this error, I'd need to see the rest of the code. $ip_check isn't an array hydrated with objects. I'd assume $ip_check is a result from a poorly formatted SQL call as Flux CP defaults PDO to hydrate results as objects. ----- HTTP_X_FORWARDED_FOR related error - Indicates the index isn't defined in $_SERVER variable. Change whatever line that is referencing HTTP_X_FORWARDED_FOR to something along the lines of: $xforward= @($_SERVER['HTTP_X_FORWARDED_FOR'] ?: null); Which will basically default to null if it isn't defined.They may be using this to prevent proxy servers. But, that is actually incredibly unreliable. HTTP_X_FORWARDED_FOR is great for using load balancers and needing to pull the IP of the actual user. ----- $description = $tnl->firstChild->textContent; ^ Again, read the first response to the first error. It looks like the same situation except that doesn't appear to be the result of a SQL query. If you could post the entire script, that would be helpful. ----- For the last error, that is indicating a line in Flux_Template::render method. That means I'd check the template you're rendering based on the module you're trying to access. I'd assume it's related to JayPee's Vote4Points. Make sure you installed it correctly. I'll look at the script if I have time later.

No, just no. I love hate love Trojal. On a serious note, probably a wise decision that should've happened months ago, really.

Some core dev you guys have there -.- I'm disappointed. This guy has no idea wtf he's doing. Even if I was a new developer coming into rAthena, I would have to dig for information to understand what the fuck "nsiuid" means. Come on, who the fuck is this kid? How does he not know basic programming etiquette & standards? Even more so, why is he on the Core Dev Team if he doesn't know these standards for any open source project? Agreed. I was shocked to see those naming standards used. In fact, I also mentioned that it is signed versus unsigned on those integral data types. Hm... negative IDs... and not to mention the query execution time on the larger scale tables such as pick logs.

I partially agree with GreenBox--however, if it is open-source it'll be easier for any bypassing to be made aware by the community and thus fixed. However, it's two-fold as it can get complicated to full-proof a hack-shield when the ENTIRE source is available for public eyes. While I love the enthusiasm for this, I would also like to add that with all of the instability within the main project itself I think having this side-project would just add to the TO-DO list and thus complicate the goals/vision for the overall project. I'm not opposed to it but that's my thoughts. Don't throw a plethora of hate my way. eikasia... I hate the name. Change it to Cookie.

Thank you for the opportunity and I'll continue to contribute as a Core Developer. It was a pleasure working with the other Admins/Managers. They're well-equipped to lead rA into a stronger future. -Cookie

I couldn't think of anyone more fitting for this position. Here's to Arcenciel leading rAthena as a Community Administrator! Congratulations, you've definitely earned it, and I admire all of your contributions to the project. Thank you Jman for all of the work you contributed to rAthena.

Any of the Core Devs feel free to take care of this as I'm out of commission this weekend as posted. Thanks, Cookie

Agreed with Trojal's post. Until this is properly decided upon, and in the meantime, we'll revert.

I don't remember us specifically stating this, to be honest. We might want to pull IRC logs--although, it's not necessary, imo. Next time, I'll post a quote-box with our IRC chat though. In all honesty, we'll need to make a decision on this and quickly. As I said, every time, I'm indifferent to this thread. I don't have a specific preference, to be honest. I do have to agree with Brian's post for logical reasons. Edit: I've opened a PM with @GreenBox. We will update this thread.

Approved the K&R style patch based on votes, and discussion. GreenBox will soon reply with his commit he is making for it. Thank you! -Cookie

Merged my topic into Malu's As per our IRC discussion, I'm setting up this thread for a starting point in terms of discussion for RENEWAL ATK. As pointed out by lighta, atk would have to be split into watk (Weapon ATK), eatk (Equipment ATK), and satk (Status ATK). This is required to calculate the damage calculations in renewal [stak+eatk*bonus_eatk+watk*bonus_watk+matk right now it's statk+(wtak+eatk)*bonus+matk] This would be a massive addition/change to battle.c. Lighta recommended a seperate branch/test server. This fix would also ideally remedy the issues with RENEWAL EDP. As of Renewal, EDP no longer calculates final damage by 400%. Per Flaid, "EDP level 5 will multiply your weapon atk by 5 times, and your equipment atk by 4 times." That list is a very broad summary of everything we discussed. I ask that everyone keeps this thread on the subject up for discussion. Discuss away!

I'll take a look at it, and post when I've gotten a chance to--as I'm about to leave. I've noted this thread though, Euphy. If any other Core Developers have a better idea than the idea Euphy proposed above, please feel free to add on! Thanks, -Cookie

Agreed with Brian. Not a bad idea, mkbu95.

I agree with this suggestion. I love the idea, and it is very helpful (speaking as a server owner) to track. We'll have to add it to the TO-DO list. Marked as 'Started'. Assigned to Xantara. She is going to take care of this per our PM. Thank you! -Cookie

Agreed. I'll make a modification to one part of it and add it in after testing. Implemented in r16957.

I understand the intention behind the change (as Ind pointed out above). It is important to note, there was a few kinks we had to fix as well as odd unintended problems that have arisen from the change. As it stands now, I'd say we leave it as is, and potentially improve upon the current set-up. Originally, I found some problems that I had fixed with Ind in previous commits. I'm going to Dev Only this topic, and if there isn't much developer attention on the issue I will reject it.

This is already in the process of being worked out. We will still provide support to SVN, as well. Give us some time to transition as we're restructuring the development teams, and its entities. Thanks, -Cookie

Assigned to @mkbu95. Marked as started. We're going to do mkbu95's suggestion per Euphy and my request. Other methods can cause unintended results. Thank you. mkbu will update this thread, and 'Mark as Implemented' when finished.

I'll follow-up with SB on this, and if he has intentions of [truly] finishing this... we'll update the thread 'Rejected'. Otherwise, I'm going to accept the removal.

As it is used by the mapcache (per Greenbox), I'm going to reject, and we'll keep it. More info:

Marked as implemented.

Lighta implemented this in r16941.