Jump to content

kisuka

Script Developers
  • Content Count

    289
  • Joined

  • Last visited

  • Days Won

    28

Everything posted by kisuka

  1. Attached are the client additions / translations for the soon to be released official 2014 halloween event script. The lua files and questid2display.txt need to be merged with your own client files. In this archive they only contain the additions. They will not work if you just drop them into your client as it'll get rid of all the other content, as they weren't included. Server side content will be released into the repo once we get some item bonus figured out for the candies. 2014 Halloween Event - Client Files.rar
  2. We wanted to deleted this folder at eAthena during the old days. Let's please make that dream come true What we could do is instead of deleting the entire folder, we just delete the scripts in it, then drop a .gitkeep inside. That way there's still a structure for people to drop custom scripts in without messing about with the official folder structure.
  3. checkquest deprecated in favor of questprogress in db1abaf. questactive() implemented in 98274e4.
  4. @Zephyr : Not trying to criticize your scripting but why have such a check at all? The script you posted shows that if the player marks the quest as inactive they cannot abandon it, complete it, or get a new one without marking it as active again... that seems like bad user experience / cause for confusion. To limit it to 1 hunting quest at a time it would make more sense to check if a user has any quest 50009 ~ 50036 using checkquest to check for an inprogress quest (remember, inactive/active both count as an active quest. when hunting mobs, if your quest is marked as inactive it will still count the kills), if an quest exists but they didn't complete it then offer them to abandon it. I don't fully understand the purpose of the inactive state in your script. As all it seems to do is cause a user to go through the hassle of re-enabling it, rather than letting the script handle it for them allowing for a more pleasant gaming experience.
  5. Might not be a step, doesnt mean it has no usability: Lets say you wanna make 3 quests, which require you to kill Poring, Poporing and Drops, you can go to Poring island and AoE it all to finish it fast, how about the scripter wants to only allow "active" quest kills to count in an attempt to increase difficulty? If we can provide the function without compromising performance, why not do it? And lets not forget a simple fact, the function is already there, we CANT take it out, its as simple as that, at least not without providing an alternative to mimic the functionality. Anyways, I don't wanna turn this into an ABAB discussion, I guess we both stated our POV. P.S.: Your poll missed a 3rd option to implement an alternative checkquest(0/1) ftw! That would be impossible, because a hunting type quest still counts kills for a quest marked as inactive. Regarding the 'we cant take it out' That's is what deprecation means. checkquest will continue to exist and work as it has forever for a period of x months then it will be removed in favor of the new command.
  6. I'm all for flexibility but in this case I think it's taking it to a point where it's just making it messy. It feels like it's breaking how quest log is meant to be used. Flexibility is fine, as long as you aren't creating logic that doesn't need to be in place, or are breaking how a function in-game is meant to be used. questprogress and checkquest are commands meant to check your current progress of a quest; a quest in inactive/active state has nothing to do with progress; It is not a step in a user's quest history, it's a UI function controlled by the player. The active / inactive state can also not be controlled by the server. There is no command to toggle that state for a player. Adding such a command and using it would also cause for some serious game experience issues for a player, as they wouldn't know a quest had been marked as inactive, nor where to find it to re-enable it, etc. In short, it's not meant to be used in progress checking scenarios, as it's not considered a "step", it's a UI function.
  7. In terms of official scripts, it will never be used as that's not how AEGIS handles it. In official, that state is purely for where it shows up in the Quest log UI. AEGIS sees an inactive state in the same light as a quest in active state because it's still considered 'in-progress'.
  8. We had a heated debate in the staff chat regarding an issue with quest log commands. I'd like to get the community's opinion on this matter. At the moment, when using checkquest() the returned values are: -1 = Quest not started (not in quest log) 0 = Quest has been given, but the state is "inactive" 1 = Quest has been given, and the state is "active" 2 = Quest completed As a scripter, these values have always frustrated me as I couldn't use ! for checking if a user didn't have a quest, as 0 (has quest) would make this true. Not to mention that having 0 as a true value just doesn't make sense. So for my rewrite of checkquest, now named questprogress() I changed the values to: 0 = Quest not started (not in quest log) 1 = Quest has been given (state is ignored) 2 = Quest completed This is exactly how the command works in AEGIS. Now, the point at which the debate became heated was in regards to me removing the ability to check if a quest is marked as active or inactive. I explained my reasonings as follows: Even though a quest is marked as inactive by a player, it is still considered a quest that is in-progress, and therefore in an active state of having the quest. Displaying different dialog / performing different actions to a player if they marked a quest as inactive can cause for some serious user experience issues (confusion). why? Because, let's say a user had accidently marked a quest as inactive, or did it long ago then forgot. Then they went to do the quest and it wouldn't let them progress due to the fact that the quest was marked as inactive. Now you have an upset player who doesn't know what's going on. The inactive/active state in my opinion, is purely cosmetic (how it's displayed in the quest log UI), and should not be used in logic situations such as determining the progress of the quest in a script file. I don't know of any script or script dev that would actively make use of checking if a player has marked a quest as inactive. No official script checks if a user has marked a quest as inactive, because an inactive quest is still a quest that's in progress and therefore active in the eyes of the server. Could cause confusion for new script developers. The debate was to keep the ability to check if a quest is marked as active/inactive vs not having that ability. I personally didn't see the purpose of such a function, due to the fact that the active/inactive state's function is purely to tell the client where it should show up in the log UI. And that from a script developers perspective, it just doesn't make sense to ever perform differently based on if a quest was marked as inactive in a quest log by the player (because it's often ton to hide a quest for later) because it's still considered an active state. So, like I said, I've come here to ask your opinion. Would you ever make use of a function to check if a player had marked a quest as inactive? Or do you purely only need the ability to check if they don't have the quest, if they have it, and if they've completed it? My vote is to only have the three options, as logically it makes more sense. What is your opinion on this matter?
  9. Added some missing parts and added stuff to 15.2
  10. Late reply to this, but captcha is a failed solution. There are some many services based in China that you pay less than 1 cent to solve a captcha. You send the image to the service over HTTP POST and it sends back a reply with the solution. Captcha don't work, plain and simple. The best solution against bots do not come in the form of scripts or gimmicky solutions. The best thing you can do is roll out your own packet encryption with a challenge system (sends a question to the client and expects a correct reply) or use a solution already made such as Harmony.
  11. lol no please.. stop... let it die already lol. Sorry, but any of us devs from Janus would never leak the source and if any did, like Reddozen said, it would be a really old version of Janus. No where near what the current repo is at.
  12. You're gonna get sued so hard from FUNimation rofl. they don't joke around with their copyrights. Just FYI.
  13. There are some things in talks.
  14. got it, but how do i know that what version currently in HERCULES master version? git show-ref refs/remotes/origin/masterReplace the word 'origin' with whatever you named your remote. Typically origin is the default / best practice naming convention for the remote repo.
  15. No idea if this will work. <?phpecho '<img src="data:image/jpeg;base64,'.base64_encode($emblem_data).'">';?> Can't test it at the moment as I'm not at a computer atm. But basically the value stored in MySQL is a binary / BLOB of the image. Or you can use GD library's imagecreatefrombmpstring() function.
  16. kisuka

    About script

    You could do this a few ways, if it's a custom map than make a wall and set the gat for that part to non-walkable then disable flywings. If it's meant to be purely script based... it gets a bit harder. You'll want to make sure the map has fly wings disabled. Then if it's like a hallway or something put an invisable npc with a large radius area and put OnTouch:: so that when a player trys to walk passed that area, they walk onto the npc and get pushed back to the area they are meant to be in. Thats just some ways @.@ there are other methods.
  17. Be careful merging your patch client and game client into one exe. Typically when doing 'packing' anti-viruses will throw more false reports as it believes the client is a virus. Packing is the common way of bundling viruses with other programs so the user will launch them.
  18. but it does not have anti-ddos Who says? You honestly think DigitalOcean isn't supporting their network with ways to mitigate attacks? Come on. The whole "Anti-DDOS" crap that RO hosts pushes was a total gimmick, most of them didn't even have protection against attacks. Add some rules against attacks on a software level (firewall rules and such) and let your host worry about the more advanced methods which they most certainly already implement. In short, don't use hosts claiming to be good for "game hosting", "ro server hosting", etc... rent from a good provider such as Linode, DigitalOcean, Amazon, etc... learn command line while you're at it. Stop using a gui for everything.
  19. What do you mean? Like what content was available?
  20. Still a long way to go ^^; https://github.com/HerculesWS/Hercules/milestones/Match%20Official%20Content
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.