Offshoot

I was excited to see: •Target Briefly command works when attached to waypoints. If it was as a result of an issue I raised (late August - http://www.battlefront.com/community/showthread.php?t=105976&highlight=target+briefly+tanks), you can make that twice in one patch they listened to the community Actually, they left a very nice post at the end of my thread, so it would make me very happy if something I spotted helped to make the game better.

Now I don't know which designation either has

Looks great, but I can't help wondering how I'm going to maintain CC in such a map. Even between squads and platoon commanders will be hard. A nightmare fight for sure.

That should probably still be OK then as I imagine in that case you would want the tank to present its front anyway so it would not have to rotate the turret much. In this case it would, in my experience, still fire one shell if it starts firing outside the first 15 seconds of the turn.

A little further to this, I wondered if having a waypoint with a target briefly order and a 20 second pause attached will alter this behaviour, but the exact same conditions apply. I also did a very quick test in real time mode and to my surprise similar conditions seem to apply in that if a tank has to rotate its turret an appreciable amount before firing, it will abandon the target briefly order. It is hard to get the timing right in real time relative to the clock, but I get the impression that the target briefly order when connected to the end of a movement order will only work as one might expect it to work if it can be completed within the first 15 seconds of an entire RT game.

Heh, so my maths is really rusty, but surely if you have three trials to spot one unit of infantry (because the squads cover three ASs) compared to only one trial to spot each tank, that is going to affect the number of spotting events in the 1 minute time frame in this test? Regardless, to remove this possible variable, it would probably be best to do this test using three-man scout teams, which occupy only one AS, rather than full squads.

I've noticed some behaviours associated with the target briefly order when attached to the end of a tank's movement order in WeGo games that players might want to be aware of. The target briefly order lasts for 15 seconds, with the counter for this starting at 15 and counting down to zero. The counter appears to start at the beginning of each turn and not at the commencement of the order. If a tank has to rotate its turret to fire, the time to do so is subtracted from the counter. What this means in practice is that a static tank firing straight ahead will use the full 15 seconds, typically firing two shells and several MG bursts. A static tank that has to rotate its turret to fire will fire for 15 seconds minus however long it took to rotate the turret. When the target briefly order is attached to the end of a movement order, however, the results will depend on a few conditions. If the tank moves for less than 15 seconds from the start of the turn, the target briefly counter will start counting down from 15 seconds minus the duration of the move plus any time taken to rotate the turret. It seems though that as long as the movement and rotation all occur within 15 seconds, the tank will typically still fire one shell and a couple of MG bursts. If the tank moves for more than 15 seconds from the start of the turn and the target briefly order is roughly parallel to its movement (i.e., the turret doesn't have to rotate far), the counter will already be set to zero but the tank still fires one shell and a couple of MG bursts. If the tank moves for more than 15 seconds from the start of the turn and the target briefly order is such that the turret has to rotate a fair amount (I haven't determined exactly how far), the tank will start to rotate its turret but then abandon the target briefly order and not fire at all. Something to keep in mind if you are doing a shoot and scoot with target briefly. I did a brief test with infantry but they don't seem to be affected in the same way or to the same extent, I assume because noggin rotation is quicker. EDIT: actually, I was at first kind of confused as to why tanks were abandoning the target briefly order (something I originally noticed in a game), so it would be handy if others could confirm this behaviour. I should also check how target briefly works in real time.

Does checking LOS use the same mechanism as spotting though? Once a unit has spotted another, I can't imagine that it would then have to 're-spot' it each polling event. Imagine a tank driving in circles around an infantry squad in the open on flat terrain that provided the squad with a 90% chance to spot a tank. If the squad had to respot the tank every 2 seconds, then, on average, the tank would disappear from site one-tenth of the time for no explicable reason. Also, wouldn't LOS need to be checked more often than every 2 seconds? I think in the other thread there was an assumption that a unit looks at all visible ASs and then checks if a unit is spotted in each. This wouldn't explain the phenomenon where a static unit polls every two seconds against a moving unit, though, because the static unit would need to know the other unit was moving and in possible LOS before deciding to check ASs every 2 seconds rather than every 7 seconds. Perhaps instead there is a reciprocity between spotter and spotee, such that a spotted unit automatically checks to see if it spots the unit that spotted it. If that were the case, only moving units would spot every 2 seconds and it would just appear that static units poll every 2 seconds against moving units (especially in conditions like this test where spotting is apparently easy).

Spotting ability sounds like an ideal function to incorporate into the difficulty modes - easy at one end, hard at the other. Even better, give it a slider of its own

Ah, I see - sorry, misunderstanding on my part. I get it now - no spotting events occur between the polling events even if the status of a spottable unit changes in that time. You've mentioned sound resulting from firing - were the units firing actually firing on the tiger or area firing elsewhere? I just wonder if receiving fire triggers a spotting check?

It could do of course, but is it likely? Assuming that the polling time is a limitation mainly from realtime, if the polling time changes, there will then have to be a system in place that ensures these changes are synchronised between the two players' game instances. Knowing the polling time, this set up would make it easier to derive quite solid info on the effects that, for example, unit experience and terrain type has on spotting. I'm not convinced yet that movement and sound do not affect spotting; it might be that spotting in this setup was easy enough that the effect of movement and sound was lost. So how long before this gets exploited? Throw out a sacrificial unit to check when the polling for an enemy unit occurs (a twist on recon by fire), then start counting out lots of seven seconds. Though I wonder if in WeGo whether the counter is reset at the beginning of each turn?

Interesting findings. As well as replicating the results, perhaps this could also be done for other types of units to see if all types follow the same rules. It would be also be interesting to see if it works this way for 'unspotting', where a unit goes out of view.

The shader fix certainly makes the visuals better for me. I do, however, have something strange going on with the shaders in general. Without shaders on, everything is normal, but as soon as I turn them on (Alt-R), what I presume is my graphics card starts emitting a warbling sound. Also, if I have vertical synchronization off, my card emits a high-pitched constant squeal at the opening screen; with v-sync on it doesn't do this. I'm prepared to accept it is one of those things, but it doesn't make me feel too comfortable. Card is an MSI Geforce 560 Ti (301.42 driver). EDIT: after looking it up, it seems the squeal with v-sync off is caused by coil whine resulting from too many FPS causing load - with it on it pegs the frame rate to the refresh rate and reduces the load. Not sure if it's also the cause of the sound I get when I turn shaders on, but I'll have a fiddle with all the settings to see if they change anything (I had best quality, high-quality textures and AA on, though it still ran smoothly on a medium map).

I don't see that anyone here has dissed the stock artists, but as someone who has contributed to this thread I am concerned my comments might be being misinterpreted. When I said the normal maps were done at speed, I was not making a qualitative judgement but repeating information provided in another thread by someone who was involved in preparing the normal maps. In that same thread they also mentioned that some objects in the game that could have normal maps do not currently do so. Commercial artists usually have to work to deadlines and within budgets (and perhaps using pipeline processes that aren't optimal), so the old maxim "you can pick two from quick, quality and cheap" applies. Modders don't have the same restrictions but can burnout or lose motivation for something they aren't being paid for.

We'll have to see how things pan out. It sounds like the normal maps were done at speed so there may be room for improvement. Also, many of the original textures look to have a lot of painted in dark shading that may not work to best effect with the normal maps when rendered together by the engine.

Thanks for the answer - sounds like there's plenty of scope to play. Did the artists ever consider using sculpting to generate the normal maps, especially for more organic models?

Were all the stock normal maps hand painted and/or derived from existing textures? Also, I'm curious about what normal maps are applied to. I saw elsewhere that they aren't applied to terrain, but what about terrain objects like houses, trees, etc? Once I get the game (can't until Wednesday because I'm already way over my data cap), I'll be keen to fire up ZBrush and see how far the normal mapping can be pushed.

This is the third piece of software in the space of a couple of weeks I have heard this happening with. Why do people persist in using Nortons, especially when MS themself provides for free a very serviceable antivirus program?

As has been asked, is it still possible to designate an alternative drive/folder to place these files in? I prefer to put data files on a separate partition to make backing up easier and to save space on my system disk.

Galileo, but only since 1992

Care should be taken when talking of bump maps and normal maps because although they may generally achieve the same effect in-game (though normal maps do it better), the maps themselves are quite different. Bump maps are greyscale maps while normal maps use colour to convey directional info. There are also a variety of ways to generate bump and normal maps. You can paint them directly, but this can be hit and miss and you would need to do a lot of testing to get them right (much harder with normal maps too). You can also use software that will generate them straight from the textures but this is not always ideal as the software has to interpret the 'volume' information from the texture. As an example, see the differences in the final renders (renders are on the left, normal maps on the right) using different normal maps generated by a variety of software from the same texture in the second post of this thread on a computer graphics forum - http://forums.cgsociety.org/showthread.php?f=2&t=1057955 For normal maps, by far the most ideal way is to make both a high-resolution (which includes all the detail such as rivets) and low-resolution model and use software that can generate the normal maps by comparing the two. Although we do not have access to the in-game polygon models, this should still be possible to do by using the textures as a guide for doing the detailed sculpting on flat planes (the texture maps, normal maps and bump maps all use the same UV coordinates). This would be much easier for things like walls and flat tank panels than for something such as a person's face.

Heh, to satisfy both sides and make the portraits more useful, rather than having flashing borders, how about switching the portraits themselves out to reflect an increasingly more panicked soldier? Of course I'm joking, but then it would make for some interesting modding possibilities.

Normal mapping won't automatically improve rendering of distant terrain - likely it won't even be used for this. Substituting in low-resolution textures for distant terrain and objects is a standard for computer games (called mipmapping), though CM's routine does seem to be quite 'aggressive'. It's like it is full high res or full low res without any in-between, so you get quite harsh differences in the rendered view. Does anyone know if there are game settings anywhere to fiddle with mipmapping?

It's going to be a close shave - bada-boom!

Shaders (normal mapping) fakes a 3D effect - it makes things look more 3D without adding any actual geometry. For example, if you look straight on at something like a tank panel with rivets, the rivets look rounded and appear to cast shadows, but if you look at the same panel from the side, you will see that the panel is still flat and the rivets do not poke out. This can be seen in the screenshots of the wall; the vertical surfaces look more 3D but the top surface is still completely flat. This 3D look though is determined in conjunction with lighting and in the screenshots shown the light is almost directly overhead, which isn't perhaps the best for showing off the normal mapping. If you look at the truck in the axis AAR thread, the features that run horizontally and catch the light more (e.g. window surrounds) look better than those that run vertically (e.g. the vertical grooves of the door). The quality also depends on how and how well the normal maps have been generated. There should be plenty of room for modding, though without access to the actual models making normal maps could be a bit trickier but still doable.