masodikbela

Okay I will skip on the network part lets say that's fine. (Its not, but it would take some extra effort on the routers in the way to extract it, very unlikely someone would do a man in the middle on this.) Reading the credentials on the library part is one thing and can be easily argued with even if you get caught in a shitstorm like this one you can say that its hashed with a strong cryptographically safe algorithm and done. Encrypting it then reversing it on the server side is another thing, harder to argue about, but I would say it is justifiable in some cases. On the other hand decrypting it on the serverside and saying that "ye basically I don't need it its just works like this" is not a good point in my opinion and raises some hard questions and as you said you cannot prove it in any believable way, maybe you should consider changing it to use some sha2 at least.

What I'm trying to understand is why do you need the credentials in a reversible format, if you are only doing a comparison. To be clear: I'm just trying to fact check the stuff you say and the stuff you do. Of course I cannot do that on the backend we don't see so I'm just gonna take your word for it. But again I only want to know this very thing: why is the credentials reversible if you only need comparison and why is there no encryption on the transit layer while sending raw credentials. Please explain this to me because I want to understand this part.

I really don't care about all this, just want to understand the logic behind all this, and one thing is not clear for me (sorry if it has been already answered I CBA reading all this yapping): If you only need the username/pw combo for verification, why is it not even hashed? If it would be hashed by the same algorithm every time it would be actually somewhat safe (depending on the algorithm) and the same input would always generate the same output. Also another thing I just realized: (I don't want to comment on the practice of sending plain credentials its not my business) You basically use http if I'm not mistaken which basically means all the data you transport to your server even IF you really don't store it or use it or whatever, is actually anything but secure, as it travels through the internet anything can read it. Now that is something that is really concerning.

What I would do is keep rendering the current image, then render on top of it the next image with 0 alpha and then increase that alpha over time. You can do it in the OnUpdate depending on the time elapsed. If you want something fancy you can even use some tweening so it wont be completely linear. Probably that would look the best. Maybe do that animation under 500 millisec or less. You can set the image alpha with SetDiffuseColor keeping it rgb 1.0 and alpha as mentioned before. (Maybe there is even a function called SetAlpha on ImageBox objects.) Also you can force disable the next/prev button while the animation is running so they cant spam it cus that would look kinda bad, can make it work anyway but probably would take much effort to figure a mechanic out for those cases. And if a button is disabled for like half a second noone would be annoyed about that. Probably thats how it works on webpages and whatnot. You can make other kind of animations as well like sliding left/right, you can do that as well without extra code in the binary using SetRenderingRect like how it works on gauges like the HP bar. So basically you change the visible part on the top image to be even less while moving its position to the left/ right depending on which button you click on. Either way you are going to need some interpolation in the OnUpdate method based on time. def UpdateMoving(self): maxH = self.peekBoard.GetHeight() if self.isOpen: hGoal = maxH else: hGoal = 0 currH = self.GetHeight() - self.peekBoard.GetLocalPosition()[1] normalRate = min(1.0, float(app.GetChronoClock() - self.progressStart) / self.ANIM_TIME) if currH != hGoal or normalRate < 1.0: me = self if type(me) != weakref.ProxyType: me = proxy(self) rate = self.ANIM_FUNC(normalRate) if not self.isOpen: rate = 1.0 - rate newGoal = round(maxH * rate) change = newGoal - currH if change: self.SetSize(self.GetWidth(), self.GetHeight() + change) self.owner.peekBoard.NotifySizeChange(me, change, keepScrollPos = True) self.arrow.SetRotation(-90.0 + rate * 90.0) Here is an example from one of my UI where you can click on an image which would slide open/close up like a spoiler tag. You can use the GetGlobalTime or whatever its name from app. instead of my GetChronoClock to get the time right. The ANIM_TIME is set in milliseconds that tells how much time you want to spend on the animation (like it should complete under 500 milliseconds). The ANIM_FUNC is just a function from the mentioned pyTweening library. Rate is obviously something between 0.0 and 1.0. The isOpen tells me if I'm opening the board or closing it. As you can see I also have an arrow image which is getting rotated alongside the opening animation. The change variable tells me how much should I enlarge the opening/closing board on that animation cycle. This whole function is just called on each OnUpdate. The goal is either 0 or the maximum possible height of that board. The currH is obviously the current height - the header's height because I don't want to close the entire window because otherwise you can't open it anymore as you won't see the header and can't click on again duh Oh almost forget, you start the animation by changing self.isOpen + setting the current time to self.progressStart. The reason why I have a separate self.progressStart is because if the window is not open or not shown, the OnUpdate won't be called, and the animation would stop and only resume when you open it again. Also you can force skip an animation this way if you set the self.progressStart to a time earlier than current time - self.ANIM_TIME (or just simply set it to 0), which would make the animation complete in the next OnUpdate call. Probably not needed in you case, just good to know. So yeah there you go thats pretty much it, you can apply it to any kind of animation, you just need a minimum value to go from and a maximum value to go to, and multiply the maximum value with the rate.

It is a good solution as a first step, using it to discover what functions misuse the item ownership/saving methods this way (like printing some useful stuff like what type of item is this might give some clue where to look or adding an extra help string to the class where you store function/file/line info when you unset the ownership or something like that) or checking for items in the global item map on shutdown after players have been removed might also be a good idea to discover if there are any other kind of memory leaks or possible dupe bugs because of that. But when something is violating the written or unwritten concept (like here you precisely want to forbid items with no owner in the delayed saving queue) the correct final solution is not duct-taping together the wrong parts but finding the whys, the actual reason why is something not working as it should work by that concept. (Like in this case even if its complexity wise not heavy, it would be normally still an unnecessary check IF the rules of this concept is followed everywhere as it should be.) So when at some point some function is not used correctly to me that behaviour is equivalent to a code that doesn't comply. Both is braking a concept, one the compiler's (or language's) and the other is a more virtual, logical or design concept. Its like you can use a screwdriver's handle to bash a nail into its place but that tool is not for that purpose. Thats why I don't like random timers for random actions like you can't warp bla-bla, the cache was designed in a way that whenever a player disconnects from the core if everything is working correctly no dupe and weird stuff should happen as that player cannot join to any other core until every kind of data is flushed to the db, and then only after this can other cores start loading the most up to date data of the player. All I want to say that it is really not a bad idea as a start, but you have to go further than this if you want to correct the underlying mistake. (Not just here, but in situations like this, and I think this mindset is what helped me the most in my programming journey, just wanted to tell this as someone might find this useful.)

I would avoid deleting the item instantly in SetCount in every case as it would be a valid scenario to remove the item from the character for some reason, change the count (to something larger than 0) and then give it back to the character. Deleting it if its count reached zero however regardless if it has an owner or not could be a good idea and if care was not taken in functions that disrespects SetCount's return value (it returns false if the item has been deleted) then sooner or later these parts will reveal themselves in a form of a crash, and probably in most cases it is already happening regardless of the change (by default there are some parts with use-after-free cases for logging like you said). I use SetCount(GetCount()-1) in most cases even if I may know that the item is not stackable, its more future proof when someone wakes up with an idea to make that item stackable.

Rarely can say this but an actual good catch! Besides the dupe it also causes memory leak as the item will never be destroyed. Very similar to the item move dupe. Might be also a good idea to put an extra log to SaveSingleItem when its executed on items without owner, as its already sus and I can't really think about a good scenario where you would intentionally like to save an item without an owner. Also not so sure about the "this can't happen on a regular server" part, as nothing is guarding against this besides the delay which you can easily bypass by closing the connection instantly and logging back in. Also the delayed save might be different on each server and if its longer (I think by default it is) than 10 seconds (the delay you probably have after such actions) this can easily happen. Like I said all depends on the timing.

The selection (and probably the coursor movement as well then) is not bidi aware there, thats why I said proper.

Original aeldra never had lycan. Thats right, its got leaked late 2018 and ppl started to sell my wiki from it around 2019. Apart from that there is a really easy way to distinct if something is from the latest aeldra files or not, as no other server has text selection and proper bi-direction text implemented as far as I know and it was fairly new in aeldra from around May 2022. Just open a PM window or normal chat window and try to select/copy texts from it or pasting texts containing both english and arabic texts. Apart from the code other assets from the client have been extracted many times before its closure so thats not an indicator that files have been leaked.

There was a correction today after many years past the release. There was a heap-use-after-free bug in the regen_free_map function, which means that the regen struct has been freed and after that in the increment part of for-loop accessed this deleted struct for the next regen in line. Normally while its not safe, it still doesn't cause any issues since the just-freed memory part is not overwritten yet, but in rare occasions it can happen. Also with debug mode or debuggers using shadow bytes to detect such cases would immediately notice it. This might have been the reason while my vs debugger got stuck back in the old days. Thanks to @ Karbust for noticing this problem with address sanitizer.

Sure it will have the same affect.

As I explained in details in the "How does it work?" part, there is nothing really to fix in the update function. The main problem is that the newly created item overwrites the original stack, and doesn't remove it properly from the core, creating an actual memory leak and later on loading the id is inside the global id map thus preventing it to be created again. But besides all of this putting an item to an occupied cell is an invalid operation and should be always prohibited.

Hi there devs, Its been a while since my last topic, and the reason for waking up from my eternal hyper dream is no less significant than a small possible item dupe exploit that is present in the original leaked source, and therefore very likely still present on most of the active servers including the official. I've seen topics from late 2021 where this bug was abused on prestigious international servers, so its for sure known by some people for a long time, moreover even a related partial fix for the exploit is already present on the board: How does it work? How to fix it? I think I filled my quota of talking in the how does it work section above, so without further ado:

Not 1:1 the same, but works well.

Alright lets see your points: Indeed sus, but on the other hand, if you think about it: how can you actually get your toplist well known by players if not convincing an actually running server to give some thoughts about using their site instead of other already existing and already popular sites. As I'm aware by that time there was no other running toplist that was actually trustable and were not already proven to be corrupt in some ways (purchasable votes, easily bottable or something like that). If I would about to start a toplist I for sure would go try convince a big server to consider switching their primary vote for buff system to my site or noone will ever know about my site. (For example see m2devs toplist, literally noone uses it as far as I see.) This is a vague topic since probably as many ppl as there are will see it differently, as for me I don't see any similarities, the serverlist's logo (as well as the whole design) looks really oldschool, couldn't even compare it with any other server's I know about. I'm clueless about web development (and if you ask me its work of Satan himself so if he exists he is definitely the real brain behind it). From what little I know I could imagine this might even be some kind of framework generated code or something like that no? Like I said I'm clueless so rather not guess anything else on this point. I can only say the same thing as I did on the first point. All in all I can definitely see some kind of connection between them, so being in partnership at least seems to be very likely and actually would be very logical since the aforementioned points. However these are no proofs to that the toplist is owned by the same person/team. As far as I'm aware the toplist is owned by Zerial, and I can tell that for sure that he is not the owner of Aeldra. I don't see much point of this topic, there is no actual hard proof, the only thing I can see is the likely frustration of the author whos' probable interested in other concurrent toplist that is slowly losing popularity to this toplist. If the site turns out to be corrupt as the others (favouring specific servers, selling votes or so) then bring us some proof and I will grab my pitchfork and join the crowd.