Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/23/20 in all areas

  1. 2 points
  2. 2 points
  3. M2 Download Center Download Here ( Github Backup ) - Download Here ( GitHub ) Download Here ( VM 9.2 ) or Download Here ( VM 12 ) Use this source: [Hidden Content] or [Hidden Content]
    1 point
  4. M2 Download Center Download Here ( Internal ) Well, such a thing is quite easy, and I know it since 2011~2012 (when the first 30k game cores were released to be more precise). You can find some diff patch files of that time for 30k game cores on the web that do this, but I will explain to you how to do it via source code editing. Before all, why the 40k game core files have a login more slower than usual? That's because ymir implemented an additional encryption security using cryptopp, and at login, they added some key agreement checks, which ended up the login to be more slower. You can actually disable such a feature, so that you can have the login fast like the old game revisions had. Disabling it will actually remove the "key agreement" issue, and will encrypt the connection with xtea instead of some cryptopp algorithms. (no big security issues, so it's safe to do) The edit is quite simple: Via server, you have to go and edit ^/Srcs/Server/common/service.h commenting #define _IMPROVED_PACKET_ENCRYPTION_ to // #define _IMPROVED_PACKET_ENCRYPTION_ Via client, same story for ^\Srcs\Client\EterBase\ServiceDefs.h commenting #define _IMPROVED_PACKET_ENCRYPTION_ to // #define _IMPROVED_PACKET_ENCRYPTION_ Additionally, in the client, you must also edit the archaic pong from ^\Srcs\Client\UserInterface\Locale.cpp like this: find #define LSS_SECURITY_KEY "testtesttesttest" change it to #define LSS_SECURITY_KEY "1234abcd5678efgh" Video of a quick login: (using a second rate connection, and with 4810 programs opened simultaneously) [Hidden Content] Here how the code should be at the end: Enjoy your abione.
    1 point
  5. M2 Download Center Download Here ( Internal ) Hey there, I have an Halloween gift for you all. i have been working for a few hours on official like element image on target window(See screenshots below). When you click on a mob if it is defined as elemental, it will open an element image in addition to the target window. Don't forget to hit the like button! (C) Metin2 guild wars - coded by [GA]Ruin - 27/10/2017 (I create custom metin2 systems in c++/python. if you want a custom system send me a pm and we can talk over skype). Let's begin! Server Side: Open service.h, add in the end: #define ELEMENT_TARGET Open char.cpp, search for else { p.dwVID = 0; p.bHPPercent = 0; } add below: #ifdef ELEMENT_TARGET const int ELEMENT_BASE = 11; DWORD curElementBase = ELEMENT_BASE; DWORD raceFlag; if (m_pkChrTarget && m_pkChrTarget->IsMonster() && (raceFlag = m_pkChrTarget->GetMobTable().dwRaceFlag) >= RACE_FLAG_ATT_ELEC) { for (int i = RACE_FLAG_ATT_ELEC; i <= RACE_FLAG_ATT_DARK; i *= 2) { curElementBase++; int diff = raceFlag - i; if (abs(diff) <= 1024) break; } p.bElement = curElementBase - ELEMENT_BASE; } else { p.bElement = 0; } #endif open packet.h, search for: } TPacketGCTarget; add above: #ifdef ELEMENT_TARGET BYTE bElement; #endif Client side: open locale_inc.h, add in the end: #define ELEMENT_TARGET open packet.h, search for } TPacketGCTarget; add above: #ifdef ELEMENT_TARGET BYTE bElement; #endif open PythonNetworkPhaseGame.cpp, look for: else if (pInstPlayer->CanViewTargetHP(*pInstTarget)) replace below with the following: #ifdef ELEMENT_TARGET PyCallClassMemberFunc(m_apoPhaseWnd[PHASE_WINDOW_GAME], "SetHPTargetBoard", Py_BuildValue("(iii)", TargetPacket.dwVID, TargetPacket.bHPPercent, TargetPacket.bElement)); #else PyCallClassMemberFunc(m_apoPhaseWnd[PHASE_WINDOW_GAME], "SetHPTargetBoard", Py_BuildValue("(ii)", TargetPacket.dwVID, TargetPacket.bHPPercent)); #endif open PythonApplicationModule.cpp, look for #ifdef ENABLE_ENERGY_SYSTEM add above: #ifdef ELEMENT_TARGET PyModule_AddIntConstant(poModule, "ENABLE_VIEW_ELEMENT", 1); #else PyModule_AddIntConstant(poModule, "ENABLE_VIEW_ELEMENT", 0); #endif open game.py, look for def SetHPTargetBoard(self, vid, hpPercentage): if vid != self.targetBoard.GetTargetVID(): self.targetBoard.ResetTargetBoard() self.targetBoard.SetEnemyVID(vid) self.targetBoard.SetHP(hpPercentage) self.targetBoard.Show() replace with: if app.ENABLE_VIEW_ELEMENT: def SetHPTargetBoard(self, vid, hpPercentage,bElement): if vid != self.targetBoard.GetTargetVID(): self.targetBoard.ResetTargetBoard() self.targetBoard.SetEnemyVID(vid) self.targetBoard.SetHP(hpPercentage) self.targetBoard.SetElementImage(bElement) self.targetBoard.Show() else: def SetHPTargetBoard(self, vid, hpPercentage): if vid != self.targetBoard.GetTargetVID(): self.targetBoard.ResetTargetBoard() self.targetBoard.SetEnemyVID(vid) self.targetBoard.SetHP(hpPercentage) self.targetBoard.Show() open uitarget.py, look for import background add below: if app.ENABLE_VIEW_ELEMENT: ELEMENT_IMAGE_DIC = {1: "elect", 2: "fire", 3: "ice", 4: "wind", 5: "earth", 6 : "dark"} look for: self.isShowButton = False add below: if app.ENABLE_VIEW_ELEMENT: self.elementImage = None inside Destroy method, look for: self.__Initialize() add below: if app.ENABLE_VIEW_ELEMENT: self.elementImage = None inside ResetTargetBoard method, look for: self.hpGauge.Hide() add below: if app.ENABLE_VIEW_ELEMENT and self.elementImage: self.elementImage = None look for : def SetElementImage(self,elementId): add above: if app.ENABLE_VIEW_ELEMENT: def SetElementImage(self,elementId): try: if elementId > 0 and elementId in ELEMENT_IMAGE_DIC.keys(): self.elementImage = ui.ImageBox() self.elementImage.SetParent(self.name) self.elementImage.SetPosition(-60,-12) self.elementImage.LoadImage("d:/ymir work/ui/game/12zi/element/%s.sub" % (ELEMENT_IMAGE_DIC[elementId])) self.elementImage.Show() except: pass Compile server, client source and root pack and that's it! Enjoy! Happy halloween!
    1 point
  6. Hi there devs, Its been a while since my last release and probably this will not change, but I had this guide in my head for like a year now. In my last ~2 years while I was working in the AE team various devs came and go, and this kind of guideline would have been a huge help and could prevent lots of errors. I have been in the dev scene for more than 10 years now and (as some of you may already noticed) one of my main interest has always been making more and more user friendly and complex UI objects/interfaces and along the road gathered tons of experience. You won't end up with another shiny system that you can use in your server this time by reading this article, but instead maybe I can prevent you from making windows that stays in the memory forever, opens infinite times, prevents other window's destruction, and many more. Who knows, maybe you will leave with some brand new never ever seen tricks that you can use in your future UIs. But first of all lets talk about some good2know stuff. UI layers Layers are root "windows", their purpose to hold all kind of interface windows while managing the z order of the windows (z order = depth level of the windows, which one is "above" the other). By default there are 5 layers (from bottom to top): "GAME": this is only used for the game window (game.py), and when you click on it the game will translate the click position to the map "UI_BOTTOM": this is used for shop titles "UI": this is the default layer, we would like to put most of our windows into this layer, like inventory, character window, messenger, pms, etc, so they can overlap each other "TOP_MOST": every window, that should always be in front of the player, so other windows would not overlap them from the lower layers, so for example the taskbar is placed in this layer "CURTAIN": this is for the curtain window, which is actually a black as a pit window, that is used to smooth the change from different introXX windows (like between login and charselect) This is the outest layer and goes before the other 4. So when the render happens, the 1st layer and its childs will be rendered first, then the 2nd layer, then the 3rd, etc, so by this we will get our comfy usual client layout. In the other hand, when we click, everything goes in reverse order, first the client will try to "pick" from the curtain layer's child windows (also in reverse order), then the top_most layer, etc. Ofc there is no layers beyond the game layer, so usually the "pick" will succeed there, and we will end up clicking on the map. UI windows Now lets talk a little bit about the parts of an UI window. It has a python object part and a c++ object part. When you create a basic Window (from the ui.py) basically 2 things happen: a python Window object is created first, then through the wndMgr.Register call a c++ CWindow object is created. These 2 objects are linked, in python the handle for the CWindow is saved in the self.hWnd variable, while in the CWindow the python object handle would be stored in the m_poHandler. What are these handles for? If you want to call a method on a window from python, you have to specify which window you want to perform that action on. Remember, the python part is just a "frontend" for the UI, the actual magic happens in the cpp part. Without python, its possible to create windows, but without the cpp part there is no windows at all. On the cpp part, we need the python object handle to perform callbacks, like notifying the python class when we press a key, or pressing our left mouse button. By default the newly created window will take a seat in one of the layers (if provided through the register method, otherwise it goes to the UI layer). In a healthy client we only put useful windows directly into a layer. For example you want to put your brand new won exchange window into the UI layer, but you don't want to put all parts of a window into the UI layer (for example putting the base window into the root layer then putting the buttons on it to the root layer too, then somehow using global coordinates to make it work). Instead, you want to "group" your objects, using the SetParent function. You may say that "yeah yeah who doesn't know this?", but do you know what actually happens in the background? The current window will be removed from its current parent's child list (which is almost never null, cus when you create it its in the UI layer, so the parent is the UI layer) and will be put into the end of the new parent window's child list. Why is it important, that it will be put into the end? Because it will determine the Z order of the childs of the window. For example if I create 2 ImageBox with the same size of image on the same position and then I set ImageBox1's parent before ImageBox2's parent, then I will only see ImageBox2, because that will be rendered after ImageBox1, because its position in the childList is lower than ImageBox2's. For normal window elements (like buttons) its very important, because after you set the parent of a window, you can't alter the z order (or rather the position in the childList) unless you use the SetParent again. No, you can't use SetTop, because its only for windows with "float" flags on it, which you only want to use on the base of your window (the root window that you put your stuff on it and use it as parent for most of the time). Window picking "Picking" is performed when we move the cursor. This is an important method, because this will determine the result of various events, for example the OnMouseOverIn, OnMouseOverOut, OnMouseRightButtonDown, etc. To fully understand it, you must keep in mind that every window is a square. Do you have a perfect circle image for a button? No you don't, its a square. Do you have the most abstract future window board design with full star wars going on the background? No, you DON'T. ITS A SQUARE. By default, a window is picked if: the mouse is over the window AND the window is visible (Shown) AND the window doesn't have "not_pick" flag set AND the window is "inside its parent's square" on the current mouse position, which means if the parent's position is 0,0 and it has a size of 10x10 and the window's position is 11, 0, the window is outside of its parent's square. This is really important to understand, lots of UI has fully bugged part because of ignoring this fact. I think every one of you already experienced it on some bad illumina design implementation, when you click on a picture, and your character will start to run around like a madman, because the game says that A-a-aaaaa! There is NO WINDOW ON THAT POSITION It is useful to use the not_pick flag whenever you can, for example on pure design elements, like lines and flowers and ofc the spaceships on the background. Lets say you have a size of 10x10 image that has a tooltip, and you have a window on it that has a size of 5x5. When the mouse is over the image, the tooltip will be shown, but if its over the 5x5 window, the tooltip won't appear, unless you set it to the 5x5 window too. But if you use the not_pick flag on the 5x5 window, the 5x5 window won't be picked and the tooltip would be shown even if the mouse is over the 5x5 window. Window deletion, reference counting, garbage collector, proxying The window deletion procedure starts on the python side, first the destructor of the python object will be called, then it will call the wndMgr.Destroy that deletes the c++ object. By default, we have to store our python object, or this time our python window, to make sour it doesn't vanish. Usually we do this via the interface module, like "self.wndRandomThing = myModule.RandomWindow()". But what is this? What is in the background? Python objects has reference count. Let me present it with the following example: a = ui.Window() # a new python object is created, and its reference count is 1 b = a # no new python object is created, but now b is refering to the same object as 'a', so that object has a refence count of 2 del b # b is no longer exists, so its no longer referencing to the newly created window object, so its reference count will be 1 del a # the newly created window object's reference count now 0, so it will be deleted, calling the __del__ method To be more accurate, del-ing something doesn't mean that it will be deleted immediately. If the reference count hits 0 the garbage collector (btw there is garbage collector in python if you didn't know) will delete it, and that moment the __del__ will be called. It sounds very handy isn't it? Yeeeeah its easyyyy the coder don't have to manage object deletion its sooo simple.... Yeah... But lets do the following: class stuff(object): def __del__(self): print "del" def doStuff(self): self.something = self.__del__ # here we could just simply do self.something = self too, doesnt matter a = stuff() a.doStuff() # and now you just cut your leg del a #you are expecting the "del" print, but that will never happen You may say " ? oh please who tf does something stupid like this? It SO OBVIOUS that its wrong whaaaaaaat????" But in reality, I could count on only one of my hand how many devs don't make this mistake. Even my codes from the past decade are bad according to this aspect, since I only realized this problem about a year ago, when I was working on the AE wiki. Even the yimir codes contain tons of this kind of errors, however there was definitely a smart man, who implemented the __mem_func__. Okay, I see that you still don't understand how is this possible to make this kind of mistake, so let me show you a real example: class myBoard(ui.Board): def __init__(self): super(myBoard, self).__init__() self.makeItRain() def __del__(self): super(myBoard, self).__del__() print "I want to break free. I want to breeaaaaaak freeeeeeeeeeee" def doNothing(self): pass def makeItRain(self): self.btn = ui.Button() self.btn.SetParent(self) self.btn.SetEvent(self.doNothing) #boom a = myBoard() del a # but where is the print? Thats not that obvious now right? What happens here? We create a myBoard object, which in the __init__ calls to the makeItRain func, which stores an ui.Button object, and sets the button to call for the myBoard class's doNothing function with the self object pointer in the OnLeftMouseButtonDown function, which means that the reference count will never be zero, because the btn referenced in the myBoard but myBoard is referenced in the btn but the btn is referenced in the.... so you know, its a spiral of death, that our best friend garbage collector can't resolve. Okay, but how to do it correctly? Lets talk about proxying. In python, proxies are weak references, which means that they don't increase reference count of an object, which is exactly what we need. #let me show this time the console output too class stuff(object): def __del__(self): print "del" >>> from weakref import proxy >>> a = stuff() #newly created object >>> b = proxy(a) #create weak reference to the new object (note that the weak reference object is also an object that stores the weak reference) >>> b #what is b? <weakproxy at 02DB0F60 to stuff at 02DBFB50> # b is a weakproxy object that refers to a which is a "stuff object" >>> del b # what if we delete b? # no "del" message, the stuff object is not deleted, because its reference count is still 1, because its stored in a >>> b = proxy(a) # lets recreate b >>> del a # now we delete the only one reference of the stuff object del # and here we go, we got the del message from __del__ >>> b # okay but whats up with b? <weakproxy at 02DB0F60 to NoneType at 7C2DFB7C> # because b is a weakproxy object, it won't be deleted out of nowhere, but it refers to a NoneType right now, because the stuff object is deleted (also note here that NoneType is also a python object :D) >>> if b: #what if I want to use b? ... print "a" ... Traceback (most recent call last): File "<stdin>", line 1, in <module> ReferenceError: weakly-referenced object no longer exists # in normal cases no need to trycatch this exception, because if we do everything right, we will never run into a deleted weakly-referenced object But how do we proxy something like self.doNothing? Actually, what is self.doNothing? self.doNothing has 3 parts: The first part is not that obvious, it has a base class pointer, which is points to myBoard. It has a class object pointer, that is basically "self". It refers to the current instance of myBoard. It has a function object pointer, called doNothing, which is located inside the myBoard class. And now we can understand ymir's ui.__mem_func__ class, which is exactly meant to be used for proxying class member functions: # allow me to reverse the order of the definitions inside the __mem_func__ so it will be more understandable class __mem_func__: def __init__(self, mfunc): #this happens when we write ui.__mem_func__(self.doSomething) if mfunc.im_func.func_code.co_argcount>1: # if the doSomething takes more than one argument (which is not the case right now, because it only needs the class obj pointer (which is the 'self' in the 'self.doSomething')) self.call=__mem_func__.__arg_call__(mfunc.im_class, mfunc.im_self, mfunc.im_func) #lets unfold the python object to the mentioned 3 parts else: self.call=__mem_func__.__noarg_call__(mfunc.im_class, mfunc.im_self, mfunc.im_func) #this will be called for the 'self.doSomething' def __call__(self, *arg): # this line runs whenever we call apply(storedfunc, args) or storedfunc() return self.call(*arg) class __noarg_call__: # this class is used whever the python object we want to proxy only takes one argument def __init__(self, cls, obj, func): self.cls=cls # this one I don't really get, we won't need the class object later also its not proxied, so its probably here to prevent delete the base class in rare cases self.obj=proxy(obj) # here we proxy the object pointer which is what really matters self.func=proxy(func) # and then we proxy the class func pointer def __call__(self, *arg): return self.func(self.obj) # here we just simply call the class function with the object pointer class __arg_call__: def __init__(self, cls, obj, func): self.cls=cls self.obj=proxy(obj) self.func=proxy(func) def __call__(self, *arg): return self.func(self.obj, *arg) # here we just simply call the class function with the object pointer and additional arguments Pros, cons, when to, when not to, why? Now you may ask that "Okay okay that sounds good, but why? What can this cause, how big the impact could be, is it worth to even bother with it?" First of all, you must understand that this is kinda equal to a memory leak. I would actually call these non-deleted windows as "leaking windows". Every time you warp, new and new instances will be generated from those objects, and ofc, one instance of a window means like about +50/100 instances, depending on the window complexity, how much childs it has. Usually these windows are at least remain in a Hide state, and hidden windows don't affect update and render time, but they will remain in the root layer, and may stack up depending on how much time the player warp. Still, the number of leaking root windows / warp is around 50-100, which is really not much for a linked list (the type of the childList). However, the memory consumption is much greater. One year ago AE had 10k leaking windows growth / warp. One base class (CWindow)'s size is 140 bytes, which means the memory growth is at least 1,3MB/warp and it does not contain the size of the python objects size for those windows, the linked_list headers and other necessary stuffs. After some hour of playing this can easily reach 100+MB of leaking memory. On worse cases the old windows are not even hidden, and on rewarp players may see multiple instances of the mentioned windows, like double inventory, double messenger window, etc. In this cases those windows can affect the render and update times too. Pros: your code will now work correctly regarding to this topic you may gain some performance boost you may find stuff in your client that even you don't know about you may find enough kebab for a whole week you can save kittens by removing leaking windows and proxying objects you can build my respect towards you and your code and you can even calculate the actual number using the following formula: totalRespect = proxysUsed * 2 + ui.__mem_func__sUsed - proxysMisused * 3.511769 - ui.__mem_func__sMisused * pi - 666 * ui.__mem_func__sNotUsed Cons: depending on how bad the situation is and how skilled you are, the time needed to find and fix everything could be vary, from few hours to several days if you are satisfied with your client as it is right now there is not that huge benefit regarding how much time it could take to fix all the windows Detecting leaking windows DON'T BLOCK THE BACKEND!! At first glance python code looks like you are invincible, you can do whatever you want, you are not responsible for the performance because python has a bottomless bucket full of update/render time and if the game freeze sometimes its definitely not your fault, the game is just BAD. Lets talk about OnUpdate and OnRender, whats the difference, when they are called, what to and what not to put in there. So as their name implies, they are called from the binary every time it performs an Update or Render action. In Update, the binary performs non-rendering actions, like updating the positions of walking characters, updating window positions, and every kind of calculation that is necessary for a render action, to make every kind of data up to date, reducing the cpu operations required for render as much as possible while keeping track of the time. In Render, the binary performs non-updating actions, calling only directx device rendering methods that builds up a picture of the current world, including the UI, using the current, up to date positions. If you try to count the number of stars in our galaxy to accurately simulate your star wars going on in the background of your inventory window, no matter where you do it, (render or update) you will start hurting the game. For example if you have an ui with tons of elements, generating all the elements under one tick can cause HUGE client lag. In my AE wiki, I only load one or two entity for the current page under an update tick, so it will still load quickly, but won't block the game. Notice that doing something like this is an UPDATE operation. Lets be nice and don't interrupt our rendering whit this kind of stuff. You should only use calls to render functions inside the OnRender, for example like in the ui.ListBox class, where we actually ask the binary to render a bar into our screen. Around 20% of time spent in an Update tick was consumed by the UI update (calling to a python object through the api is kinda slow by default) in the AE client one year ago. Removing the rendering and updating of the gui for testing purposes actually gave a huge boost to the client, so who knows, maybe one day someone will make a great client that runs smooth on low end pcs too. Answer the api calls if expected! Some calls from the binary like OnPressEscapeKey expects a return value. Of course if no return value is provided the binary won't crash, but can lead to weird problems and malfunctions. For example, the OnPressEscapeKey expects non-false (non-null) if the call was successful on the window, so it will stop the iteration from calling to lower level windows. So if you expect from the game to close only one window per esc push, you have to return True (or at least not False or nothing). There was a crash problem related to this in one of my friend's client recently. In his ui.EditLine class the OnPressEscapeKey looked something like this: def OnPressEscapeKey(self): if self.eventEscape(): return True return False In the original version it just return True unrelated to the eventEscape's return value. This looks fine at first glance, but if for some reason the self.eventEscape doesn't return anything and if (like the garbage collector decides to run or its disabled) the layer's or the parent's child lists changes in the binary because one or more windows are destroyed under the OnPressEscapeKey procedure and the iteration trough the child list is not interrupted, the binary will start to call invalid addresses thinking that they are existing windows, calling OnPressEscapeKey on them, resulting hardly backtraceable crashes. Closing words I can't highlight out enough times how much I like and enjoy creating new kind of UI stuff, (like animating windows that you may saw on my profile recently (click for the gif)) and because of this if you want to discuss a theory about new UI stuffs or mechanics of already existing UI stuffs feel free to do it in the comment section instead of writing me a pm to help others. Also this time (unlike for my other topics) I would like to keep this guideline up to date and maybe adding new paragraphs if I find out another common mistake/misunderstanding. DEATH TO ALL LEAKING WINDOW!!!!!4444four
    1 point
  7. [Hidden Content]
    1 point
  8. 1 point
  9. M2 Download Center Download Here ( Internal ) Hello, This time i grab an old stuff again and bring back to life: Bangsan & Imji Valley. (Jinno's and Chunjo's orc maps) Originally every empire would have had their own orc map, but Bangsan (Jinno) and Imji (Chunjo) never finished nor used. Video: -Demon Tower (Hwang Temple) placed -Heaven Cave's entrance placed -Attrs and textures corrected -Added trees, rocks where it felt too empty -Atlas dumped -Full serveride made with complete regens -Etc Everything included, even quests with the new coordinates. You don't have to make anything Download1: [Hidden Content] Download2: [Hidden Content] Download3: [Hidden Content]
    1 point
  10. My ideea is lazy and ugly, but its fast to do and has no performance impact.. i'm a very lazy person.. 1. Server-side when the duel starts the server will send a command to the client that will set a variable to 1, and when it ends to 0. 2. Use the python root variable to set a binary global variable. 3. Use the global variable to return if 1 directly where the auto attack function is, so the auto attack wont work until the duel is finished. 4. Set the variable to 0 at every teleport.
    1 point
  11. Btw, instead of adding a .SetDelay() to all objects, you could do do a simple change. for all visual ani_image from screen. root/ui.py Search for: if True == value.has_key("delay"): window.SetDelay(value["delay"]) Replace with: [Hidden Content] So, you don't have to any part of python from tutorial, just this.
    1 point
  12. As the title says, here's the simple method how you can skip the video without waiting until is finished, like official did long time ago. Here're the constants value for virtual-key codes (hexadecimal values), right now these are by default: VK_LBUTTON 0x01 - Left mouse button VK_ESCAPE 0x1B - ESC key VK_SPACE 0x20 - SPACEBAR Srcs/Client/UserInterface/Locale_inc.h Srcs/Client/UserInterface/MovieMan.cpp [Hidden Content]
    1 point
  13. Hi there, I hope this thread finds you all well. The reason of this thread is mainly the fact I grew tired of having to change the directory and executing a quest with ./qc quest_name.quest every single time, well not every single time, but you know the lines you need to go through while updating quests. Attached to this post you will find a shell script which its sole purpose is to take away that heavy load of you having to type cd /usr/home/share/locale/... && ./qc quest_name.quest every damn time. All you need to do is copy the file provided in /usr/bin and set file's permissions on 777. Now before you go bananas there are a few adjustments needed, so follow my lead. Open the quest file and change the following to reflect the path to your quest folder(i.e: /usr/home/game/share/locale/germany/quest) #!/bin/sh get_locale="arkadia" # locale name goes here get_name="ARKADIA2" # Server name goes here dean_path="/usr/arkadia2" # do not add a forwards slash (/) at the end of this variable quest_path="$dean_path/share/locale/$get_locale/quest" clear echo -e "\033[1;31m] $get_name Quest menu: " echo -n "] Type the quest name here to execute it or 'x' to cancel: " read quest if [ -z $quest ] then clear echo -e "\033[1;31m] Next time, please provide the name of the quest you're trying to execute. \033[0;0m" elif [ $quest = "x" ] || [ $quest = "q" ] then echo -e "\033[0;0m" clear else echo -e "\033[0;31m" clear quest_name="$quest.quest" cd $quest_path if [ -f $quest_name ] then ./qc $quest_name echo -e "\033[1;31m] $quest_name has been executed successfully. \033[0;0m" else echo -e "\033[1;31m] $quest_name not found. Please try again. \033[0;0m" fi fi Save your progress and now start a SSH session and after logging you will call this script by typing quest and it should look something like this: Now you can go bananas on this! If you have questions or suggestions in regards of the above, leave a reply to this thread as usual. Cheers!
    1 point
  14. I'll take the lag rather than the shitty names without Outline but ty for rls
    0 points
  15. 0 points
×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.