48 replies to this topic

[ThetaOrion]

Guess the second slave chamber is more a building bug than anything else. It is not needed that early. I watched its build being started at second 45.

--

Yes, when I was playing as DE, I tended on average to only build the chambers when I needed them, because I was nearing the cap limits.

But when it was time, I also made it a point to build them in pairs for the reasons I listed above. But, then I wouldn't build a second pair until I was reaching the cap limits again.

I can't remember how many it let you build, six or eight, iirc. But, with the third pair and anything thereafter, I tended to be more creative. Sometimes I used the chambers as foundations for forward bases, and other times, I simply buried them in the back areas so that I could use the extra space they generated and threw in a second barracks or second machine shop around the chambers for the DE to use. Having a producing barracks or machine shop near a chamber can provide a protection factor that's pretty much as good as having an LP2 or LP3 listening post nearby.

Hopefully Arkhan will be able to take all the input and create the optimum use for the chambers, as much as possible. As he has time to observe, I think solutions will present themselves over time.

[thudo]

Caravels should stay around LPs near the startpoint. Thats it. They are NOT Eldar Webways that can cloak, build units, and transport them between other webways. Caravels need to be back at home base as they are used to increase squad/support cap, increase research speed AND increase reinforcement speed.

[ThetaOrion]

Caravels should stay around LPs near the startpoint. Thats it. They are NOT Eldar Webways that can cloak, build units, and transport them between other webways. Caravels need to be back at home base as they are used to increase squad/support cap, increase research speed AND increase reinforcement speed.

--

So, the Slave Chambers are called Caravels in Thud's version of the game. I wonder what they are called in Arkhan's version of the game.

I think that's the hardest part about all of this is getting the vocabulary down.

Anyway, I had to finally go in and look.

In my version of SS, they are called Slave Chambers, and they have two possible upgrades or enhancements:

1) Gruesome Display: which demoralizes the enemy
2) Torture Pit: which harvests Soul Essence

So, I guess our use of the word Slave Chamber isn't too far off.

--

I'll trust Thud to make sure that the DE Slave_Chambers/Caravels end up in the right spot back at home base, because they are not Eldar Webway gates. And, building them around the LP's near the startpoint is a good plan, as well.

[ArkhanTheBlack]

I guess I've at least partially solved the crash bug. The most crashes seemed to be caused by the Necron Lord and not the Warriors. We still used an unstable pathing routine to check if a jump position can be reached by walking. Usually it's stable if we ccheck before if the position is a valid jump position. Unfortunately, it doesn't seem to be stable on the Broken Lands map. This also means that the map is probably unstable for several races and not just for Necrons. I therefore deactivated this pathing check. The disadvantage is that sometimes jumpers will jump on 'closed terrain'. It's annoying, but I definitely prefer it over a crash.

[Zenoth]

I guess I've at least partially solved the crash bug. The most crashes seemed to be caused by the Necron Lord and not the Warriors. We still used an unstable pathing routine to check if a jump position can be reached by walking. Usually it's stable if we ccheck before if the position is a valid jump position. Unfortunately, it doesn't seem to be stable on the Broken Lands map. This also means that the map is probably unstable for several races and not just for Necrons. I therefore deactivated this pathing check. The disadvantage is that sometimes jumpers will jump on 'closed terrain'. It's annoying, but I definitely prefer it over a crash.

Yes indeed, that's a simple to-the-point workaround against that bug. Basically what you're saying is that the map in question is buggy when that function is active... so that means that the vanilla A.I did not have that function enabled since I never got a single crash there or anywhere else in the Campaign with it, right?

Does that mean that the function will always be disabled from now on for the Necrons? Or for other races too? Or will it be disabled only on Broken Lands? Or perhaps only during the Campaign and not during Skirmishes or... well, you know, just wondering that's the future of that pathing routine.

[dreddnott]

ThetaOrion: sometimes the name of an object in the game's code is not the same as its title ingame. The Dark Eldar Slave Chamber is dark_eldar_slave_caravel in the code, and there are others as well.

Why? Ask Iron Lore Entertainment. Oh wait, they're out of business now.

If you're not playing a race but you have your head in the code all the time, you're simply going to use the name you see all the time rather than the ingame one.

As far as the Caravel Chamber of Slavery is concerned I think the issue is that the build order strategies all have the first entry set to build 2. The first entry should be set to build only one, and the second entry for building two should be moved a little earlier (maybe right after armoury depending on build).

Arkhan: great to hear you've squashed the Necron crash bug, even if it means disabling a function for the time being.

[ArkhanTheBlack]

so that means that the vanilla A.I did not have that function enabled since I never got a single crash there or anywhere else in the Campaign with it, right?

The vanilla AI doesn't have such advanced jumping code and so it cant crash that way.

Does that mean that the function will always be disabled from now on for the Necrons? Or for other races too? Or will it be disabled only on Broken Lands? Or perhaps only during the Campaign and not during Skirmishes or... well, you know, just wondering that's the future of that pathing routine.

At the moment I've deactivated it for all races since it's not a specific Necron bug. I guess it was only linked with Necrons because they are the default opponent in the campaign on this map. If I could check a map name then I might have tried that, but unfortunately that isn't possible.

To be honest, I'm not sure if it's the best solution to deactivate the code part. The crash doesn't seem to happen on most maps, and even on broken lands, it's so rare on my computer that I could up to 20 test games to just reproduce the crash.

I guess I will wait for the testers feed back in the next beta. If there suddenly occur noticable problems on several maps, we might have to get rid of the whole special jump code.

As far as the Caravel Chamber of Slavery is concerned I think the issue is that the build order strategies all have the first entry set to build 2. The first entry should be set to build only one, and the second entry for building two should be moved a little earlier (maybe right after armoury depending on build).

I've delayed the second one a bit. It should be okay now.

Armouries are also built earlier now to get the heavy weapons while they are still in the harassing phase.

I'm pretty sure that there is a problem with normal moves which should better be attack moves.
Expl.: Ork attacking eldar LP. Eldar squads run to the rescue - right into the middle of the orks. Certainly no attack move.

It is not the first time I did observe this.

If it's caused by the code, then it's because the IsInCombat flag doesn't mean that a squad is fighting. I've replaced it now with IsAttacking. However, I'm almost sure that I've also seen this odd unit behaviour when I've played the game myself (especially chaos marines). In this case we can't do anything to avoid the problem. It's not the first time we're trying to solve that problem, so I have my doubt if we will manage to solve it now.

[LarkinVB]

I did some debugging and found that there are instances where squad is :

InStateMove() = TRUE
InStateAttackMove() = FALSE
IsAttacking() = TRUE
IsInCombat() = TRUE
GetTactic():GetState() = "Attack"

This shouldn't happen, right ?

Are there instances where tactic in attack state is setting normal move ? If yes perhaps something is fishy with the code there.

[ArkhanTheBlack]

I did some debugging and found that there are instances where squad is :

InStateMove() = TRUE
InStateAttackMove() = FALSE
IsAttacking() = TRUE
IsInCombat() = TRUE
GetTactic():GetState() = "Attack"

This shouldn't happen, right ?

I think this happens when a unit is waiting somewhere, an opponent appears and the unit attacks. The opponent retreats and the unit follows a bit. I'd even guess that the whole combat moving is just stated as 'InStateMove' since 'InStateAttackMove' is a very special command which is usually given by the player with the 'a' button.