Jump to content

Zephyr

Members
  • Content Count

    9
  • Joined

  • Last visited

Everything posted by Zephyr

  1. Forget about free protections, it doesn't work, no, no one.
  2. Remove them all. If an adm can't make this basic scripts by themselves, they don't deserve a successful RO server. @edit Keep just the warper, job master and card remover. Because they are a very long NPC to build, but don't keep them at the git, instead, make some pinned topic at the scripts area here in the forum to put them.
  3. Zephyr

    Midgard-Community

    Thanks for your response! This I can probably do. As for your second suggestion, I don't think I can necessarily do it just 'cause I'm not skilled enough when it comes to coding lol It's easy, when you have time, send me a message and we can talk about it. I can teach you how to send and receive JSON data and you'll see how it's easy.
  4. I don't bother if this feature will be removed, I'm just saying that has a lot of newbie players that doesn't know the RO interface, and it's good to warn them if they have some inactive quests, and teach them how to active it again. I'm complaining about this, because it actually happened to me, I didn't have that check before on my NPC, but I had to implement it because private RO players just don't do quests a lot. There's no need for quests and only players who like the game storyline like to do it. RO Quest Window is frustating, it's a big mess, and players got confused easily, that's why I'm saying: let the check there, just for warn players about they have inactive quests on their window and teach them on how to active it again, just it. There's no need to remove this feature, just change the -1 to 0 and it'll work fine. return checkquest(id); // will return false if it's not on the quest log and true if it is. That's what you want and people who uses quest commands will be happy again.
  5. Zephyr

    Midgard-Community

    Suggestion: When we do a search, make it to show the fields we put again, example: if I search for the item ID 1723, it takes me to this page: Above that little "search result" window, you could implemente another small window with the fields we filled before, so we can search another item on that screen without clicking the "back" button to search it again. If I filled the ID field, the ID field will be shown there, if I filled another fields, it'll appears too (but only the fields we filled before). It'll allow fast searches through the database. If you implement AJAX request, it'll be amazing too. When we click the "search button" or press enter, instead of the page reload, it'll show a "loading" gif and then the page shows the info. It'll increase the speed, and it'll be the faster database ever created, and your database will be unique, doing what no other database does, focusing on speed and an easy interface that allows the users to search over and over again with just a few clicks. Now, other amazing suggestion for you: make an API that returns JSON data with the infos, this way, web developers (like me) can make a request to your database like: http://database.midgard-community.com/?api=database&search=item&id=1723 And it will return something like: data = { item: { id: 1723, name: "Luna Bow", desc: { "A bow crafted out of moonstone with an attached blade that allows its user to block and counter enemy attacks. ", "The drawback is that this bow is quite heavy.", "[Refine Rate 0~6]", "DEF + 2", "[Refine Rate 7~8]", "DEF + 3", "[Refine Rate 9~10]", "DEF + 5", "[Lunatic Brooch & Luna Bow Equip Set]", "Class : Bow", "Attack : 100", "Weight : 200", "Property : Neutral", "Weapon Level : 3", "Required Level : 30", "Applicable Job : Hunter" }, droppedby: { monsterid: 1650, monstername: "Sniper Shecil", rate: "10%" } }} If the item doesn't exists: data = { error: 1, errorException: "This item doesn't exists."} And then your database can be implemented at any other site easily, allowing users can search for your database from any site that implements it, of couse, at the result, including the link for your site, or even a link with something like "See full info clicking here" and then going to the original link. OR, if you are planning to receive donations or selling features, you can sell it to the servers, making some very simple window with the API implemented, so the admin can just iframe it into their sites to search anything, and you can control the requests for any server like that: http://database.midgard-community.com/?api=database&user=zephyr&search=item&id=1723 If the zephyr user has no permission (didn't buy the api feature), it simply return an errorException like I said before. I liked the website, I'll save it. I'd like to see the implementations.
  6. In my experience with Ragnarok, I'm not a new user, actually here, yes, but I build servers for about 5 years, and based on what I know, check more is not a issue, it's for protect, users can lag, no server are perfect, and NPCs can be always exploitable, that's why the double-checking. And @Yommy, you say that Kisuke is right, because was not you that received a topic like that in your forum: Where were the quest? Can you guess? ~ My vote is "NO" for this poll and I'll save the diff to always revert you're doing on removing features. You could just change from "-1" to "0", simple, will not change almost nothing, you'll get your "false" return, and I'll get my "inactive" or "active" status. But instead, you're going to remove, and I didn't like that because my server is entirely based on quests, and I need to check everything, thank you, that's my unchangeable opinion.
  7. That's fine if I can check if the quest is with the player, even if it's inactive. I thought that checkprogress would return false if the quest were inactive. But I still prefer the way it is, for example, if the user inactive the quest by mistake (it happens a lot, since it's just to right-click), my NPC checks if the quest is inactive and alert the player: for( set @i, 50009; @i <= 50036; set @i, @i + 1 ) if(checkquest(@i) == 0) { mes "Oh! You returned alive,"; mes "I thought you were died"; mes "for that stupid monsters,"; mes "I was almost sending reinforcements"; mes "to you."; next; mes .@n$; mes "Please, your mission seems like"; mes "to be inactive at the moment,"; mes "open your quest menu (alt+u),"; mes "click on the 2nd tab and active"; mes "it again. Back to work soldier!"; close; } I think this is cleaner, beaultiful, alerts the player, and you can make the player feels good. lol My whole script for consult:
  8. Personally, I think this way is good. I have custom quests and I need to check if it's active or inactive. for( set @i, 50009; @i <= 50036; set @i, @i + 1 )if( checkquest( @i ) == 1 && checkquest( @i, HUNTING ) == 1 ) { mes "Do you want to abandon the quest?"; if( select( "No, I'll continue this quest.", "Yes, I want to give up." ) == 1 ) close; dispbottom "You have deleted this quest.."; erasequest @i; close;} If I can't check if it's inactive, the player can take another quest. My system is a daily quest that the user can do it 10 times to receive a reward, but they can't take a quest, set it as inactive and take another. If it was like that, I could take a quest to kill 30 Dullahans, set it to inactive, take another, active both and kill 30 (not 60) to complete both together killing just a half. Screenshots with your way (sorry I'm brazilian): Take a quest: Set it as inactive: Take another quest: Now I have two quests: Now, the way it is with screenshots: for( set @i, 50009; @i <= 50036; set @i, @i + 1 )if( checkquest( @i ) >= 0 && checkquest( @i, HUNTING ) < 2 ) { mes "Do you want to abandon the quest?"; if( select( "No, I'll continue this quest.", "Yes, I want to give up." ) == 1 ) close; dispbottom "You have deleted this quest.."; erasequest @i; close;} Take the quest: Set it as inactive: Can't take another: Talk to me if you need more translation, but I think you'll understand. I translated both script parts to English for you to understand. --- That's fine if you guys make the command like that: ...But if I understood your question wrong, let me know.
  9. /src, here we go!

×
×
  • Create New...

Important Information

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