Jump to content
  • Sign Up

pan

Community Contributors
 View Profile  See their activity

  • Content Count

    355

  • Joined

  • Last visited

  • Days Won

    13

Posts posted by pan

  1. Posted

    My vote is for Kernel style, since majority of scripts already use this style. Some small tweaks would need to be made still but for the most part, most scripts already are in a form of kernel style.

     

    Once we agree on the style we should figure out the final decision on this max line length thing.

     

    Typically with kernel style, the max length is 80 characters per line.

    As everybody seems to hate Allman's and most scripts already follow this standard ): I agree. I think 80 characters per line is a good limit see this answer: http://stackoverflow.com/a/578318/929395

     

    @Haru

    I think when folding it can make a little more difficult, but when everything is unfolded it just seems better, but that's just my opinion. That's why standards need to be polled before being implemented, some things are "more personal" than others :)

  2. Posted

    eu uso client de 2014 e meus atributos são 600 e funcionam normalmente, não sei qual deve ser o seu problema :/

    Você sabe qual o limite de alteração de stats?

     

    @MuriloStrike

    Como que está o seu PACKETVER? E qual o hexed que você está usando?

  3. Posted

    Main problem about this, is that I think everybody will try to defend their current scripting style more than reach to an agreement :P

    That's why we need to show pros and cons and then make a poll to know which one is most accepted, I'm already using K&R in our source code, I don't mind switching styles in different projects, I just mentioned Allman's identation because nobody ever mentions it, and I, personally, find it better to read and to write than other styles.

    Allman style can't be used because currently we can't do:

    -	script	test	-1,{	}
    Or:
    function	script	test{	}
    Or:
    -	script	test	-1, {	function test	{	}	test();}
     

    (Except if i miss an update).

     

     

    We can always change our scripting engine to make comply with other standards, that's not really an issue... But I see that it could be a waste of time. I always thought that our headers are not very good, but changing such a 'basic' thing would make a lot of people confuse :x

  4. Posted

    Se bem me lembro, pelo menos nos clientes pré-renovação havia um limite imposto no próprio hexed, e só com um tipo especial chamado XRay era possível burlar esse limite. Provavelmente deve haver alguma limitação nos novos clientes que estão saindo também.

  5. Posted

    I can't think of a proper way to do so... The language syntax doesn't let you assign a value to the result of a function, probably because functions don't have a return type (and even when they in fact normally return a reference, you can't know that at parse time, because they could return void at parse time)

    If you have any good ideas... I don't :x

    Well, we can think of something, I'll try to study our current parsing engine and see what can be done c:

    Can you explain what you mean when you say it 'highlights' the block of script pan? Cuz I have my own syntax highlighter in Sublime Text 2 specific for scripts, so my blocks are always highlighted if I select one of the braces of that block.

    It "separates" a block from the rest of the code, and also I think it makes easier to identify quickly different parts of the code, as it becomes less crowded.

  6. Posted

    I disagree. It makes it unclear at first sight that the block is related to that specific if statement, and it uses too much vertical space unnecessarily. (For the same reason why I dislike excessive amounts of empty lines inside functions, in general. The less lines of code you can fit in your screens, the harder it becomes to understand what a function does.)

    And why don't use set to define variables? If it's not all right to use this syntax we should "remove" it from our documentation and just leave the entry in our source to keep backwards-compatibility.

    In some (very few) cases it's necessary to use it, so it needs to be kept in the documentation (perhaps also noting that it is deprecated and it should not be used unless strictly necessary.)

     

    An example where it is necessary is when you want to set a variable from another npc:

    set getvariableofnpc(.foo, "My Other NPC"), 1;

     

     

    Why not rewrite getvariableofnpc to behave like an identifier and work just like a regular variable would?
    getvariableofnpc(.foo, "My Other NPC") = 1;
    I prefer Allman's because it 'highlights' each block, making it easier to read, I also think that when functions are too crowded they are harder to read, but it's just a personal preference.

  7. Posted

    I don't know why nobody ever says anything about using Allman style, in my opinion it's the easiest to read and to maintain.

    if (condition){}else{}
    Or even a variation that I personally prefer to read:
    if( condition ){}else{}
    And also I think sometimes shorthanding is a good way to save time and still make good code, other times you could use the ternary operator... And why don't use set to define variables? If it's not all right to use this syntax we should "remove" it from our documentation and just leave the entry in our source to keep backwards-compatibility.

  13. Posted

    @Hadeszeus

    It should be working, by quick looking into the latest revision the only change that can 'mess' with this snippet is:

    	SC_DECORATION_OF_MUSIC,		SC__MAELSTROM,	SC__CHAOS,	SC_MAX, //Automatically updated max, used in for's to check we are within bounds.} sc_type;
    Just remember to add SC_IGNOREDISPELL before SC_MAX and update its const number
    	SC_DECORATION_OF_MUSIC,		SC__MAELSTROM,	SC__CHAOS,	SC_IGNOREDISPELL,	SC_MAX, //Automatically updated max, used in for's to check we are within bounds.} sc_type;
    Now it should be 578

  14. Posted

    Open your map/script.c and search for OnPCLoadMapEvent, you should find something like:

    eA@r15265struct Script_Config script_config = {	1, // warn_func_mismatch_argtypes	1, 65535, 2048, //warn_func_mismatch_paramnum/check_cmdcount/check_gotocount	0, INT_MAX, // input_min_value/input_max_value	"OnPCDieEvent", //die_event_name	"OnPCKillEvent", //kill_pc_event_name	"OnNPCKillEvent", //kill_mob_event_name	"OnPCLoginEvent", //login_event_name	"OnPCLogoutEvent", //logout_event_name	"OnPCLoadMapEvent", //loadmap_event_name	"OnPCBaseLvUpEvent", //baselvup_event_name	"OnPCJobLvUpEvent", //joblvup_event_name	"OnTouch_",	//ontouch_name (runs on first visible char to enter area, picks another char if the first char leaves)	"OnTouch",	//ontouch2_name (run whenever a char walks into the OnTouch area)};
    I don't know how it its in rA, but in Herc it is now:
    	/* script_config base */	script->config.warn_func_mismatch_argtypes = 1;	script->config.warn_func_mismatch_paramnum = 1;	script->config.check_cmdcount = 65535;	script->config.check_gotocount = 2048;	script->config.input_min_value = 0;	script->config.input_max_value = INT_MAX;	script->config.die_event_name = "OnPCDieEvent";	script->config.kill_pc_event_name = "OnPCKillEvent";	script->config.kill_mob_event_name = "OnNPCKillEvent";	script->config.login_event_name = "OnPCLoginEvent";	script->config.logout_event_name = "OnPCLogoutEvent";	script->config.loadmap_event_name = "OnPCLoadMapEvent";	script->config.baselvup_event_name = "OnPCBaseLvUpEvent";	script->config.joblvup_event_name = "OnPCJobLvUpEvent";	script->config.ontouch_name = "OnTouch_";//ontouch_name (runs on first visible char to enter area, picks another char if the first char leaves)	script->config.ontouch2_name = "OnTouch";//ontouch2_name (run whenever a char walks into the OnTouch area)
    Cabrera reacted to this

  16. Posted

     

     

     

     

     

     

    To add multi-thread support in something that's already coded is a lot of trouble. I'll read on this subject and see the cost-benefit of adding this 'feature' in Hercules.

    Can you send cost for adding this feature to pm

     

     

    There's no cost in adding features to Hercules, but it may take some time as I have to analyse our source-code first, and then test everything.

     

     

     

    Another issue to recall is multi-platform support. It'd have to be platform specific implementations for linux and windows, both of which have their own optimal solutions (linux has POSIX threads, pthread.h, and windows just has all the functionality within windows.h to create threads, though I believe there's a pthread for win32 out there, I've never used it). Boost also has its own thread library, but that's C++, at which point you might as well use C++11 standard if you had that option for the built-in threading.

     

    Though pan is right, the major issue is trying to figure out what you can really throw into threads safely. At the very least, it'd be interesting to see certain scripts be async. That is to say, if there are no global dependencies (only character variables being used in the script), then it might be totally feasible to handle processing in different threads. Imagine 1000 people using the refiner, and instead of each user blocking another (which isn't noticeable unless you have a high volume of players usually), each one runs asynchronously. 

     

    Though there's also the overhead of thread creation to consider. 

     

    Then there's also creating testbenches so you don't need 3000 players to test how well it worked.

     

     

    It's not that difficult to code a thread-implementation that supports both platform specific ones. The real issue is to design a system that is more resource efficient that the current one, also designing multi-threading in legacy code without breaking any functionality is more difficult than designing in green field projects. Implementing this in code wouldn't be so difficult as designing such system, that's why it's needed to research on the subject extensively before trying to do anything otherwise it'd be wasted work. When my next break begins I'll start looking possible ways to implement this system in our current design and post a project to other developers analyse.

  17. Posted

     

     

    To add multi-thread support in something that's already coded is a lot of trouble. I'll read on this subject and see the cost-benefit of adding this 'feature' in Hercules.

    Can you send cost for adding this feature to pm

     

     

    There's no cost in adding features to Hercules, but it may take some time as I have to analyse our source-code first, and then test everything.

  23. Posted

    I am personally not too fond of the idea, not that its bad, but it kind of feels like somethings are being pushed a bit too far in regards to customization. 

    I am fine with some new features and what not, but I don't think it is that much of a good idea to add every feature (For as useful as it can be) cluttering up the code with not-so-much-deal-breaking configurations/options.

     

    With the plugin system and any improvements it might have in the future, adding custom modifications is only going to be a matter of minutes, so everyone can freely mess up or overcomplicate their own installation without overcluttering the code with stuff that might not be really needed by most people.

     

    Please note though, this particular change might not be too big to add (And my comment is not regarding this particular suggestion, but more of a common thing), but its just I've been seeing some "Make this a builtin feature" more and more often everyday...

    I sort of agree with the above (perhaps the time to make this could be best invested in making group permissions hpm-friendly so a plugin could do this instead), but if there is demand for it to be built in, sure, in my opinion.

    I agree with XGear and Ind, it'd better if this was a plugin and not a built-in feature, it just seems more things to do maintenance and clutter our main code-base. Let's just wait what a high-up has to say about this...
×
×
  • Create New...

Important Information

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

  I accept