masodikbela

Me upon opening the topic: https://static.wikia.nocookie.net/darkestdungeon_gamepedia/images/3/38/Vo_narr_town_backstory_19.ogg

At this point I must say that there might be some real scam going on in the background. Here is some more evidence:

Looks like some of you need some opening the evidence. But fortunately if needed.

And this would be the moment when I would just send back his money and block from skype. (probably somewhere between around the 5th or 10th call in a row)

I've tried various ways to keep the lambdas somehow, but always ended up having extra references to self because of it. Never really liked lambdas in python anyway so I gave up on making them work easily so didn't dig much deeper than that. But of course this doesn't mean that its not possible to keep them so the best way to do some tests, try out some ideas and come to a conclusion.

Detailed information about #6: As you all aware, the resource loading is not async. (like @IceShiva said it earlier) There are 2 types of resource loading: Ask the packer tool itself (eterpack) directly for some file (this could be any type of file). This method will always block, so it does not cache, and by default (using eterpack) it always read from the disk (it uses mapped files so its a little bit better than directly reading from the disk, cus some sections could be already cached inside the OS). Ask the resource manager to load a resource. Only some type of data can be used here (images, .sub, .mdatr, .fnt, .gr2, etc). There are also 2 scenarios: If the resource already exists inside the cache, it will directly return with the loaded data. If the data is not yet loaded, #1 happens, but it will cache the data. There is a time limit for unused resources to keep them cached. Once the limit has been reached and still nothing uses it it will unload the unused resources. The problems When a new player arrives the motion files are not cached (not the .gr2 files), so for every player it will try to use method #1. When you meet a new player/mob with uncached models (armours, weapons, hairs, etc) the game will use #1 due to the reason explained in method #2 scenario #2. A proper solution: Make it async! This would mean that you have to provide a callback every time you ask for something. You will have to change lots of stuff, mostly in python part, to handle async loading correctly. For example the python UI sometimes depends on other element's size. If the image is not yet loaded, then it would mean that its size is 0x0. You could however for example tell the UI that okay, preload the images first, then if everything is loaded then you can build the interface. Here is an example:

In the building section in the docs it says that only the following boost packages are required: boost-convert boost-log boost-system boost-filesystem But cmake cries for boost-program-options too, that should be corrected.

Sounds good. It would be also a good idea to create a way to add bots or something, simulating actual players/connections for performance testing. For example building a very lightweight console client while developing the features that you can run on bsd servers to simulate 1-2k or more players, or if there will be separated processes for player instances on server side this may won't be even necessary.

I'm eager to see the actual plans for the architecture/layout of the server, like how will the player/client instances handled on the server, like maybe new processes per players for handling the whole sessions until they disconnect, fully separated from other things like handling npc movements, etc, maybe something similar to that spatial os thing you once mentioned on the discord. Anyway its a good idea and I'm definitely looking forward to it, but of course it (probably) has a very long way to be complete and anything could go wrong during this time, like losing interest in the project, etc...

Thats not a problem either, its called static object. It won't be created more than once (or more times than it gets deleted). There are 3 windows by default that are static as I mentioned already in the guide. So in the terms of "leaking" windows its not leaking, but of course it doesn't mean that using this will produce the expected result. After the first warp the number of leaking windows will contain the static windows, so to get the correct result you have to teleport 2 times, and the 2nd result will be the accurate one.

This is not a problem, because if GameWindow is not leaking (and also the button class itself is not leaking) the button will be deleted after the deletion of GameWindow, so there is no need to do xy = None or del xy in the __del__ method. Its generally not necessary at all, the reference number won't increase by setting parent of a window, it increases when you save them into a variable of a class or into a global var. Here is an example from the python command line: >>> class stuff1(object): ... def __del__(self): ... print "del1" ... >>> class stuff2(object): ... def __del__(self): ... print "del2" ... def __init__(self): ... self.something = stuff1() ... >>> a = stuff2() >>> del a del2 del1 >>>

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

Probably thats not gonna happen, I don't think that its good enough to make a release about it on this forum, also there are better alternatives already published here, also lost the changelog with the fall of that forum.

I don't know about this, and I highly doubt that packmaker is infected, since its basically only one cpp, all the other files (or libs) are from the original binary. Btw there was a little mistake that @xP3NG3Rx pointed out, so I updated the last version with the fix.

For me it looks like its just how the animation works... so basically the combo_01 and combo_03 works, but the combo_02 doesnt work because of the collosion data: -> this is for the 01 and 03 which I think does damage, if you imagine the horse under her you can see that its correct, usually collide on the side and on the front with the monsters this is the same from another perspective this is the combo_02 which I think sometimes doesnt do damage on the front because its too high and doesnt collide with the height of the metins So I think its nothing to do with speed, simply its just "visual", cus when the attackspeed is slow you may not notice that the second animation doesn't do damage, and when it becomes faster its more obvious that something is not right.

The second one is totally wrong and causes double deletion.

Although I like the idea very much too I'm a bit sceptical. I think in the very end this would not affect very much the amount or the quality of the newly created releases/topics. Those who make releases time to time would keep doing it anyway (surely this would give a little mental boost to most of them) and those who don't do this because of a reason (no time or don't want to participate in the community with ready to use systems, etc) wouldn't do anyway. As for myself, I would definitely have more affinity for sharing stuff but even though I don't think that it would reach that level when I would actually start doing so.

So: the discord server got deleted and now you don't share a server and you are not in his friendlist or you have been blocked by him I would say its the first one, so its still not a proof. You are very far from the truth if you think that gf has anything to do with AE. Everyone can make theories, but thinking that you have played any part in this incidence is very delusional.

Oh please... this is the biggest bullshit I've read so far in the past days, its like when you buy an ice cream, then you get shot in the head and someone says that HE DIED BECAUSE THE ICE CREAM WAS POISONED.

I don't really see the problem here. So far I use this method only in the aeldra wiki, where I always use a normal base window (which is transparent) as a "peek window", and a second base window (which is also transparent, but contains all the stuff, could be very large). With the first window I can control the size of the visible area, and I put all the stuff onto the second window (so thats the parent window of the real content). Without that obviously you will use the size of the parent window which includes the edges in this case and it will feel like it goes out of the window (but in reality it doesnt).

I couldn't have explained it better myself.

Obviously I have it, but its not for sale or anything like that. I think I already explained how does it work here: Also wanted to make a video talking about the making of AE's wiki, which depends on this feature, but unfortunately didn't have time to finish it so far.

One of those very rare moments when you can actually read a well explained non-bullshit release on a metin2 dev forum that follows a logical thread written with decent language skills. Can't believe my eyes.

[Hidden Content]