Lock / Unlock Scroll

Quote:

Originally Posted by Syloxx did i said anything about linux? i mean you compare the cpp module inside the gs with a cs application i talk about performance so what you think is more performant?

Quote:

Originally Posted by ​Exo Under normal conditions, I vote for C#! Now let me me be specific so we can have a valid discussion here. I have been spending almost a year on mathematical and algorithmic competitive programming and have worked countless time with both languages. Why C#? NET is easier to use for development phases, raw C# is faster than c++ why? C# JIT almost optimizes everything whilst in C++ you will have to optimize everything [Even simple sortings/searchs/data struct building, just everything. So we it comes to huge applications that are supposed to handle too much data regularly in a parallel manner then if you are not going to write let's say x10 of code as you would do in C++ to each the same performance rates then C# is the way to go. Otherwise, C++ would be faster since it won't go into the same process as C# do with its JIT.

Quote:

Originally Posted by Syloxx sure cpp brings alot of work with it but you get alot of benefits with it cross platforming and the end performance is one of the point and as long as microsoft doenst add native .net for desktop apps i wont use c# in any kind of server proccess. [Only registered and activated users can see links. Click Here To Register...] We are talking about server software then we shouldnt think "whats the easiest way to do" we should think like "whats the most secured, stable and performant way to do"

Quote:

Originally Posted by ​Exo Of course, but that would really matter if this thing is really important and the performance ratios would affect. Here, I don't see the point, we are not rebuilding the modules we're just using some kind of a bridged connection and even after the tons of optimizations you will have to implement from small search functions to socket classes and database connections you will achieve the same results as if another guy did in way less code in C# and you will just get a few ms difference. In this case of not building something that really damages the performance in a way or another the easier option seems more sufficient to me.

Quote:

Originally Posted by Syloxx might be, but if you want easy code go with python :) if u use iron python its a .net based framework you wont get any performance difference to c# so why should i use c# if i could write it in python way easier? now dont say "easy GUI" who the hell want GUI on a server?

Quote:

Originally Posted by ​Exo Have you checked the performance ratio of C# to IronPython? I guess not cuz it's too hight (in this case you take it into account since it's noticable). Another reason is because most projects in the last few years were in C# so in case of a reference need, it makes sense to use C# instead of having to recode everything again. *IronPython has extra compilation processes not like other .NET since iPy is interpreted.

Quote:

Originally Posted by Syloxx nope, i didnt checked the performance from ironpython to c# got it just by reading anyway you went really offtopic the topic was: "why using a packet filter if everything can be done inside the database"

Quote:

Originally Posted by ​Goofie​ Filter is better, less load and you can prevent them before it happening "db side". Just get the "slot" numbers and then read the "INVENTORY_MOVE" packet, if the slot.contains(list) && this.locked sendnotice: continue; Easy peasy.

IF @Serial64 or @ItemID (dont know whats used on the queries) EXISRS IN (SELECT * FROM _ConfigLockedItems WHERE ItemID = @ItemID | OR Serial64 @Serial64)
RETURN -x

Quote:

Originally Posted by Syloxx well, what is so bad if it happen db side? and in SQL is more easy Code: IF @Serial64 or @ItemID (dont know whats used on the queries) EXISRS IN (SELECT * FROM _ConfigLockedItems WHERE ItemID = @ItemID | OR Serial64 @Serial64) RETURN -x info be4 you guys cry: return doenst disconnect the client every time it depens on the return value :) another info: its FORBITTEN to select , update , insert or delete in C programation just calling procedures is allowed (yes, i know "but joymax..." ye but joymax shared the files with the world so) so what you wanna do? make a XML file and update it on every usage, hardcode all the items or storage it sql side with an sql procedure?

Quote:

Originally Posted by ​Goofie​ Never said it was bad, just unprofessional, example would be "+ing" and item, if you success +11 and your maxplus is +10, you need teleport before the item's plus changes back to +10, with a filter you can prevent them from doing it +11. Also SQL queries will result in more DB load, more DB shit needed etc, Silkroad is already unstable when it comes to the DB and its load. My goal with life is to make servers stable, stop the 300 rows of coding inside the SQL just to check one thing, the less queries running in your SQL the more speed you have for the basic stuff. So 0 sql usage 2k15 braw.

Quote:

Originally Posted by Syloxx sure, in thos case a packet filter the besser choise because gameserver updates the item in _Items but move / delete / exchange is done by a procedure. so simply add a new check to these procedures and done this check will be just 1 check under 10,000 inside the shard database so whats so special on that check to outsource it to a filter? :) or you will outsouce every check example "username exists check" :D and nope... silkroad isnt unstable sql related how should this be possible all the exploits are binary related :) and i prefer 3 more lines in an procedure instad of keep running a additional proccess wich play arround with my traffic "how i said befor in my opinion a packet filter should send the traffic without any detours to the agentserver exception: the opcode itself is black listed (exploit for example)" this guaranteed more stability and way less performance issues. just check pioneer, Manuel had so many problems with filters and tought all the time its my fault but i setup every propper with the 1st setup the problem was all the time a packet filter. since the Manuel uses the packetfilter like i said apporove there is no issues :) a packetfilter slow down the performance thats sure but the art is it to keep the performance lose as less as possible and well thats not possible if you add like 10000 features to a packetfilter the SQL server is way faster in this case :) [Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...] just googled a bit and well the most ppl agree with me :P

Quote:

Originally Posted by ​Goofie​ By the way "manuel" is using SUPERMAN.

Quote:

Originally Posted by Syloxx might be but then he turned of all the features i asked him if I am allowed to use his hyperfilter during my beta of VSRO 274 and if its possible to setup it as proxy only and he said "yes, thats what i am doing currently" anyway we went to offtopic, SQL is a way better method then packet filter in this case and done i also posted by idea how to improve that system so if someone wanna do it go ahead :)