FOB update

[=VG= Kavelenko]

FatAlbert and I tested this out and we can put up a FOB with two guys (one engineer) in 4 minutes 7 secs.

We also completed a round on Muttrah City without deploying a single FOB but that was with 30+ players on the server.

[=VG= SemlerPDX]

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.

 

[TEDF]

Atm, it takes 3 people to succesfully dig a FOB (2 if one is engineer) due to the fact that vehicles (also deployables) decay a lot faster than assets on deployment. Also, the more shovels, the faster it goes up.

 Ive been looking through the files but have been unable to locate the line where we can change it / turn it off. 

[=VG= Fastjack]

9 hours ago, =VG= SemlerPDX said:

It takes over 4 minutes to dig a FOB?!

It feels to me that the BLEEDING EFFECT for the  FOBs is higher in coop as in deployment.

I dig a FOB with another guy in Deployment faster as in coop. Last time i played with some [GI] guys on our coop server and  he placed a fob AND I AM SURE it takes more time in coop to counter the bleeding :

[=VG= chickenjason123]

IMO the problem is the variation of the player quality/skill level. When I'm online, even the easiest asset-heavy maps take at least 1hr30min-2hrs to finish due to how incompetent the "squads" are (wandering all over the place, flag jumping when there are only 1 functional squad etc.) 

Without building FOBs in the correct place the players won't even be able to get to the flag as no one will run transport/trans as suppressed by AA or APC/all ground transport vehicles got ditched somewhere far on map AND then all of them(Players) will spawn in the main or generally being useless. Basically it's like herding cats to finish a map before everybody quits and kill the server population.

 

But then when there are at least 3 proper players online or 2 good squads and the round finishes in 30-45 mins and everybody steamrolls the bots.

I suggest that we use the old wire need wrenching and other is instant build to keep the balance if the vehicle decay speed can't be fixed/set to deployment level.

[WCCBadploy]

Ahhh... Them were the days. Steamrolling over the enemy with so much back up and squad interaction.

When we first started way back when, there was such tight cooperative team play, we only had to worry about not ending the round too early!!

If tweaks like this help bring back the spirit of direct team work it can only be a good thing.

After all nothing ventured, nothing gained, ay?

[=VG= Inch]

FOB being shoveled/with Combat Engineer, is just the best for the server. Personally had no problems with it, making the Co-Op great again with more tmwork. Quite a challenge tho-

Shovels needs some love from players~

 

Inch

[=VG= HaterOneActual]

MAKE COOP GREAT AGAIN!!!!

 

[Xenalite]

Great changes. We continuously need more challenge to keep an old game like this interesting.

As to problem with hard maps on low server population, it can probably be solved by setting a better map rotation for euro night time.

[Double_13]

Well if the map is  not finish able due to been to hard its up for the admin to just runnext.

I went on FOB duty today on yamalia (so the map would be easy and not get wrecked by tanks) and it took 3 people 1 min to shovel the fob. Reasonable I would say

[=VG= SemlerPDX]

6 hours ago, Xenalite said:

As to problem with hard maps on low server population, it can probably be solved by setting a better map rotation for euro night time.

@=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.

[Double_13]

Well I would like to see a variation on starting maps. Let's say the server crashes it takes one of a preset map rotations and then launches. This so one time the server starts at mutra and a other time at pavlosk and a other at map X and follows the map rotation further down. In theory this should be possible in where a program replaces the map rotationrotation.file by an other (preset) file if the server would to crash or reboot.

[TEDF]

11 hours ago, =VG= SemlerPDX said:

@=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.

Depends on how much effort creating something like this would take. It's not that difficult to change these things manually, takes like 1-2 minutes to copy paste the settings for the config files in question so if it's complicated or takes long time to make, then I wouldn't waste my breath on it. Or could even just upload the same config file on to the server, just with different settings and rename it to something else, so PR wouldn't use it until the names get swapped out.

Additionally, any new changes we make to the configs, es specially ones that force PR to swap between files, in theory makes the server more unstable as it is overstreched already.

I was thinking about changing the settings during European off time when the FOB changes went live, but decided against it due to a lot of people propably would get very confused about it and start spamming admins with "bug" reports like I have already recieved when I changed the vietnam, Falklands and unconventional faction FOBs back to vanilla ones without digging requirements so it wouldn't be that hard on those maps. Also, changing the config files requires a server restart for those changes to apply.

2 hours ago, =VG= Double_13 said:

Well I would like to see a variation on starting maps. Let's say the server crashes it takes one of a preset map rotations and then launches. This so one time the server starts at mutra and a other time at pavlosk and a other at map X and follows the map rotation further down. In theory this should be possible in where a program replaces the map rotationrotation.file by an other (preset) file if the server would to crash or reboot.

This has been under depate for years and been dismissed. We are talking about 10 year old game engine which has already been streched to the limit and even over it. The more changes we make to the server files / configs the more frequent the crashes are going to be. That's why admins have the !setnext & !runnext commands. If the server crashes frequently, just change the following map after Muttrah.  

I strongly advice to play throught muttrah without using the !runnext command as the study shows, running next during first map on rotation leads to more frequent server crashes.

The same goes for changing the first map of the rotation to something else. So far Muttrah seems to be the most stable map out there, with crashes only happening once the bots manage to capture the Docks flag and start attacking the carrier, which is in DoD and uncappable. With mostly balanced assets, good defensive locations and city layout makes it a perfect starting map that can be easily finished even with less than half the server max population.

[=VG= SemlerPDX]

6 hours ago, =VG= TEDF said:

Depends on how much effort creating something like this would take. It's not that difficult to change these things manually, takes like 1-2 minutes to copy paste the settings...

..Or could even just upload the same config file on to the server, just with different settings and rename it to something else, so PR wouldn't use it until the names get swapped out.

Additionally, any new changes we make to the configs, es specially ones that force PR to swap between files, in theory makes the server more unstable as it is overstreched already.

I was thinking about changing the settings during European off time when the FOB changes went live, but decided against it due to a lot of people propably would get very confused about it and start spamming admins with "bug" reports like I have already recieved when I changed the vietnam, Falklands and unconventional faction FOBs back to vanilla ones without digging requirements so it wouldn't be that hard on those maps.

Also, changing the config files requires a server restart for those changes to apply.

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.

[Double_13]

Well can your idea not be automated that if the server would to crash and/or reboot it launches the script/bat so for the next reboot/crash uses a different rotation would be used and so on.
 

Server starts mutra (sets that next reboot maplist would be pavlosk) plays its current maplist
server crash
Server starts pavlosk (sets that next reboot maplist would be x) and plays its current maplist
server crash
Server starts x (...)

and so on 

The only thing that cares is the first map but the others the admins can manage themselves like ted said.

[TEDF]

If we are going through with this, then I'd leave the maplist changes out (although that Muttrah24/7 does sound appealing).  Admins have proper ingame tools to switch out the map if needed. If anything, after the config file swap, could propably have it enable the voting during non admin hours so people could switch out the maps themselves.

I'll make a locked separate post with the changelog as this one for FOBs only has already been overflooded.

I'm mostly worried of having too many changes happening in a small amount of time, es specially with custom commands. I know that lady PR is very picky of what you feed her. If you throw too much at her then eventually she'll barf it out and it could take a lot of efford to clean it up afterwards.

Edit : 

Quote

Well can your idea not be automated that if the server would to crash and/or reboot it launches the script/bat so for the next reboot/crash uses a different rotation would be used and so on.
 

Server starts mutra (sets that next reboot maplist would be pavlosk) plays its current maplist
server crash
Server starts pavlosk (sets that next reboot maplist would be x) and plays its current maplist
server crash
Server starts x (...)

and so on 

The only thing that cares is the first map but the others the admins can manage themselves like ted said.

Not the best idea as most of the maps in the list are nowhere suitable for seeding maps (salt sae FTW)

[Double_13]

Well my idea would implement that somewhere else are x amount of maplist.list files and that the program picks one of those files and makes it the main one. This would mean that if we would only have 2 maplist.list files it would only pick between those 2 maps 

 

[=VG= m823us]

Don't forget we do have human admin that can modify the in game maps to run next if we are having these issues.  I do like the idea of having a coded button that would have all the setup files for use to run instead of having to do a manual config reconfiguration.  This would be great for the OPFOR events if we did host them again.  

 

Anything that I can do to help?  I have logged on multiple times today and noticed that people are getting stuck on Muttrah again and taking a while to play through the map.  

[FatAlbert]

On 4/25/2017 at 8:30 PM, =VG= Fastjack said:

I am sure many of you saw the jumping bots against a destroyable object (excample Basrah, the corrugated fence near the Mosque mainbase). I can tinker a little bit. I believe that can be fixed with an ai template,

 

The Bots also do this on Fallujah west.  There is a compound just north east of US Main where there is destroyable corrugated fence.

I like to take advantage of it by letting the bots - just get stuck there, trying to jump over the fence.  After 15 or so bots, it makes the Hospital manageable with few people on.  Unfortunately, some people don't think strategically and destroy the fence and kill the bots - letting them respawn at hospital.     

So in the end, it's not so much of a problem.  But I thought I would mention it.

[Double_13]

On 30/04/2017 at 3:46 AM, =VG= m823us said:

Anything that I can do to help?  I have logged on multiple times today and noticed that people are getting stuck on Muttrah again and taking a while to play through the map.  

One does not get stuck on muttrah, muttrah is love muttrah is life you shall play muttrah at least once a term. 

 

wasnt there suppose to be a separate event server (and coop ins) to be created as mentioned in a other topic? This so that events/tests can be held there without modifying the main server files. 

 

I do have to say that the server has been a lot more stable since ted disabled prism yesterday. This not only in less lag but also in less crashes.