Jump to content

GmOcean

Community Contributors
  • Content Count

    371
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by GmOcean


  1. Your problem is in the for(loop).

    You're using @i without a player attached, you should be using .@i

     

    for (set @i,0; @i < 3; set @i,@i+1)

    into

    for (set .@i,0; .@i < 3; set .@i,.@i+1)

     

    After that, make sure you change all instances of " @i " into " .@i ". Or else the game will continue to spit out that error so long as a player is not attached.


  2. First, does your debugmes display the proper name? Secondly, if it does, does it match your cutin name correctly? Thirdly, if both 1 & 2 are working as intended, try creating a simple version of the script function first.

    e.g : Make a menu with 3 options. Option 1 = Show cards 1,2,3. Option 2 = Show card 4,5,6. Option 3 = Show cards 7,8,9. However have it build the cutin name like normal, by using variables instead of sql for the test.

    At this point you have nothing to lose out on, a simple check will remove this from the list of possible issues.


  3. From what i can tell this would allow you to bind an OnClock label, to a different label in a potentially different npc. Which, is the equivalent of the below:

    OnClock0100:
    L_event_end:
    end;
    

    With the exception of being able to do this all remotely. So instead of having OnClock labels in 100 different scripts, you would have 1 script managing all the OnClock labels.

    It would be cleaner, but wouldn't do much else than that. As you could easily just do what I did above. Managing each individual script as needed.

     

    In short, not needed but doesn't take anything away as it provides just more utility.


  4. I'd have to go with Emistry's idea honestly, it's far better than having it toggle'd in a conf file. Especially since there are multiple instances where you could use the progress bar with both walkable and non-walkable forms.

     

    Example that I used in a few scripts:

    1. In a custom crafting system, players were unable to move while the progress bar went through (much like other MMORPGs).

    2. In a custom battle ground, I add pyres that needed to be activated 5 times, each time took 5seconds. Meaning if they moved, or were attacked, the bar cancelled, thus making them have to start over. Really adds depth and variety to scripts with just this simple option.

    3. Made an item that simulated using a long cast time skill, however they needed to remain still or else it would cancel (intended feature), since the spell casted a global stun effect bypassing stats. No need to punish the players by making them unable to move to re-position themselves for strategic use.

     

    So again, I'd go with Emistry's idea, and add an extra parameter to make it root players, or allow them to walk.


  5. Honestly, both options are completely fine. As far as resources go, Hercules can handle well over a measly 90-900 variables, it could easily handle a whopping 90,000 variables in all honesty. The important thing is which type of variable is being used. If it is a permanent variable (those that dont get reset upon logout or done talking to an NPC / server restart) then it'll be a little resource heavy, but for this script I'd recommend using player variables (as Winterfox suggested in her example).

     

    The only thing I would do different from Winterfox's example though, would be to store the information in a custom sql_table. You'd only update the sql-db upon the player logging out or completing the quest, and resetting the quest.


  6. @@Khazou - If I'm not mistaken, NPC's & their duplicates share the same npc_variables as an intended feature in Hercules (rA as well I think).

    You can test this by making an NPC, and hardcoding a duplicate (the default way) and setting a variable, it should set it for both of them.

     

    Either way, whether they share or not, there is a small fix you can do on the script side to make it work as you want. All you would need to do is set the variables using setd/getd and add extra information to it, in this case you can just add the duplicates unique name to the variable.

     

    Ex:

    setd ".variable_name"+ strnpcinfo(3) +"$", "data_here";

  7. I'm not sure if this will fix it, but i'm pretty sure it will. This isn't tested, so be sure to make a copy of the file before making any changes (for backup purposes).

    Find the below in src/map/battle.c

    		if( sc && skill_id != PA_SACRIFICE && sc->data[SC_UNLIMIT] && (wd.flag&(BF_LONG|BF_MAGIC)) == BF_LONG) {			switch(skill_id) {				case RA_WUGDASH:				case RA_WUGSTRIKE:				case RA_WUGBITE:					break;				default:					ATK_ADDRATE( 50 * sc->data[SC_UNLIMIT]->val1 );			}		}

     

    and add the case for RA_ARROWSTORM:, should look like this:

    		if( sc && skill_id != PA_SACRIFICE && sc->data[SC_UNLIMIT] && (wd.flag&(BF_LONG|BF_MAGIC)) == BF_LONG) {			switch(skill_id) {				case RA_WUGDASH:				case RA_WUGSTRIKE:				case RA_WUGBITE:                                case RA_ARROWSTORM:					break;				default:					ATK_ADDRATE( 50 * sc->data[SC_UNLIMIT]->val1 );			}		}

     

    This should tell the server to not increase the damage output for having RA_UNLIMIT skill active.

     

    Save and Recompile. Again, this is untested, so I'm not sure if it will work.


  8. Yes and no.

    Currently cell_pvp isn't something that exists, so you would need to make a custom cell and edit multiple src files to make it work.

     

    However, this can be simulated by either making the non-pvp cells unwalkable, meaning you can't go there. Or you could use @killable command with multiple NPC's. If a player walks near/on/over those npc's you just make it so they use @killable. This will either make them a targetable person, or make them unkillable to players.

     

    But since, this isn't done via a src edit, and through script, it is likely exploitable and can cause issues. Best bet is to ask for a modification in src or plugin section.


  9. Yes wow. Welcome back. I used to refer to your work quite abit trying to learn scripting, as well as bookmarking your php scriptcommands page. But that was way back in eA days. Glad to see you re-entering the RO scene. It seems people who leave (myself included) always come back to this wonderful game and community.

    Welcome back.


  10. IMO the app should function as a quick and easy way to access RO item/mob database, nothing more, nothing less.

    Simply opens up to a small splash page of Midgard Community that displays for about 2seconds, then they just have 2 blank search bars.

    1 for Item Search, and the other for Monster Search.

     

    Seems about the easiest, and cleanest way to do this. I honestly don't feel the app should have a loaded kit of features, when this is about all it'll be needed/used for. But again, just my opinion.

     

    Keep up the good work.


  11. What you need to do is make sure they are online such as this:

    .@na = query_sql("SELECT `char_id`,`online` FROM `char`", .@c_id,.@online);.@nb = query_sql("SELECT `char_id` FROM `char_reg_num_db` WHERE `key`='hunter' && `value`='1'", .@char_id );			for( .@i = 0; .@i < .@nb; .@i++ ) { //Loops through second sql_query                            for( .@a = 0; .@a < .@na; .@a++ ) { //Loops through first sql_query                                if (.@c_id[.@a] == .@char_id[.@i] && .@online[.@a]) { //Compares Character IDs, and then checks if player is online.				    // If player is online, then we send the information out. Else, it should skip ahead to the next player who is online.                                    dispbottom "(From Hunter Academy) : "+strcharinfo(0)+" just got online.",0xFFFF00,.@char_id[.@i];			        }                            }                        }

     

    Granted there is a cleaner way to do this using a better sql_query, and/or using the command " while() " instead of " for() ".

    However, both should get the job done, and depending on the player base, the amount of resources saved is minimal at best.

     

    Edit: Haven't tested, but based on scripts I've written in the past this should work, barring any syntax errors.

×
×
  • Create New...

Important Information

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