Hello! This is my magnum opus CPACK for the most part. Though it provides very powerful units so be sure to include some tough enemies and lots of Creeper. You can find some tougher enemies in my Vertu'sCreeperBuildings CPACK which you can download from this forum page: https://knucklecracker.com/forums/index.php?topic=41251.0. Just be sure to disable PAC mode in the CPACK as accessed from a Global Script called PAC CONTROL.
See the link below to visit the wiki page for CPACK information and see what the VAU CPACK is all about. Lots of information is over there.
CPACK Information page: http://knucklecracker.com/wiki/doku.php?id=cw4:cpack:docs:7f65b557-95b9-47d0-807a-5d05b1b426db
I am always open for feedback and suggestions, you can message me directly to this forum account, comment here, or throw an @ to me in the Knuckle Cracker Discord. I very much enjoy constructive criticism and feedback and would always be happy to hear the opinions of others and the ideas created by them.
I am a very experienced 4RPL coder, there is little I can not do.
V2.7.3 Major rebalancing, refining, and improvement update. The holy wall of text has been summoned!
Spoiler
- Performance enhancement for all VAUs to call RefreshLOSCashe a lot less.
- RESTOCKv now requests ammo as a method to check if it's connected to an energy source. It will use the ammo and if it reaches 0, will tell the VAUs to restock at the RiftLab.
- VAUs will now always restock at the RiftLab if a RESTOCKv beacon is unavailable or offline.
- The RESTOCKv beacon auto-sets it's build limit to 1 if undefined (less than 0) though only after the first ran frame or on Gameload. Leaving a small window for you to place multiple for any miscellaneous reasons and no worries if you forgot in the past to set it's build limit to 1 as it's now automated.
- It has became clear to me that there is nothing wrong with having more than one RESTOCKv beacon. They all simply fight to define the same variable only once being done in :Buildcomplete, :Gameload, and :Destroyed (which sets those variables to -1, -1) along with a special case of if the beacon runs out of ammo. Having multiple RESTOCKv beacons does not break anything at all but for all desire for simplicity and convenience, do not try to stop the CPack from setting the build limit to 1 for the RESTOCKv beacon. Multiple RESTOCKv beacons may even be supported in the future.
- Some slight changes to the MBF, Fighter (VGPSF), and R-Fighter (EXP-VRF) models (besides the return of originally intended textures)).
- I got the originally intended textures of the Fighter
and R-Fighter (not the R-Fighter, was a bit too excited and gave it textures it didn't have) to work out!! I am very pleased to say that they both finally possess their originally intended appearance. - COMPLETE OVERHAUL TO THE VAU'S BALANCE! Only the Battlestation and HCPPCAS are unchanged. Ever since I made the technological advancement of converting from using potatoes for CPU to a beefy apparatus, it became VERY clear that the VAUs where COMPLETLY AND UTTERLY OVER POWERED. Now that I can see everything unfold faster than 20/30 FPS at the best of times I was able to actually witness the shear Creeper killing power of the VAUs. In response, their damage has been COMPLETLY REDONE. They also tend to use less ammo per shot now too.
Details:
Damage per shot reduced. (Typically halved).
Damage radius per shot heavily reduced (where way too big now having a better idea of how important damage radius is when it comes to kill-power).
Fire cost typically reduced (normally proportionate to damage reduction).
Minor changes to fire rate for some weapons. - Added formation AI to the Fighter AI in an external global script. Fighters also include new AI modes of which being LEADER (fighters with AI enabled will enter a formation around the leader fighter while that leader fighter has the targeting AI of Hunter, Rouge, or none as chosen) and INDEPENDENT (the fighter won't enter formations even though the AI is in control of it and possessing the Hunter or Rouge targeting AI as chosen).
Formations are:
- Square: 3x3 square with the leader in the middle.
- Circle: Same a square but in the shape of a circle.
- Cross: An "X" shaped formation with the leader in the center.
- Converge: All fighters within the "formation" will remain around the Leader in no particular formation, simply being around the general location of the leader.
- Redone the VRF's health system. It now has a casual 225 HP. 25 in hull, 200 in shields which regen at a rate that's not impossible to overcome.
- Default caps redone. There can now be a max of 4 Autostations and 9 Fighters by default.
- Summoner UI text now updates to changes in caps. Much of it's text is now defined within the Summoner script so no more need to manually change it.
- Some general rebalancing of health.
- V-Battlestation now stuns units next to it's cannon shots on impact. This includes both enemies and friendlies but is a minor inconvenience. The Battlestation will vaporize enough Creeper in a single shot for the units to recover from being stunned before Creeper runs into them unless it was Crimson or A LOT of Creeper. Just something to consider.
- Increased health threshold for when a VAU starts to retreat when in AI mode.
- Altered damage effects a little to be more cumbersome.
- Some alterations to the retreat sounds and effects of some VAUs.
- Various script optimizations to have less lines of code run per frame. Usually using "if(GetGameUpdateCount % [NUMBER] eq0)". This should help a good amount for slower computers that start to lag behind from the amount of code ran per frame. This also means the VAUs are further noticeably optimized when a strong computer runs the mission.
- A potential bug has been found to make the VRF shoot laser missile volleys twice. This however was discovered during some tinkering with that very weapon in the VRF's code and has been seemingly only from that experimental code.
- Added a special PAC_MODE disable variable in the Governer global script. Only utilize if you are semi-experienced in 4rpl and or coding in general.
- VAUs are now 100%/100% PAC compatible, including the V-Tesla. Once you set PAC_ENABLED_FOR_VAUS to 1 (aka "true"), the VAUs (including the V-Tesla in theory) are perfectly PAC ready and the CPack will even remove the Summoner and RESTOCKv from the build menu (only when the mission is loaded outside of the editor).
- Heavily updated the forum-post's information.
- The VAU CPack has reached over 10,000 unique lines of code!
- The UnitSpecifiedTarget marker (that gray line that appears for the Thor and Bertha) will now disappear upon the VAU being deselected (only when deselected) or the VAU is in PAC_MODE because a bunch of gray lines going everywhere through terrain and is fully opaque is just a horrific eye sore when there are 9 Fighters buzzing around. The paths will only show again when the VAU is selected.
- Potential plans for adding another VAU; The Vertu Fighter Frigate (VFF) which will play a support role for other VAUs and be an extra important unit in PAC maps that use the VAUs in PAC_MODE.
V2.7.4-Corrected texture of the R-Fighter (whoops).
-Altered colors a bit to be more accurate. From now on, the greens will be replaced by their correct shade rather than lime green.
V2.7.6-Fixed the VAU Social AI global script to work in PAC_MODE again. It was a simple fix that I only noticed after they where being used in a 2nd VPAC in the making ever since V2.7.3.
-Many minor changes not worth mentioning (V2.7.5).
Performance note: [Rant Warning]Spoiler
I view laptops as... *sigh...* in a brutally honest way.... Utter trash compared to the capabilities of a tower.
So please understand that a laptop will have a very difficult time running maps with dynamic CPacks like the VAUs CPack.
I have done my best to optimize the VAU CPack more but if you are using a laptop then you need to understand that it's not my CPacks that make the mission laggy. It's actually mostly the scale of my maps such as something so simple as how much Creeper in on the map, not the fact there are 10,000 lines of unique code when only say.. 3,000 run per frame at a high estimate. A laptop lacks the performance efficiency to benefit from my efforts of optimization so at the end of the day please consider what you are using to run not only this CPack, but any other CPack from any other map maker.
I don't care how "good of a laptop" you have. I am not budging on my perspective of (Computer Tower >>>>> Laptop). I have experience in this perspective.
I have done my best but there is only so much I can do, for A) Laptops have massive hardware limitations requiring possibly far unmeetable levels of optimization. And B) I am only a modder of a game that heavily supports and integrates modding. I can't go and try to optimize the deeper code of CW4, that would be called hacking and the game is already very optimized while making it's modding compatibility very user friendly, efficient, and useable/yielding. Plus, KnuckleKracker has levels of experience that would drown any levels of experience I possess so it is rather safe to say that the game is already very well optimized.
I have seen what an unoptimized game looks like and what a performance heavy game looks like. And CW4 is not anywhere close to either besides being potentially performance heavy from a massive map on a scale like PAC Prospector Fortress which will crush any laptops' hopes and dreams of not exploding. In fact, I even got called out for how performance heavy PAC Prospector Fortress was when a person's laptop experienced performance overload mean while my 8-year old computer from the age of the dinosaurs was the computer I used to create, finalize, and publish that map.
Performance note summary: Don't expect laptops to be mobile mini super computers. They have no hope of being anything close so I can't make my maps and CPacks laptop friendly when I need to optimize everything to unreasonable levels.
VAU Forum-post updating process insight:Spoiler
This forum-post including the CPack download will not be updated (unless some nasty bug(s) need patching or some hole(s) need filling are found after an update to the CPack is placed onto this forum-post) until the CPack has went through enough changes to be in any sense, meaningfully different to the current forum version.
Every time I complete a coding session on further developing the CPack in some way, I increase the version by 0.0.1 depending on how significant the mini update was. Typically a very, very, minor bug patch or change in code/behavior will result in +0.0.1
A rather lengthy mini patch that adds a good 20 or so lines and/or a semi-significant behavioral change will result in an increase > 0.0.1.
When an large change in code or behavior is finished. The version changes by +0.1 and resets the minor version to 0.
This typically is from a coding session that lasted for over an hour or two and/or added a new behavior/change to the CPack that makes it's contents be noticeably different than in previous versions. An example of this is the addition of formations in the VAU CPack that only applied to PAC_MODE. This was found to be too minor because it only applied to PAC_MODE, was new, and not fully developed to the planned end result. Only when the addition of formations included non-PAC_MODE and was refined, furnished, and given finishing touches would the addition of formations be significant enough to warrant an update to the forum-post.
A change in the major version (X.0.0) means that version 1.0.0 is basically unrecognizable to version 2.0.0 in development. This is very rarely incremented past V2 as V1 would be the most unstable, being new and fresh. It wouldn't take much for some revolutionary change to occur and increase the version to V2. Changing into V3 however is substantially harder as V2 tends to have the most potential work to be done much like for the VAUs, now V2.7.3. V2 very easily just grows and grows with no massive revolution. A VAU V3.0.0 would be on the scale that space combat would be a fully functioning, stable, optimized, and applicable thing where VAUs could fight enemies up in space and the planet's atmosphere/ground (where they currently mostly reside and fight).
And finally, the forum-post will be updated if the latest version isn't changed for a good while and is stable. This is proportionate to the difference in version number. The more different, the less amount of time needed for this to happen. The less different, the more amount of time.
STILL have no idea how to do images. :(