SKay

I approve of this. I'll clean up the source code that I still have on hand and publish it on a GitHub or something tomorrow or Tuesday. Still works but the MEAN stack I was using is probably a year old at this point. Actually wait: I disapprove of this. EDIT: The original description is a load of wallop, so mindful of that, here's my updated description: "The APB HSL System is a method of colour reproduction using a subset of the HSL colour reproduction standard The standard HSL system is a representation of colour using Hue, Saturation and Lightness to achieve a specific colour. However, as the APB HSL system is a reduced value subset of standard HSL, the values are condensed down to bands of values, which means that true colour reproduction for most colours is just out of the question. Take for instance a greyscale image in your favourite image editor, and shrink and expand it several times (this mostly happens in Paint which does not retain sub-pixel data). You will see a lot of colour banding, and this is how APB HSL works. Normally the HSL system can accept 3.6 million values for colour (360x100x100), however the APB system only accepts 4096 colours (This would be 32x8x16). This colour banding reduces the likelihood of 100% accurate colour reproduction to almost zero, due to the loss of 3+ million potential colour values. This can be circumvented by using opacity in game, but it would be outside the scope for this tool. The calculations are: int[] calcHSL (int& colour) { // Assume colour is 0xFFFFFF return [ std::round(convert_to_hsl(*colour, "h") / (360/32)), // h std::round(convert_to_hsl(*colour, "s") / (100/8)), // s std::round(convert_to_hsl(*colour, "l") / (100/16)) // l ] } This allows for a massive reduction in the potential cost of texture memory being mapped and used (APB already is hitting a wall on the current engine with how much memory it can keep in use at one time). 4096/3600000 = 1.13% of the original footprint, or a potential memory saving of 98.87% from what it could be. However you lose fidelity in the amount of colours at your disposal, and it can lead to a fruitless search for one particular shade of pink, or purple, or red, or green. It can get close, but it can't ever truly get there."

That's pretty fair feedback. Unfortunately I just lost my trail of thought halfway through, and given my stress levels it bore down on me. If I do another Q&A/Stream, it will definitely be better rehearsed. Unfortunately making small mistakes throughout threw me off, I was essentially a walking anger bag (at myself) at the end. I just could not think. It will be better. I will be better. That's the least I can do to give back to the community.

Bump. This website has been restored! I forgot to do it for an age and the box it sat on was having a fit, so a re-install and a upgrade later it should be available... well until I forget it again. I'm currently working on a colour picker based on an image import - i.e you pick a pixel on an uploaded image and it'll give the closest as sheer possible APB HSL colour. Please remember that APB's HSL colour subsystem is that - a subsystem. No matter how hard you try, there just cannot be more colours squeezed out of it. Unless you perform a colour gradient workaround... which leads me to my second WIP: Colour in Colour preview, or CIC for short. It's been a thing for ages that content creators for APB use the inbuilt opacity slider to adjust the output colour. This is in effect using a RGB-like system to give more colours. However as it stands, it requires a lot of manual trial and error to get a desired colour. My work aims to get rid of this limitation. At least, hopefully. The theoretical maths means that the shortfall of 4096 colours is essentially eliminated. If the opacity is set correctly for both layers, the 4096 colours becomes potentially 16,777,216. This is essentially emulating 24-bit colour, which is the equivalent of 8-bit RGB. Snappy! This might take a while of figuring out the best way of doing it, so it's going to be teased as I go along. But hopefully before the start of summer is the planned date when it'll get released. Watch this space!

I forgot to weigh in on this thread when this was originally posted. Better late than never. The reason why EAC disables manual editing of CPU Affinity/Priority for processes it attaches to is for security reasons. For most games, EAC is considered a child process which starts and hooks into the game where necessary. On start of a child process, the child process inherits the parent process Affinity for simplicity reasons on Windows. Very rarely will you ever need a child process to access more processing cores than the parent process, and also simplifies data access across processing cores. Setting process priority higher for the game process should not be necessary. Very rarely does it do anything, and has much wider implications. To quote this article's answer on Stack Overflow: "A realtime priority thread can never be pre-empted by timer interrupts and runs at a higher priority than any other thread in the system. As such a CPU bound realtime priority thread can totally ruin a machine. Creating realtime priority threads requires a privilege (SeIncreaseBasePriorityPrivilege) so it can only be done by administrative users." Any process that has real time priority essentially can get ahead of anything else, force other threads to wait until they are done and are one level below the Operating System in terms of priority for CPU time. Perfect if you wish to have your game squeeze a frame or two, or if you wish to get your cheat to circumvent EAC detection by bypassing it altogether. And as for forcing CPU Affinity/Priority through Registry Edits, this is NOT SUPPORTED by EAC at all, and has resulted in bans for EAC circumnavigation in other games. You perform this Registry Edit AT YOUR OWN RISK. As far as this RegEdit is concerned, it would be considered circumnavigating an EAC safeguard.

A ban is not handed out without reason. The fact that @MattScott has said "Customer Service deleted your graphics library after getting my approval." should be an indication that you made graphical designs that were against the Terms of Service. You were obviously warned by a GM, then ignored the warning. When a GM tells you not to do something, do not neglect what they say and try the exact same thing again.

Almost like Ketog is enlightened. Or maybe he actually understands that ARMAS guns are variant guns. IR1 is an insult to anyone who bought it. HS3 at least justifies the weapon's existence.

Bump. Don't worry, it's for a reason. Slightly newer machine the webserver sits on. Now includes a re-write. This is Version 1.2, but it's also only the beginning while I actually write code that isn't chicken scratch.

I heard a rumour. The rumour was SuperToaster is actually SuperSuperToaster.

That would just end up back to the old behaviour, especially seeing as most stages are 4+ stages long. So this does absolutely nothing other than even making it worse for lower skilled players.

That's... that's me. Yeah. I voiced a few (and wrote the script of several) of the JMB videos for SlimTheShady back in the day. This is indeed one of them.

I created a video "advertising" the N-TEC 7c "New Glory". Just as a personal venture into content creation after being inspired by content creator Ahoy. For me personally it was to get back into content creation again and to try and achieve a level of professional quality. As well as a sort of experiment into how I want to contribute video's going forward. Hope you like it.

I'm presuming you're downvoting the post you quoted because of this image of a fair amount of zombie processes. The post I put up explained what these are, so I'm not sure why you're downvoting it. To quote myself:

The APB_Catcher is the process that handles exceptions thrown by the main game executable. Contrary to what OP states this process is absolutely necessary. Without it the game can potentially crash in a way that is not graceful and can cause issues beyond that. The APB_Catcher is a child process, i.e it's parent (the main game executable) is responsible for handling it's execution and termination based on it's own run time. The issue you're seeing is to the fact that the APB_Catcher process is not being terminated correctly by the main game executable, resulting in a zombie process. A zombie process needs to be terminated manually or by a program that is designed to determine any dead processes. Also instead of pinging Matt Scott directly, maybe leave a bug in the proper place. For like the 100th time. - SKay