=VG= SemlerPDX

We have indeed discussed that - and sadly it is not possible to code a variable bot spawing force, or any such automated system that can vary with player numbers. What we can do, and what still requires a bit of work to even make possible, is to make a more easier maplist setup that must be MANUALLY initiated by a PR Admin with TCAdmin Panel access to the server. In this way, a custom set could be put on a time schedule as well - only problem is that if for some reason, the number went up, they'd be steamrolling the AI like they were a sack of soggy shit until the server setup was reverted to the DEFAULT maplist/config parameters. Now, I've coded a few buttons for the PR Admins, and for now they swap 2 files if needed (a config and a maplist) but I noticed that TEDF needed to adjust something else for this EVENT -- so if another file or set of files needs to be included for a "LOW POPULATION MAP ROTATION" server setup, I can make that part of the function. But again, there is a bit of work and testing to see if this all works as intended, and if we can actually use a "LOW POP" server function button that will make Off Hours more entertaining to that smaller crowd, or if we can even slap something like that on a automated schedule so it's hands off (players would just experience a server crash, but return to the server list and see VG COOP back almost instantly). Us =VG= guys are and will be discussing this very thing in more detail very soon. It's something I very much want to implement if we can, and if it tests out to work just fine, which is yet to be proven. It's all theory and assumption right now, even though I did the coding for such actions already as a sort of "proof of concept".

...hmmm My opinion is not quite so valid as the others, as I am a noob again from years of no PR -- BUT coming from someone who retired with more than 3,000 hours logged, I can say that it was a great team effort and everyone seemed to enjoy playing and trying to fight as a group. That said, also with the understanding that this was one chapter of a larger story, I found it difficult to discern if we were supposed to have a snowball's chance in hell of doing anything when we knew for a fact that each time, some PR player with GUARANTEED more time than I have in this game lately spawned in and "started the bot advance". When we know there are tools we can use, but the logistics of the game itself prevent us from using those tools (such as a FOB and/or a Stinger emplacement, or any such defensive buildups) at a base that seems to be a maze to most players (read: unfamiliar map), it is very difficult to know if the game went awry or if it's playing out as it's supposed to and it's just a digital recreation of the fight for the Alamo. When we fight with AI on that difficulty level on such wooded map scenarios, it feels like it's weighted so much against us, it was equally difficult to tell if we were just getting steamrolled due to lack of action on our part or just because the game was not balanced as the mission designer intended, and moreso confusing knowing that human players were actively delivering extreme offenses on any lines we managed to set up. Again, I'm new to this, and my opinions are more of an outside perspective than those who play PR regularly, so don't mind my confusion about whether we were playing the game as it was intended or if things had just gone completely sideways due to simple AI spawning logistic facts that require us to "DON'T SPAWN IN! DON'T SPAWN IN!!" .... "Oh, sorry guys - I spawned in" .... on... EVERY... SINGLE.... MAP!!!!!! Also, and FatAbert brought this up more than once -- and maybe I saw more if it cuz I was a medic and they were popular players to gather around when you get your ass shot off every other minute, and also the fact that I'm newer myself and will be very slow to react, slow to get a kit item in my hands, and unfamiliar with the ability to push other people around when you're trying to just move next to the other medic who's busy... BUT... Don't bunch up like a JV Soccer team!! Spread the hell out - no more than 2 squad members within spitting distance of each other, and one medic should stay within earshot of the SL at all times. I was a bad medic; but the other "good" medic(s) were having a tough time with the multiple casualties in one pile that could have been avoided by spreading out a little bit more. Last edit, I promise: Finally, HaterOneActual just posted a great Comms Protocol guide with excellent suggestions and tips we should all review because Comms were nuts, cross comms between squads on direct was even worse. We can all do a little better on that front with a few exceptions, and they know who they are - the ones biting their tongues from not yelling at others to shut up for one goddamn minute while the SL talks with the other SL's and the Commander. All that aside, I had a great time and look forward to the next event! (Hopefully not another no-win scenario) Thank you TEDF, Double_13, PBASydney, and anyone else who worked to make this event!

Excellent comms guide and tips!! Thank you, Hater! We gotta keep it short, sweet, and clear on comms --- we get to joking around on the mics in games which is just fine, but know when it's time to snap back into Operator mode and clear the comms when asked. For the Viper Pilots here, in Falcon BMS, we get squelch when someone tries to transmit while another is already transmitting on the same radio - in this example, a "BREAK, BREAK" should be simulated by two separate bursts of squelch (press COMMS HAT Forward or Back two times on the UHF or VHF radio respectively). On VG BMS Server, If you hear two sounds in a row like this, drop comms (release transmit) to allow for the other transmission. It could be far more important AND time sensitive!

I'll be there - probably as a medic in some squad, or grenadier.

Just one more point on the Dev subject of COOP: COOP would already be dead, it was slated to be dropped on full release, and Melon saved it. They had no interest in doing the navmesh work required for the maps. It is NOT a primary focus of the PR Dev team in any way. The work we do here to make it popular, and the development work Melon and others do are essential to keep PR COOP alive, or it very well could be forgotten and dropped in future releases.

^^Very, very good explanation, FastJack!! That really explains a lot, and why it is so difficult to get these "AI" bots to behave in an intelligent manner. Maps look beautiful for a game of this age, but to see them in the way that the bots see them is very revealing.

First, no effort - and secondly, using my method, it would take less than 3 seconds to copy paste the settings. I already had to make several TCAdmin buttons for what will be the VG ARK Survival Evolved server, and it would be no effort to slightly modify the code to work on PR files (more like simply changing the file path in the code). Already modifying it for the Minecraft server for auto world backup. Different settings config with different name would be required, and that's part of the functionality - also custom command lines would be part of the swap. New changes to configs that are tested, and minor tweaks are just what you are doing now. Restarting the server with a different tested config will not make the server unstable. That would be the result of a poor choice in a config, not the ability to restart PR in a different configuration with the touch of a button vs. manually swapping files / copy paste or service settings edit. As far as bug reports and these changes you have been making, a public announcement and details to the specific changes would help - not as a discussion thread, but as a sticky post that can be updated and referred to for info. These are some rather sizable changes, a change log would be appreciated by many. Restart was implied in all ways, of course. And with regards to what Double wrote, yes, there could be a trigger that swaps out a maplist or config upon server start/restart so long as it is manually performed in TCAdmin - when the server crashes, I doubt it fixes itself and restarts to Mutrah, so there is a man-in-the-loop at the stage of a crash, and that man can have a host of custom actions that you decide, if you want. It is no effort to code, it's more just batch scripting anyway, and it would give you some next level config options for the already unique VG PR COOP Server. Think of each setup as a set of files (config, maplist, etc) that all have their own different folders with the name you choose - they sit in that custom folder, and if you edit them, these are what you edit. The ACTUAL working versions that PR sees are in their correct places, when they swap, the ACTUAL ones move to a dump folder (and then dump deletes the next to last file) and then your Custom Configs/Maplists/Etc. get copied from their special folders to the ACTUAL file places. FolderTEDFsetup1: maplist config FolderTEDFsetup2Mutrah247: maplist config FolderTEDFevent1: maplist config All of those could be on buttons - just examples - you never touch the ones in actual PR folders, just a swap button in TCA that puts those where PR will read them - then start/restart PR. Done. Just let me know.

@=VG= TEDF if you could use the tool, I can create a button for TCAdmin that can swap out the maplist for a different rotation. This also could be set on a schedule so that known down times could have a maplist rotation that is more feasible on a low pop server. I could even make a button in TCAdmin that swaps out a config for a different variant, again either manually pressed, or on a schedule. This could alter the game for Low-Pop times and revert itself when it nears High Pop times (or you admins could manually do this by pressing said custom TCA button). This is the sort of code-fu that I am very good at, let me know if you could use some "swap" tool buttons in your TCA panel for PR.

It takes over 4 minutes to dig a FOB?! Or is the point that it's faster with more than two people? Is this same as with Deployment or is it less/more? This could change the whole dynamic of placing a FOB, and their use and implementation in COOP, which could be a very good thing for more tactical gameplay - placement would need to be more well thought out, and the accomplishment of placing one is more of an achievement in and of itself, requiring and rewarding teamwork.

You want feedback, it is a good thing. Do what you can to help make the game fun and more involving, but do so with respects to the server running with different sized populations - I was also an "off times" player when I was big in PR, and it was a big challenge - because if you favor one group on the server with your changes (peak time players when server is fullest) you risk losing a portion of your player base and server popularity. This is not Deployment, it's COOP, and fun changes that help are great, but beware that stressing too many Deployment rules could make it less of a casual version of PR; vehicle respawn times is a good example where it's best at 5 minutes for COOP and 20 for Deployment, and altering it would change the nature of the game. Just because you don't see certain groups (those who play during non-peak times) doesn't mean they aren't dedicated VG PR COOP Players. Be careful what tools you remove - and test your changes, if something needs a day or two to feel out, fine - but be sure you pay attention to all the constructive feedback and don't mistake all of it as merely an "aversion to change".

Are you freaking kidding me?!

The VG Project Reality COOP Server is back online. PR Mumble is still down - it may be a day or two until we get everything working the way it was, but at least the main server is back for now. It's fair to expect some restarts here and there when the server is being worked on, but we will always try to notify you before that happens. Thanks again for your patience!

Well written review! Meant to post that back when you wrote this - I can appreciate the time it takes to get something looking right. Game sounds pretty cool, too!

sadly, servers are down - details here: http://veterans-gaming.com/index.php?/announcement/7-vg-servers-are-down-we-do-not-yet-know-when-they-will-come-back-online/

TS3 and Mumble Services restarted -- it should be working now. *I may need to restart PR as well, but I hope not. Please let me know if it worked. oh crap - servers just took a crap... details here: http://veterans-gaming.com/index.php?/announcement/7-vg-servers-are-down-we-do-not-yet-know-when-they-will-come-back-online/

Hey bro, don't worry about it! Thank you very much for your kind words! We know not everyone can donate, and that some cannot because it's physically/digitally not possible - but we still appreciate the thought! Those who cannot donate money still help by playing on our servers, and promoting the friendly teamplay spirit we all enjoy here at VG. There are other things you can do to help the community, things as simple as sharing a screenshot, teaching a newer player some helpful skills, helping to report a nuisance player, or even just telling a friend about our mature gaming atmosphere and helping to spread the word about our cooperative teamwork servers. Rest assured that VG will continue to function even if we do not receive donations because we have some very dedicated VG Alumni who still devote time and money to help keep VG running year after year. Any little bit helps, but no one should feel bad for not donating. Help out where you can, have fun; spread the love! Thanks again, ranger_12!

Well said, Rotblut. Poffadder replied to my email: "I'm heading to Spain, I'll do it from there."

I emailed Poffadder regarding the update

@=VG= SolarFlame1 Technically, you can find the info on our page, but it is best that you do not mess with it as you said - the server does not multi-task well, and if there are more than 4 players flying around, anyone working on the server will risk crashing the main application (BMS) that it is running. If you can help to troubleshoot this issue, I'd be happy to help you out, but I believe the best time is early to mid-morning for you (that would be middle of the night for most VG BMS players, so the server would be empty). And I might be asleep - but we should talk sometime in person about this. We could make sure no one is flying, and shut it down. I do any and all maintenance when no one is flying. The server auto-save's every 2 hours, so it is unlikely that you could seriously mess up a misson/Campaign in progress, just FYI. You'd just login, end the processes via task manager (Falcon BMS.exe and IVC.exe) and do your stuff. Force closing the programs won't hurt it at all. I'd login the next morning and restart the server. Eazy peazy. (that's just in case you ever wish to check out that server ) The only problem with you logging into the server is that when you leave, the server will lock up to the Windows login screen and I'd have to come in afterwards to fix that. Again, we should talk in person someday, too many details (some sensitive) for me to type up here. This is not the first time a player has had this sort of issue connecting, coming from a country where people already connect without issue, and in this case, he's even in a major city (Hamburg) and not the middle of nowhere it seems. I do assume it has to do with his hardware configuration, a user issue and not a server issue, since we all connect well from US, UK, and Europe already with no extra steps required, no ports needing to be forwarded.

banned