Offshoot
-
Posts
674 -
Joined
-
Last visited
-
Days Won
1
Posts posted by Offshoot
-
-
Wait, can you repeat that again? Are you saying BF took something a user reported on the forum in Sept and applied it to a patch released in October?!! OMFG I thought BF NEVER listened to their user community or fixed anything.
Okay yes I am being a bit sarcastic, but the point deserves to be made as often as they have been accused of not addressing items.
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.
-
...the entire point of their existence is to get every nuanced detail of every fact exactly right.
...the three Dr.I prototypes, ... the F.1 designation of the prototypes...the production versions were marked Dr.I!
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.
-
A cause for this may be that a rifle squad occupies three AS and thus gets checked three times per unit while the Sherman only gets one check. But this seems not to be reflected in the probabilities.
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.
-
Well, I would think a moving unit CHANGES LOCATIONS and needs to have LOS checked more frequently than a stationary unit? As well, if a target is moving, the stationary units would need to poll their LOS more frequently to see if they have a shot. (By more frequently I mean in comparison to stationary units, not in absolute terms.)
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).
-
The "flow" of the game would be very slow and difficult. (Given a map with plenty of concealment.)
Okay, CM:HS is an extreme, but it shows how bad a game it could be if invisibility (or camo abilities near that) were used. Put that next to CMBN/CMFI's spotting model.
If perfection is somewhere between these two extremes, is it better to approach from the too easy side and get closer, or from the too hard side and work closer?
(Hint: this _is_ a game!)
Spotting does seem too easy right now. But, and this is the hard part, how do we quantify what makes it too easy? Given that, how would we quantify what it should be, once we've defined what it is?
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
-
Please note that this tests does NOT determine if spotting moving units is easier than prone ones. Its just to see if movement CAUSES spotting.
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?
-
Actually, 10 identical, independent Tigers: the purpose would be to see if the spot "polling" period (spp) changes from 7 seconds. With more units present does the game change the spotting routine? Is it load-leveling the processing based on the number of LOS origination points, or is it fixed at 7 seconds?
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).
-
But the dissing of stock artists here really rubs me the wrong way.
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.
-
Oh yeah and umm, who was actually right?
Galileo, but only since 1992
-
Just like textures. They're bmp files. You'd need to convert your bmp template art to normal map format but there's freeware photoshop filters and standalone mini-aps on the web to do that sort of thing.
Actually, making normal maps is so simple I can imagine a series of 'enhanced' 3rd party normal map mods to spice up the game. Just last week (at the 11th hour) all the game's 'character faces' got the bump map treatment.
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.
-
This is from the list of new features with v2.0:
http://www.battlefront.com/index.php?option=com_content&task=blogcategory&id=297&Itemid=507
You should notice an improvement.
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!
I Hope This Is a Bug and Not a Dumb Design Decision
in Combat Mission Battle for Normandy
Posted
I'm not sure that is the case. Rather, some are arguing that the status quo (where, assuming the test is correct, moving = paused != stopped) is not correct and should perhaps be moving != paused != stopped. In this case, pausing would have costs compared to stopped.
Assuming that, in-game, a tank that has stopped moving (i.e., does not have further move orders) for just 1 second is as accurate as a tank that has been stopped for much longer, scenario c could be gamed in some circumstances to have less costs than the others by making sure your end of movement and firing coincided with the end of a turn. Unfortunately, I think that the only way to overcome this would be to program accuracy as a function of time stopped, as mentioned.