Jump to content

martooth

Members
  • Posts

    19
  • Joined

  • Last visited

Profile Information

  • Gender
    Male

Recent Profile Visitors

2522 profile views

martooth's Achievements

Poring

Poring (1/15)

2

Reputation

1

Community Answers

  1. Hello everybody. I've been working on a FluxCP plugin that will integrate a forum and chat system directly into the control panel. I was going to just develop it for my own website but i figured others might be interested in this. It is still in its infant stages at the moment but I thought it might be beneficial to get some feedback from others who have been looking for this as well. Planned Features: Basic forum. Full integration with FluxCP. Sorting options, default will be most upvoted. (sort of reddit like) User's posts will show up as a selected ingame character. User's preferences, such as picking which character your posts and chats will show up as, etc. Full customization from an admin panel including heading labels, moderators, blocks, etc. Chat feature, that also uses the users in game characters to chat with. I have a demo site up http://chatter.infiniro.com. Please feel free to leave some feedback if your interested in such a plugin, what you think it would worth, what you would like to see as features, etc.
  2. Ok so the problem is here in flux's root/lib/flux/PaymentNotifyRequest.php while (!feof($fp)) { $line = trim(fgets($fp)); } // Close connection. fclose($fp); // Check verification status of the notify request. if (strtoupper($line) == 'VERIFIED') { $this->logPayPal('Notification verified. (recv: VERIFIED)'); $this->txnIsValid = true; return true; } else { $this->logPayPal('Notification failed to verify. (recv: %s)', strtoupper($line)); return false; } The first while statement that is setup to read the last line in the paypal response. for "VERIFIED". This used to work but for me paypal's response's last line is now blank and the "VERIFIED" line is now the second last line. I'm not gonna recommend a code change to fix this due to possible security issues a change might create, but basically one would just need to modify the code so that it checks the second last line or just checks for a VERIFIED on any line from the paypal response.
  3. I have resolved this if anybody else is still having this exact issue.
  4. I'm getting the same issue here now too, just started happening this year. I just tried a fresh newest version of Xantara's Flux but it didn't help, anybody have any idea. [2014-02-15 19:47:28] Establishing connection to PayPal server at www.paypal.com:80... [2014-02-15 19:47:28] Connected. Sending request back to PayPal... [2014-02-15 19:47:28] Sent 1195 bytes of transaction data. Request size: 1340 bytes. [2014-02-15 19:47:28] Reading back response from PayPal... [2014-02-15 19:47:29] Notification failed to verify. (recv: ) [2014-02-15 19:47:29] Transaction invalid, aborting. Thats what my paypal.log.php is reading.
  5. I'm getting the same issue here with Flux aswell. Donations have worked fine for a year now and randomly they no longer work this year (which i just thought now maybe it is a year thing). The payments are going through fine but flux is getting a not verified from paypal for some reason. Anybody else having the same issue or have this resolved by chance?
  6. Hey everybody, Our great rAthena overlords have blessed us with the new Rebellion weapon vendors in Prontera however my iteminfo.lua (2013-08-07 client)(which comes from the newest revision of the client translation here https://subversion.assembla.com/svn/client-side-translation/) has none of the data needed to actually use these items so i was curious if anybody has knowledge of anybody with these items translated in there iteminfo.lua and if i could get a copy of said iteminfo.lua
  7. ragexe 2013-08-07 is 100% stable with the latest version of rAthena. Denien1 - That issue typically stems from your clientinfo.xml in your data folder on your client. You must set the packet version to 45, however that looks like the root user for your server not a user that would even be using a client. Somebody might have more information for you. but if your connecting with a client using that account then make sure to set your version to 45 in your data/clientinfo.xml
  8. Well either method will work, you just need to commit your current changes, git pull to the newest version, recompile, update your sql if your using sql and that should do it. To get the newest version of rAthena.
  9. Well all of the client exe stuff you need can be found in this post http://rathena.org/board/topic/82726-2013-ragexe-and-diff-up-to-date-2013-08-07 from the exe file, the differ, the diff files, the modifications to the mmo.h in the emulator core the clientinfo.xml, which should be packet ver 45 for the newest emulator version. You will need to download the newest version of rAthena using the Github, and you'll need the version 4.0 of the complete basic data folder here http://rathena.org/board/topic/66962-basic-complete-renewal-data-english-folder/ Just follow the sorta instructions in that first link and you should be ok, if you have any question just ask, its the same setup im using, once thats all done we can rule out client-server versions as an issue:) lol
  10. Yeah the error messages with these not connect issue its awful (probably because the emulator hasn't a clue theres even a problem). Did you try commenting our your login_ip setting in your char_athena? Also you made me recall another similar issue i had was a client issue, i didn't diff it with....."Disable Packet Encryption", and do not use "Use SSO Login Packet", "Packet First Key Encryption", "Packet Second Key Encryption". Now that being said these are diffs for a 2013-08-07, which is one im using, you may have better luck with a 2012-04-10, which is rAthena supported 2012 client, if your doing renewal however 2013-08-07 is 100% stable and supported. I normally just play with stuff until something else break or something gets fixed. (breaking stuff usually leads to more understanding which leads to fixes). There is just too many possible problems that have this same symptom. I didn't see anything wrong with your setup tho. Oh yes so try commenting out the "login_ip:" option and try uncommenting "//char_ip: 98.165.9.16" and setting to 127.0.0.1, your wan ip, and your internet ip.
  11. Hi there, I've had this issue countless times moving server machines around. It seems really picky about certain network setups and rAthena config settings. Sometimes its quite picky about this setting in your char_athena.conf "char_ip: [your internet ip]", which if your connecting using your actual ip address then it needs to match, if your connecting via localhost (127.0.0.1) then make this 127.0.0.1, there is another option in char_athena.conf "login_ip: 127.0.0.1" i have to leave commented out and have the emulator auto assume 127.0.0.1 to work. Just setting this to 127.0.0.1 does not work for me but used to. Pasting your conf files here (char_athena.conf, login_athena.conf, map_athena.conf and inter_athena.conf) plus a screen of your rAthena starting up might would be helpful if playing with those first suggestions aren't of any help.
  12. I would check if you're using the custom aura diff and whether or not your players are crashing when there is a level 99 or 3rd job max level character around. I can confirm from experience that the custom aura diff does not work and causes normal and custom auras to crash players out, using the 2013-08-07 client.
  13. I sure have. Its so wierd tho, i don't understand where or why its looking for that sprite file. I'd type it out but if you look at the screenshot you understand why thats difficult lol. Ok i have some more information on this, I had the view id in the database wrong. I;ve now matched it up correctly with what it says in my accessoryid.lua, and the error has gone away. However the headgear is still not visible. I've confirmed the sprite files are in the correct location, the headgear is added to the accname.lua and accname_eng.lua but im still getting nothing. Ok and got it all figured out, it does and will not read .lua files for accessoryid, accname and accname_eng, only the .lub files. Thank you to everyone who tried to help and pointing me in the right direction.
  14. Yeah i've tried that, the 2013 clients don't appear to use idnum2resnametable or num2resnametable. or /datainfo/accname.lua lub. anymore, which is what the trouble is, i did have this headgear working correctly using those files with my 2012 client.
  15. That is the error. The code in my iteminfo.lua looks like this... [32712] = { unidentifiedDisplayName = "Custom Helm", unidentifiedResourceName = "30001", unidentifiedDescriptionName = { }, identifiedDisplayName = "Custom Helm", identifiedResourceName = "30001", identifiedDescriptionName = { "Custom Helm Description", "Class :^777777 Headgear^000000", "Defense :^777777 3^000000", "Equipped on :^777777 Upper^000000", "Weight :^777777 90^000000", "Applicable Job :^777777 Every Job^000000" }, slotCount = 1, ClassNum = 0 }, As i said its pointed to the 30001.spr and .act files, which are there and work fine in inventory and when dropped, the problem is when its equipped, it seems to be looking for something completely different. And to address needing an iteminfo.lub file recompiled, i have the client patched to read lua before lubs so as far as i know i do not need to recompile the lub file. These sprites did work fine before i upgraded this client to 2013 using the accname.lua/lubs in the data folder. It just seems i haven't told it which sprite files to use when worn. Any more help would be great, thank you.
×
×
  • Create New...