Help needed testing 3.2.x Campaign games!

Discuss the future of Warzone 2100 with us.
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: Help needed testing 3.2.x Campaign games!

Post by NoQ »

What are the tools were currently using (and their versions) to track bugs and consolidate our data?
Am I correct in assuming that the master file on buildbot will be the most recent push?
If we are testing fixes, how are they applied to the master files between pushes, and are they all in this topic or located somewhere else?
It's, kinda, git. Here's the whole history of changes. On the right you have unique identifiers for each change, aka commit hashes (eg. 27582e8). Files produced by the buildbot are named after the corresponding hashes, eg. http://buildbot.wz2100.net/files/warzon ... [b]27582e8[/b].exe (this exact link would die soon but you see the point).

Bugs here are usually tracked through Trac, but this thread is moving on too quickly to document all the bugs that get fixed, so i guess it's ok to just boil here. Commits, together with bug ticket updates, are also appearing on Trac timeline, if the respective tick boxes are ticked.
Bethrezen
Regular
Regular
Posts: 661
Joined: 25 Sep 2009, 02:05

Re: Help needed testing 3.2.x Campaign games!

Post by Bethrezen »

you can also find a list of outstanding issues that still require fixing here

viewtopic.php?f=6&t=13753&sid=341f7bf9b ... f5a6c6add2

These are general issues that are not specifically related to the campaign that my self Alfred, Philosopher have encountered during testing it was decided to list them all in there own post as a reference so that people who decide they want to help don't report issues that are already known about and it makes it easier to update as new issues are encountered or fixed.
Hmm... did not encounter base blip removal bug for Alpha 2. If it's not save related then it might be some obscure bug in the library.
Strange humm... I'll up date to the latest master and then check alpha 2 again see if i run it to this glitch again, because it could well be that i did activated the deity cheat and i just don't remember or it could be some other minor issue like a typo that has already been fixed.
Bethrezen
Regular
Regular
Posts: 661
Joined: 25 Sep 2009, 02:05

Re: Help needed testing 3.2.x Campaign games!

Post by Bethrezen »

Ok so i just noticed an odd glitch on alpha 1 somehow on reload my builder is able to build the oil derrick even though the oil is still burning.

here is a save to demonstrate the issue.
Alpha 01.7z
(50.13 KiB) Downloaded 107 times
[edit]

Also i know this might sound like a bit of a stupid question but how do scav units out range your units when you are using the same weapon ? shouldn't scav machine guns and player machine guns have the same range ?
User avatar
Hironaru
Trained
Trained
Posts: 38
Joined: 11 Jun 2017, 10:10

Re: Help needed testing 3.2.x Campaign games!

Post by Hironaru »

Excellent, thank you NoQ, Bethrezen.

I will make the necessary arrangements, and go ahead and focus on the balancing review concerning all skills for Alpha and Beta, paying careful consideration to their respective strengths over time through the campaign with the listed play-styles. It does appear that the Gamma Save bug is still in effect. I did not see them in the forum post, so I will refer to these tickets, which may be related:

4669
4644
4556
3377
2126
1939

Is there a global list of variables I can examine for all of the weapon mechanics and upgrades?
Last edited by Hironaru on 18 Nov 2017, 03:35, edited 1 time in total.
Do, or do not. There is no try.
-yoda
User avatar
Hironaru
Trained
Trained
Posts: 38
Joined: 11 Jun 2017, 10:10

Re: Help needed testing 3.2.x Campaign games!

Post by Hironaru »

Update: master version warzone2100-master-20171116-003054-27582e8.exe
CTD on cam 1 Load.
Persistence: 100%

LOG:
error |06:05:08: [khr_callback:139] GL::API(Performance:Medium) : SLI performance warning: A region of an active drawbuffer is 'dirty' and color writes are enabled. Disabling AFR to prevent possible corruption.
error |06:07:28: [khr_callback:139] GL::API(Performance:Medium) : SLI performance warning: A region of an active drawbuffer is 'dirty' and color writes are enabled. Disabling AFR to prevent possible corruption.

Fix: Disable shadows
Stability: 100%
Do, or do not. There is no try.
-yoda
Bethrezen
Regular
Regular
Posts: 661
Joined: 25 Sep 2009, 02:05

Re: Help needed testing 3.2.x Campaign games!

Post by Bethrezen »

It does appear that the Gamma Save bug is still in effect.
we haven't really gotten as far as gamma yet some fixes have been applied but it's not been extensively tested so still has some bugs, but give it time we'll get there eventually. :)
User avatar
Hironaru
Trained
Trained
Posts: 38
Joined: 11 Jun 2017, 10:10

Re: Help needed testing 3.2.x Campaign games!

Post by Hironaru »

On the issues of balance relative to play-styles on normal difficulty, I will be taking careful consideration of balance for three relative play-styles, assuming a limited level of exposure to Warzone 2100, and what the sequences of events of game-play and upgrades convey upon first impression as someone new to WZ. My primary objective in this is to keep all demographics engaged and challenged, but not constrained; to evolve their play-style by adapting.

----- Playstyles -----

The 3 play-styles I am testing, will hereafter be designated by the following acronyms:

- [Z] for zerg: Players who focus on this tend to focus on micro skills, maximizing their build order efficiency and damage with guerilla style unit movements.
Type: Early Game
An ideology which revolves around resources. this play-style revolves around denying enemy resources and developing ones own resources under the concept that if an enemy has less production ability than you, then they absolutely will lose. This is often accompanied by an early rush, or "poke" to see how much damage you can do to an enemies early economy, followed by small waves or a stream of units to ensure that economies are either stunted or crushed.

- [O] for Reactive Offensive: This player tends to focus on developing resources and offensive ability. They are macro warfare masters and favor numbers.
Type: Mid Game
An ideology which focuses on unit strength and number theory. A direct counter to zerg, the player will build units in the same way that a zerg player would; with one minor difference. Instead of sending out his units, he will simply pool all of his units near his base. In theory, by the time the enemy arrives they will have less units than you due to proximity, and also have to deal with light defenses. Once the enemy force is wiped out, the remaining army steamrolls the enemy base.

- [D] for Ultra Defensive: This player focuses on survivability, expansion and minimizing loss. These players excel at response, recovery and map control.
Type: End game
An ideology which relies on brick wall defenses and rapid growth. This player is vulnerable early, but excels at end game defense and control. A common tactic is to build out defensive structures near untapped resources to prevent early enemy expansion and develop mid game economy. With a focus on staunch base defenses, mobile artillery and rapid recovery, they are well situated to dealing with conventional assaults. The end game revolves around a war of atrophy.

----- Process -----

I feel that before changing implicit values of game mechanics, careful consideration needs to be given to the order in which upgrades are presented to the player. Once this has been established, I will use the three different play styles to measure and approximate the overall flow of the campaign in a segmented process. I will focus on each subsection, playing through several more as well to verify the integrity of the changes, and then will evaluate weapon balance.

Only once I am satisfied that the changes I will recommend will equate to a good overall experience between all play-styles will I present a recommendation here. My intention through the entire process will be to force people to deviate from the three generic strategies, evolving their play-style situationally, rather than the blatant forceful attempts other rts's use to make players try different units and strategies. Soft player development vs hard player development.

To get the ball rolling, here's 3 recommendations right off the bat. :D

----- CAM1A -----

When engaging the first group of enemies, the game feels balanced, perhaps slightly in favor of the player. You are able to wipe out the first base with your four mg tanks, and research the Hardened MG Bullets upgrade. However, at that point, you can pause offensive progress and continue with consecutive upgrades: APDSB MG Bullets, APDSB MG Bullets Mk2, which kind of spins the balance of the present conflict for the remainder of this segment out of control.

In addition, new or young players have a tendency to react slower and build less units, focusing on structures before offense. Due to the nature of the AI, and an inability to have any defensive structures available to them, it is possible that constant waves of AI would defeat an entry level player, or novice [D] player. Offensively, the current system I see seems to reward [O] players, while providing an optimal challenging environment for [Z] players.

The first impression I would get coming into the game, is that it was a game that pushed me to be an offensive player. From a [D] perspective, the fact that there are no base defenses to start out with would seem dangerous (which is a good thing), but as the mission progressed it would feel like this game lacked content due to a limited number of early defensive options. [O] Players might research full mg upgrades before second base, making the game seem too easy.

To add a more smooth transition into CAM1B, I would add "Engineering" from the first base in CAM1B as a prerequisite for "APDSB MG Bullets"
Now this added some questions from me. First of all the tech tree on our site does not reflect the upgrade path at all, which means it needs to be managed (I can do that, after revisions are finalized between Campaigns). Allowing this level of progress takes away from the feeling of progression from base to base between CAM1A and CAM1B, and there are a lot of missed opportunities to leverage the lack of power to train new players to be cautious, and develop micro.

To balance the playing field, I would like you to switch the "Heavy Machinegun Guard Tower" upgrade with the "Hardened MG Bullets" Upgrade (the first and third base upgrades). This will make [Z, O] progression more gritty, and allow players to explore the flamer upgrade (second base upgrade) as a solution to their then under-powered mg turrets, giving depth to flamer technology. Simultaneously, the first upgrade will be a base defensive structure. a hint to [Z, O] players, and a much needed relief to [D] players, who will have the urge to plant defensive lines around their resources, and between each base.

To solve Flamer practicality, I would also recommend doubling the base rate of fire for Flamers and to reduce their base damage by roughly 30%
The reason for this is that small groups of flamers don't inflict damage often enough to warrant their use in combat. They either die before they have a chance to recharge, or if they are mixed with machine guns, often only get a chance to fire once during an encounter. They also provide less dps than the machine gun, despite being more expensive and having less hp. The improved rate of fire would allow them to sustain in a fire fight, and damage would balance with cost.
Do, or do not. There is no try.
-yoda
User avatar
alfred007
Regular
Regular
Posts: 619
Joined: 31 Jul 2016, 06:25
Location: Stuttgart, Germany

Re: Help needed testing 3.2.x Campaign games!

Post by alfred007 »

Berserk Cyborg wrote:Does anyone think that we should try to balance the assault gun? I still think it is too powerful so much so that a small group of them can destroy tracked units and structures with ease. Thoughts?
Yes I also think, that the assault gun is too powerful. And I'm also the opinion, that lancers are too powerful, especially right after you researched them. And the ripple rockets of the collective are too weak. As I said before at beta 5 it is too easy to enter the NW base. In 3.1.5 the RR could easily destroy a python tracked lancer, now they have problems to destroy a mantis tracked repair unit. If you tell me where I have to adjust these weapons I could make a mod for testing one after the other.
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: Help needed testing 3.2.x Campaign games!

Post by Berserk Cyborg »

Bethrezen wrote: Also i know this might sound like a bit of a stupid question but how do scav units out range your units when you are using the same weapon ? shouldn't scav machine guns and player machine guns have the same range ?
According to the weapons file (base stats here), scavengers MGs have more range than the one the player has. Why? Most likely so they can annoy the player and have at least a chance to destroy something the player owns.

Hironaru, to get a sense of what this testing thread is for, you can read parts of the jscam guidelines. The main focus is on if the scripts are working good enough for a stable experience. There might be something non-script related showing itself, in which case it is better to put that in a trac ticket. The campaign can be quite different depending upon what difficulty you choose. Easy and Normal are for a more relaxed experience and Hard and Insane is if you want a challenge.
alfred007 wrote: Yes I also think, that the assault gun is too powerful. And I'm also the opinion, that lancers are too powerful, especially right after you researched them. And the ripple rockets of the collective are too weak. As I said before at beta 5 it is too easy to enter the NW base. In 3.1.5 the RR could easily destroy a python tracked lancer, now they have problems to destroy a mantis tracked repair unit. If you tell me where I have to adjust these weapons I could make a mod for testing one after the other.
See link in my reply to Bethrezen above.

Maybe we won't have to do anything balance related if MIH-XTC does try to attempt this later.
User avatar
alfred007
Regular
Regular
Posts: 619
Joined: 31 Jul 2016, 06:25
Location: Stuttgart, Germany

Re: Help needed testing 3.2.x Campaign games!

Post by alfred007 »

I reduced the damage of the assault gun from 22 to 18 and played beta 8 again. It is much more difficult now to destroy enemy units. For me it's clear, that if we reduce the damage more assault guns became useless, so 18 seems to be the minimum damage in my opinion. We have to see later in gamma campaign if 18 ist maybe too low or if we can go on with that. Generally, I say that we should do some work with balance, but first, we should get a (mostly) bug-free converted version and after that do the work with balance.
@Berserk Cyborg In weapons.json I can change the damage of my weapons, but where can I change the damage of enemy weapons?
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: Help needed testing 3.2.x Campaign games!

Post by Berserk Cyborg »

It will modify the enemy weapons as well. If for whatever reason we want to create stronger/weaker variants of the same weapon for the AI, all that is needed is to copy an existing weapon in weapons.json and give it a new name (and modify the droid templates file in scripts/campaign so enemy units would produce it).

Same thing for structures (would need to search the mission scripts for any references to it) and we could boost the damage of, say, the collective ripple rocket structure that way. Enter debug mode and click on a structure to find its name.

We could also experiment with the weapon/structure modifier files. Likely would need to separate lasers into their own category since they need to be powerful.

Edit:
Interesting, the last Gamma mission has two video sequences that are not used currently. They seems to imply that something would happen where the player would have to destroy the command center quickly or else something would happen where the player starts to lose control of stuff (cam34mu1.ogg) and, probably, then taunts the player if they lost everything (cam34mu2.ogg).
User avatar
Hironaru
Trained
Trained
Posts: 38
Joined: 11 Jun 2017, 10:10

Re: Help needed testing 3.2.x Campaign games!

Post by Hironaru »

Berserk Cyborg wrote:
Bethrezen wrote: Hironaru, to get a sense of what this testing thread is for, you can read parts of the jscam guidelines. The main focus is on if the scripts are working good enough for a stable experience. There might be something non-script related showing itself, in which case it is better to put that in a trac ticket. The campaign can be quite different depending upon what difficulty you choose. Easy and Normal are for a more relaxed experience and Hard and Insane is if you want a challenge.
Yes of course, The intention was to establish a baseline for new players (normal mode) and then adjust the other difficulties one by one.

I understand the objective of the thread is to repair the code for a stable environment. However due to the sweeping changes being made during this process to the overall balance of this game, I would like to point out several pitfalls that happen to people who don't have an established methodology and change tracking method for these changes. Despite best intentions, these sweeping changes (throughout the industry of gaming and multiple platforms) are usually made by people who have played the game several times, and are relying on their perspective to grant them the ability to ascertain a proper re-balance of a given mechanism. Unfortunately, familiarity is the enemy of discovery. It is easy to forget we take things for granted, which are unfamiliar to new faces.

I still own the original cds of this game, and have played through it more times than I care to count as this project has continued from 2.x. But as someone who has been trained to contribute to the balance and feel of players for the direct purpose of customer retention and product first impression in several other environments, I can say without hesitation that I am uniquely well suited for creating a finalized, comprehensive balance to the overall game-play; because I can ask myself questions like "what would I do if I diddn't know whats coming" and "how would this player react in this situation".

You do not know me by name. I feel that its better that way, but if you poke around enough; with some simple tools you can find my identity through my email, and see the kind of companies that I work for. They trust me to communicate vision in the projects I perform. And I envision an rts that can be played from any perspective, and maintain a well-polished feel through out the game no matter what they choose to do. The missions are built to train different aspects of play and test the players ability to improvise strategy, but that strategy changes based on both the player and level of familiarity with the game.

-----

I would like to make a bold proposition. One that I would like you to consider as a newfound friend on our journey to not only restoring this game, but finishing what pumpkin started and ended here. I would like you to trust in my abilities and skill-sets, and allow me to manage balance entirely, while you focus on the coding aspects related to the stability of the game. Any change to base values requires a complete play-through in order to fully grasp, and affects different play-styles in different ways. Leave that task to me; by the end of this project, you will be glad that you did.

I can make a separate thread and work with you guys here side by side, and get newcomers involved in a focused balance testing process. I speak a little js and can probably find a way to test alterations myself so you don't even have to worry about the busy work, and give finalized changes for you to implement in whichever next master we are on. :) I will keep a chronological order of every change I make, so if you feel that something needs to be assessed, I will have the ability to provide rollback functionality in the event that anything falls flat with coding errors down the road.

I can organize and direct balance initiatives within the balancing community specifically for the campaigns, in a focused and contentious way. Changing one weapon at a time without the consideration of every other weapon option for both the player and the enemy at that time, and the overall growth of that weapon through the course of the game is like: trying to fix one aspect of an "as is" car you bought from some shady used car dealer only when it fails to turn over, with youtube diy videos on your best guess of what the issue might actually be. From the beginning, it was always apparent that wz needed a tune-up.
Do, or do not. There is no try.
-yoda
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: Help needed testing 3.2.x Campaign games!

Post by Berserk Cyborg »

So here is the new version of the cam3-ad2 script. I figured if I move the LasSat by 0.275 tiles every blast (12 second interval) then it will traverse a third of the Gamma home map in about a hour. Any review of it is welcome.

I would push this into the official repo now, but I discovered starting with cam3-c there is something blocking the player from building anything above the revealed area for that mission (possibly caused by restoreLimboMissionData()). It does allow building on a small strip of land running down all the way on the eastern side. Then the next missions it only allows building on that small area to the east as I said before. :?
Hironaru wrote: I would like to make a bold proposition. One that I would like you to consider as a newfound friend on our journey to not only restoring this game, but finishing what pumpkin started and ended here. I would like you to trust in my abilities and skill-sets, and allow me to manage balance entirely, while you focus on the coding aspects related to the stability of the game. Any change to base values requires a complete play-through in order to fully grasp, and affects different play-styles in different ways. Leave that task to me; by the end of this project, you will be glad that you did.
I am fine with that.
User avatar
alfred007
Regular
Regular
Posts: 619
Joined: 31 Jul 2016, 06:25
Location: Stuttgart, Germany

Re: Help needed testing 3.2.x Campaign games!

Post by alfred007 »

Finished testing beta 10. Looks good with one exception. At my first try, the western hover group needed too much time to come to the east. Due to that, I restarted from the beginning of beta 10 at my home base. Now everything worked fine. These logs are in the beta 10 zip-file. After I finished beta 10 I tried to reproduce this bug. I needed three tries. Twice it worked good, at the third try the hover group moved from NWTankPos1 to NWTankPos2 and then back to NWTankPos1 instead of moving forward to NWTankPos3. I saved this game when the hover group was on his way back to NWTankPos1. This log and the saved game are in the beta 10 bug zip-file.
Attachments
beta 10.zip
(1.05 MiB) Downloaded 94 times
beta 10 bug.zip
(385.23 KiB) Downloaded 99 times
User avatar
Berserk Cyborg
Code contributor
Code contributor
Posts: 938
Joined: 26 Sep 2016, 19:56

Re: Help needed testing 3.2.x Campaign games!

Post by Berserk Cyborg »

Not a bug since that is what all patrol groups do, that is to randomly select a position they are given and go to it. Though I guess I could implement a loop through method where they sequentially visit each patrol position.
Post Reply