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

You're now proving my point, thanks. Experimentation with changes is the aim of the game, trying to see where they could push the RFP to. They never said "woops we messed up", that'd imply a mistake was made when they were experimenting on where to place the RFP. It was never pushed to the LIVE action districts, it was in a closed off area where the testing of the changes was encouraged, yet no chance was given by the wider community for the aforementioned reason of "they thought they knew better". There is 0 excuse for not testing the changes. You think they were off the mark based on the stats. Did you test them? If the answer is no, you can't just assume your viewpoint is correct. If you're not willing to even bother confirm what you think then this rodeo will continue going around in circles and you will not get your stats. If you want stats, you gotta put in the work. Don't just assume. Confirm.

You really do need to read the patch notes son. This kind of whinging is the kinda thing I'd find from a baby stuck in a pram. A direct quote: "In both districts these guns will both now prevent you from weapon swapping while the re-fire or burst fire timers are active." This is the same treatment the HVR got. It prevents you switching to a sidearm while the action is engaged, i.e you fire, and have to wait for the burst delay to be passed before being able to continue. Please don't make threads as if the forums can be a place for a cult of outrage. There is a thread specifically for this kind of material right here. And that is where it should be.

Except that hadn't happened before when the exact stat changes were given. No-one bothered. Not now, not even back in the day. No issue with giving stats at a later date to give time for blind testing. But the effort needs to be put in first by the community. Armchair stat scrutiny is the main reason why a lot of APB's items are as they are. Because people thought they knew better and didn't bother actually testing.

And that's exactly the reason why you should test the changes when the servers come back online. Armchair stat scrutiny helps absolutely noone.

Hi Nerima Sorry about the delay. Just got alerted by @CookiePuss to this thread, even after tagging me in it days ago. Sorry about that. Hopefully the in depth explanation and discussion to nerd over makes up for it :P. If you haven't seen it already, I would recommend looking here to see the work I did for performance testing Ryzen CPU's in action in APB @ 4K in both the current engine and the upcoming Engine Upgrade. Spoiler: they work quite well. The graph listed is the same graph provided in the thread linked above but just a bit higher clarity. Now with this graph, I can say personally that either AMD or Intel for your CPU choices would be equally valid, depending on if you're using the system just for gaming, or for more. There are anomalies that both Intel and AMD suffer from, which I will go into once appropriate. Before all of that, I have to go through the current situation. The current situation As of right now, APB is a tightrope. A lot of the problems that players face today are from how tight some of the constraints are, and how the main game thread is tied up as soon as something happens, and with little relief until the task executed is complete. The biggest problem is the Garbage Collector, which is one big double-edged sword. On the one hand, it allows the game to run. On the other, it can make the game run extremely poorly. It's necessary for the 32-bit memory constraint to work, but at the same time strangles the main game thread every sixty seconds as it does a fly-by. Unless you are willing to edit the GC settings in the files (don't, it's very easy to get it wrong), you will suffer with everyone else on the matter and soldier on. This is something that all platforms suffer from, you're not getting around it. But more than likely an even bigger core problem to APB is that it does not support multi-core. It can use more than one thread, however it cannot scale past two main threads, used by the game executable itself for the main game thread and the render thread. This does not include child processes like Vivox Voice Service and the APB Exception Handler (APB_Catcher). APB historically prefers clock over cores, but can benefit from running on unique cores. This, again, is something that all platforms suffer from, you're not getting around it. The two issues I've listed above would be rectified with the Engine Upgrade, that much can be said. So you're going to need to look ahead... The look ahead In the future - APB will largely be a much more "fair game" situation, where the user will be able to not experience drops every time they look at LeBoyce's awesome afro. Oh and also not crash every time the memory map is exceeded. So your choice should be influenced by that. With that in mind - looking ahead to your potential CPU choice would be moving to a new platform regardless of what you do. Unfortunately that is the way of the world since forever for Intel, and a move to AMD would require it anyway for AM4. Let me outline very quickly some bullet points on both CPU manufacturers (i.e benefits and drawbacks, with APB specific items marked) Intel Pros: (For APB) It is currently seen as the best CPU for the current engine, and it can push high framerate. Up until recently was still superior to AMD for gaming in general More established second hand market Cons: You are required to purchase a new chipset & motherboard if you want to upgrade Prices are very high compared to AMD offerings 14nm++++++. 10nm has been so slow to market, that 14nm was recycled again and again. Aged well, but it's not worth it. Expand-ability via PCIe (for NVMe SSD's etc.) is limited on the budget side drastically. You need to fork out hundreds for more PCIe lanes. AMD Pros: You are not required to purchase a new chipset & motherboard if you want to upgrade. Ryzen 3000 is essentially holding parity to Intel for single core performance Multi-core Ryzen is vastly superior to Intel multi-core. Much cheaper CPU's for much more cores and now similar performance Cons: (For APB) Can have inferior performance by a few percentage points (Ryzen 1st Gen) May not have an organic second hand market yet (it's getting there though) Overclocking is essentially not possible past a certain point. Mild overclocks are possible but more substantial offsets are limited to LN2 cooling. First Gen X370/B350/A320 motherboards can be junk in terms of quality. 3rd/2nd gen boards are A-OK. As you are going to a new platform in any regard, I would personally recommend you get a Ryzen 3rd Gen CPU (3600, 3800X or the 3900X depending on your budget), simply because for the price, you will be getting into a platform that can be upgraded past one single generation which would be very important if you just want to upgrade a CPU down the line for instance. Intel for the price really isn't competitive and even though the 9900K can be competitive in gaming, if you do content creation (I assume you do since you got a Mac), the performance of the AMD CPU's in that space is second to none. Again, it is down to what workloads you do. Hopefully that helps a little bit. If you need me to answer any questions past that just mention me and let me know specifically what you want answered. And that goes out to anyone in this thread. - SKay

Just for anyone who is curious, I've done the math. And it creates a graph like this: Orange is the proposed changes at range, blue is the current range. Range is at the bottom. In short: The proposed changes will mean the RFP-9 will take a longer time to kill, but will be able to reach out a much longer range in tandem. It's magazine capacity is of no consequence immediately.

I want to say I didn't laugh hard at this simple post. But I did. Goddamnit

One word: Stop. Stop with this broken English harassment for no reason. Stop.

The backend is the blanket term used for all services not maintained by the end user, such as user information storage, networking infrastructure and CDN, server capacity and server hardware. It's the equivalent of going behind the counter of a shop and being a cashier. The client should under optimal circumstances be able to use the software as is designed and without hassle such as downtime. There are multiple layers in which you can distribute server hardware, from creating database VMs to bare metal game servers. Each server is given one or more jobs, such as to be a network entry point, or being a database instance or such like. They could theoretically set it up so that everything is hosted on the one server (which is not a good idea at all). A RAID controller in this case is mainly used for storage servers and database instances where backups are extremely critical, and where losing records just willy nilly is literally not an option. By definition a RAID controller is a specialised controller that is able to push more Read/Write IOPS (effectively how fast we can read or write) to a set of disks under the control of the RAID controller. You can easily get RAID cards these days for not that much expense, but for RAIDS controlling two dozen drives, its still quite expensive. Also this has been said many times in the past, not just here but in a global context, but it's always worth repeating - throwing hardware at a software problem really only gets you so far in regards to server performance. You would need to enable the software to be able to take advantage of newer hardware instruction sets and architectures, not just bankroll on IPC increases and clock count.

After LO took over the running of APB, a lot of people had been understandably waiting on some form of movement on the meta of guns and gun game play, especially since they had been issues for the longest time in many peoples' eyes. However all threads on the issue have been threads with more so complaints about the issues they see with a particular gun, and aren't helpful in bringing the issue of guns to a satisfactory compromise. This is the purpose of this thread, to try and start a conversation on what potential changes the community might want to see in the current set of guns, and why they would like to see them. This thread would be very long if we took a look at every single weapon, and to keep it from being that long, this is a look at the "Big Eight" (in my opinion, good or bad) of guns, break them down into problem statements, and give potential solutions. The "Big Eight" would be considered as: N-TEC 5 RFP-9 CSG NFAS Obeya CR762 OBIR OCA-626 HVR 762 (Yes it's on the chopping block) NOTE: I am not discussing grenades here. That's a topic for another day. Just want to test the water and see how the community wants to discuss things. Before I discuss the weapons listed above, I want to explain a few of the statistics that most people talk about, and some I will be using, so that everyone can join in, give their own opinions, and critique mine and suggest counter-examples: In each of these cases, I will be using the following format: And I want to stress before I begin - these are my own opinions. They do not reflect anyone else's opinions but my own, and I've thought of the following changes under my own steam. With that, let's begin. N-TEC 5 RFP-9 CSG NFAS Obeya CR762 OBIR OCA-626 HVR 762 So... that's my opinions, and is my own only. What do you think? Do you agree with what I had? Or did you feel like I was too harsh, or too soft with some of the changes? Remember - these changes are all just theoretical, an attempt to get a mature conversation started on them. It's now up to you all how you all want to proceed. I'm looking forward to hearing what you all think.

Hey there, While it's great to see others wanting to report bugs, it's important that a format is followed - we can't really determine what 90% of the issues are here. As you say yourself, you want these bugs fixed. It'd help immensely if you followed the guide listed here and give us a detailed report of the issues you are experiencing. Also Please don't incite drama in a bug thread. This section of the forums should be apolitical and no drama. Leave that at the door.