VSR 5.0 Released

[mase]

Here is how I do it with 7-zip:

Unpack the VSR5_0_shellfix.zip somewhere.
There will be a file without an extension in that folder.
Rename that file by putting .rar as the file extension.
Unpack that file. Within that folder will be a VSR folder.
Copy that folder into the Battlezone2/VSR Folder. Say yes to
copy and replace, overwrite, etc.

[Ded10c]

I'm obviously missing something Ahadley if you can somehow double click this to make it work.

Don't extract the extensionless file in 7-zip, just double-click it to open it inside 7-zip. You don't need to add an extraction to the steps I indicated.

[Zero Angel]

I'm pretty sure that vsrbasesetup is just an extensionless version of vsrbasesetup.cfg (there's a convoluted development reason why I did this). If you open it in a text editor like notepad it should be a text file.

EDIT:

Just realized that extracting directly to your BZ2 folder creates a SUBFOLDER called VSR5_0_shellfix.

In that case, just extract the zip to wherever you downloaded it to. Go inside the VSR5_0_shellfix folder and copy the folder "VSR" to your BZ2 root folder. It should overwrite some files but everything should work properly.

[Red Spot]

I've been doing computers since I was 14 and I'm now 49 so I have all kinds of opportunities to look stupid pretty much every day.

What type of PC's did you work with at the age of 14? Those with a stone keyboard and a wooden mice?
Seriously though, that seems rather impressive to me. I am a fair bit younger than you but when I started on my first PC at the age of 10-11 we where one of the first to have a PC in the neighbourhood and we were not allowed to touch it until daddy more or less knew how to work with it. And he made us read up on things as well before we were allowed to stare at the black MS-Dos screen.

[Deathbringer]

Guys, First.. Thanks for the key of extracting the extraction. That obviously was what I was missing.. What was bizarre is that I was able to open that first file at all with notepad++ since it clearly had more extracting to do. That is what threw me off.
As far as my start in computers is concerned.
I started with the Atari 2600 at about 13. Yes.. this is loosely a computer but it is what got me hooked.
Signed up for what was probably one of the first computer classes in school with a Commodore PET and started basic programming. If I remember right my first program was making a block screen rocket fly up and off the screen.
Got one of the first Commodore Vic 20's that came out right around 1980 and continued to program with that whopping 5k of system ram. 3.5k was usable.
Went on to the Commodore 64.
At one point between the Vic 20 and the 64 I was getting online with a 300 baud coupler modem.
I honestly don't know how my mom afforded me.
Commodore 128 to Amiga 500 and then by that time my next computer was coming over to the IBM clone dark side..
After Highschool it was a job in the Airforce working with Mainframes and 5 years later I was working with an MLS company with a bank of 600+ modems supporting the Realtors in DC Virginia and Maryland.
Anyway.. TMI I'm sure but I just woke up and I'm all Chatty when I just wake up..
Thanks again for pointing out where I was going wrong. I'm usually pretty good at randomly pointing and clicking until something works, but alas I didn't expect to be able to look at a file that needed further decompression so clearly.
Happy Holidays!!

[Deathbringer]

Hey Zero Angel,
I know I have just started playing with VSR 5.0, but anybody have any comments on the balance of the Deadlians? I'm sure this is prob just because I'm new at this race, but my 15 year old Son has been kicking my arse with the ISDF. Is it just me? Which I'm ok with by the way, or are they meant to be a bit more of a challenge to play?
Thanks for the Mod by the way. I do like them I just want to smack him around a bit.

[Zero Angel]

The Daedlians are meant to be balanced for multiplayer, and also are more challenging to play than the ISDF which has a far more straightforward teching path and is ultimately easier to grasp.

[AI_Unit]

What kind of AIP's are you looking for ZA? I can allocate some time to making more if you still need help improving your AI Plans.

[Zero Angel]

I'd be willing to test any AIPs you can offer. The current AIPs are kind of basic, and predictable (like stock 1.3 AIPs). But generally i'd like to see these kinds of things in an AIP.

• AIP builds combat vehicles throughout the game, not just in early game. Sends them at good targets
• Use of buildLoops
  • Blackdragon has sold me on the idea of using buildLoops instead of buildMinimums. BuildLoops allow the AIP to produce units throughout the game (with the DLL upgrading their weapons as necessary) and leads to unit compositions that are wholly unique rather than being predictable.
• Slower and gradual teching. Good target selection
  • One problem that I think is major in 'traditional' 1.3 AIPs is that the CPU team will often tech up very quickly due to having a high scrap boost. Where in 10 minutes into the game, you're already maintaining your guntowers against the inevitable (and somewhat boring) advance of assault tanks.
  • Although it's difficult to do, I believe it would be worthwhile to have combat units frustrate the player's attempts to expand his defensive line. Perhaps tanks that go after his constructors, mortar bike groups that harrass early guntowers, etc.
  • Combat vs the player is important. VSR includes 'smart scout' units which are simply regular scouts that have their AI tweaked to be more aggressive opponents in combat
• The use of conditions (make sure requirements are met before triggering a buildloop or buildminimum) would be useful in making the AIP a little more bulletproof. They'll also allow for higher-teched units to be put into the AIP earlier as the AIP will just skip that unit if it doesnt yet have the tech for it.

Generally, i'd like to see an AIP that techs at the same pace as the player and remains challenging and (especially) fun to fight against, without relying overly heavily on scrap boost (if possible) to deluge the player with assault units. FE and ZTV:Long Journey are good examples of MPI modes that exemplified these principles.

[Red Spot]

In a good, well written, plan you can drop most of the conditions that test requirements.
Not sure if it has any real benefits, but it at least keeps the AIP more readable .. just sayin' ..

If the ai has all to build walkers, putting a plan to build them early in the aip just requires a load of conditions. Having the plan after the actual construction plan means you do not need to test for it any more.

Personally I suggest you allow the dll to switch plans a bit more often. In such style I make the dll switch plans when all basebuildings are up. This means all other plans do not need to bother and I can easilly trow a whole variaty of 'unit-aips' at myself so even I as author do not know whats coming at me.
(When stuff gets killed it triggers stuff in the dll which allows you to switch the aip within a fraction of second.)

[Zero Angel]

I've already thought of all of that, and hinted at GBD that 'non-deterministic' AIPs would be the way to go. Thing is I don't know how well it would sync with clients and buildloops already do bring a little bit of non-determinism to the design of the AIP.

However, there's also alternative AIPs which we do use for other teams in a multi-team setup like FFA (VSR_i1, VSR_i2 etc). Right now, they're just carbon copies of the base AIPs (VSR_i0, f0, e0, d0) but they could be different if an AIP writer was willing to write different plans. We can then likely have the DLL randomly select one of these.

In fact, if AI unit or anyone else was willing to have a go at doing AIPs, I may be willing to replace one of the alternative AIPs (i1, i2) with their AIP file and we can have GBD modify the DLL to randomly select one of these plans; or possibly even switch between them on-the-fly to shake things up a bit. It all depends on what the engine will let us do and whether the extra effort would be worth it.

[MrTwosheds]

Having the plan after the actual construction plan means you do not need to test for it any more.

Maybe they just help the AI to stop building walkers once the conditions are not met anymore... a fail will occur, better to have it done cleanly than be forever debugging aip stalls.

[Zero Angel]

Having the plan after the actual construction plan means you do not need to test for it any more.

Maybe they just help the AI to stop building walkers once the conditions are not met anymore... a fail will occur, better to have it done cleanly than be forever debugging aip stalls.

I agree. A mitigating factor to this however is continueEvenIfFail which does what doNextOnFail is supposed to do , and that's to skip that plan if it cannot be carried out. (Note: DoNextOnFail actually does nothing. Someone started putting it in AIP files and now a lot of people use it in AIPs even though its a placebo)

However continueEvenIfFail is a lazy solution, and should only be employed if one wants to give up on troubleshooting AIPs and is willing to let a few skipped plans through to a release.

I recommend conditions, because they make each individual plan more robust. There's less worry about AIP stalls, and the AIP will hold up if it's switched to; you won't have to worry about a plan being ignored because it has failed once or something dumb like a plan having a wrong priority number which stalls the entire AIP.

[Red Devil]

there are a few good reasons to use ContinueEvenIfFail = false

[Commando]

On an aip, I added all prerequesites to each plan. If the ai was building sabres, it checked for the existance of enough power, the existence of a relaly bunker, and factory. This slowed down AIP execution drastically.