ClaytoniousRex

Yes, everything must be triangulated or the game will (eventually) crash. Reducing face count at the expense of higher per-polygon vertex count is a net performance loss on all modern GPU's.

Active camouflage like the Predator's could be easily modded with alpha in the infantry textures. To really give it that nice refracting effect would require a bit of shader work, though.

A platoon of Valkyries has landed on a remote moon in the Wolf 9775 system in search of ... a shrubbery!

It sounds like in one (or more) of those many conversion steps, the transformations for the model's primitives got hosed up. Since it sounds like you're able to export .obj files, why not just use those for your model? You do not have to use .cob files. For the collision models, you do not need to do anything with image files of certain names. That was only for the CobDump tool which you don't need to use since you're using collision models instead. You use one tag for each of your 6 collision models for each object, like this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"><CollisionModelFront>RamsesCollisionFront.obj</CollisionModelFront> <CollisionModelRight>RamsesCollisionRight.obj</CollisionModelRight> ...</pre>

There's a pretty good case for ditching the Cutter in favor of a unified Mercury, giving the Mercury all of the features formerly possessed by the Cutter, especially in light of the other thread on this topic which describes improved digging done via charges rather than a blade.

We've been leaning toward not simply improving the digging, but changing the way you do it completely. The Cutter would use charges instead of a blade for digging. The blade would be removed and when you toggle into the digging mode, it would begin firing excavation charges downward into the terrain at a fixed rate. You could drive in whatever pattern you like, firing charges down as you go. Once you toggle out of the digging mode, *all* of the charges that you've placed will detonate after a 15 second delay. The resulting pattern is similar to what you would have achieved by driving that path while digging, but with some serious perks: the terrain wasn't deforming as you drove (so driving was easy) and your speed wasn't reduced while driving the pattern. Much less painful and quicker. Any thoughts about that approach?

Can you hit the Details button on the crash report and email its contents to support@tbgsoftware.com? Thanks!

Phil, to register a 2nd account email your product key, current username/password, and desired username/password for the 2nd account to support@tbgsoftware.com. We do your 2nd one manually on the account server. Zik, is your eLicense issue now OK? Is a 2nd account now all that you still need? If so, email as above.

That is a really good idea, Iceman!

We use a little app we wrote called Spawner that restarts dead processes. You can grab it here if you want to use it. You just pass your normal command line to it, so something like this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">nohup ./Spawner ./SpaceVikings -enterlobby false -hostmode server -password blah -packetsize 2000 -lobbyname Delta_Pavonis -deploymenttime 320 -numbots0 8 -numbots1 8 -dynamicbots true -gametype Objective -gamelength 35 -parachute false &</pre>

Sure, that makes sense Aittam. We would work total combat effectivess into the scoring of occupiers. So in my example above of 2 MBT's scoring full points, the system would actually be saying "2 mobile vehicles with thick armor and working 120mm guns" to arrive at that conclusion. So if one of them was unable to fire, its contributing score would be far, far less (for example). And I think you mean they should have LOS to the objective in order to score, right?

As for 2, yes. Actually, the ability to act as someone else's gunner is already there but we hadn't planned on releasing it before the ww2 mod. If there's interest, we can go ahead and let it out.

Works fine here. Let's put a few of your "zones only" scenarios into rotation in 1.1.6. Working on the "improved ScenarioList.dat" now so we can mix game types in the rotation, too.

Regardless of the max acceleration of the tracks, you still also have the acceleration of the user's throttle (his input), which is controlled via the Acceleration tag (I think it's actually on the wiki for once!) So you would need to raise that one, too, to get the result you're looking for. Careful, though, you don't really want instant acceleration up to max speed as you described. Imagine what would happen physically - or just try it . But there's certainly room for much faster acceleration than what's there now.

Stan, can't he simply use the MaxDropElevation thingy to completely solve this stuff with the bots and tell them to drop on the "floor"? Alex, that's very cool. And, no, I don't only mean the intro image. You know, with a little random perturbing of the maze walls, it might even look kind of "natural", but it's more honest the way it is.

The symbology is actually pretty simple for the bots to interpret. For the first release, they will only pay attention to the Drop Zones and No Drop Zones. On a subsequent release we'll allow them to obey almost all of the others. I'm finding already that it's actually much easier to layout a few general orders via diagram and then let the bots flock to those orders however they like. I don't care if Collins is the one who pins the enemy here, I just want someone to do it right now.

Yes, I think we need to get the enhanced tools for defense (real digging, more and better turrets, etc. as discussed elsewhere) out first so that we're sure the defender really has a defender's advantage (not only on those scenarios where this already happens to be true). Then, it's full steam ahead on giving the attacker a superior force size. The two would probably need to be released together. That would be really excellent, along with the "orbital defense battery" kind of installation mentioned in adz's thread. Do you have any more ideas for perks that could be granted for building capture? Anything that smells like a "power-up" is anathema, but feasible advantages gained by control of facilities would benefit all game types across the board. Great idea, and I think already doable with the current XML. Will look... You should have this option in your scenario's GameType tag with the system described in the Objective Scoring thread.

I've spawned a new thread about scoring for the Objective victory condition. It's an important topic, but let's keep this thread on new victory conditions and game types.

This is a spawn from the Victory Conditions thread. This one is specifically (and only) about scoring for the Objective victory condition. There's a concensus that points earned for controlling an objective should be proportional to the number (and maybe type) of units that are actually sitting on the objective. We're open to that, but first I want to offer some history and explanation of why the scoring currently works the way it does. Right now, the defender is assumed to control the objective unless the attacker has at least one unit within its radius. When the attacker has anything within the radius, points start peeling off of the defender's score and onto the attacker's over time. When attacker units are cleared out of the area, points move back to the defender at a slower rate. For a short while during beta, we did make the score depend upon the number of units within the radius exactly as many here are now requesting. So if the attackers only had a single unit near the objective, then they would slowly gain a tiny trickle of points. To gain the maximum possiblke points, everyone on the attacking team had to pile into the objective area. Similarly, to regain lost points at the quickest possible rate, the defending team had to get all of its units into the objective area (since you get more points for more units). Based on that description, you can probably already see the problem. Here's an example of a good defense of the bridge in Dead Gulch (green is the defending team and red is the attacking team): The defender is holding the attacker off at a distance. The defender is deployed in what happen to be, at the moment, good tactical positions in order to keep the attacker away from the objective. Notice that the defender is not sitting directly on top of the objective. Sitting directly on any objective is rarely the best way to defend it. But with a scoring system that awards points proportionally with the number of units that are sitting on the objective, the kind of defense pictured here actually penalizes the team. The team is losing points because they are in good tactical positions instead of just piling onto the objective itself in a big heap. This is even more true if you look at the same figure above but now imagine that green is the attacking team, which has already pushed the defenders off of the objective. So now the roles are reversed - now that green has taken the objective they are defending it against counterattacks from the defending team. If they deployed as pictured above, they would be bleeding points. They would be penalized for not all being in a big pile on the objective itself. When you only get maximum points for being on the objective, then this deployment is the only one that gives you the max points: Not a very effective arrangement. "Let's all huddle right on the bridge and just try to hang on for dear life while the other team comes at us in wave after wave!" The other reason that scoring works the way it does now is simply because of the definition of "defense". We sometimes complain that the attacker is winning the game when he only has a single Paladin sitting near the objective. Let's imagine that your commanding officer has ordered you to "defend the bridge". He comes back a few hours later to survey the situation. He asks you "Is the bridge secure as I ordered?" "Yeah, except for this one enemy armored vehicle sitting on it. Besides that minor detail, the bridge is secure." What kind of look does he give you at that point? If the enemy has breached your defense and is physically present inside of the perimeter that you were ordered to defend, then have you succeeded in defending that perimeter? It's secure because only one enemy squad or vehicle is inside of it? No, it's not, and that's why defenders do and should lose their points due to a single enemy unit's presence on the objective. However, from the attacker's perspective, it's quite a different conversation from the CO. The attacking team's CO would not consider the objective taken if only a single attacking unit had made it into the objective area and that's where the current point system really falls down. Now, having said all of that, we definitely see where everyone is coming from with the current problems. So I laid out that history and explanation not in order to say everything's fine right now, but so that whatever we do now won't repeat the mistakes of the past. There clearly is room for some kind of relationship between the amount of force occupying the objective and the points earned for occupying it, but without going "all the way" - some (probably low) number of occupying units should be the maximum that are considered. And, for that matter, the types of units should count. So, for example, having either 2 MBT's, 3 Apollos, or 4 infantry squads on the objective should fully count for maximum points. Any more than that do not increase the total score or the scoring rate. Having only 1 MBT, or only 2 infantry squads, gives a team half as many points. This way we do not encourage the entire team to pile onto the Objective, but they do need to commit at least some decent sized "holding force" to the objective itself. I think this solves both of the issues raised above as well as those raised in other threads. Thoughts? [ September 14, 2006, 11:50 PM: Message edited by: ClaytoniousRex ]

"Killed with a tractor" I'm still laughing... good stuff!

Outstanding, Toby! Just tried it out. That is a really impressive terrain and a very fun scenario to play. Will be playing a good LAN game on it tomorrow for a "real" test. It looks like you've mastered all of the essential elements; can't wait to see some more scenarios with your name on them! Is it OK with you if we include this one in the next update?

Here's how the tac is looking after some much needed loving. Other improvements include much cleaned up selection and orders menu (for example, you no longer have to use hotkeys to issue orders to multiple selected units - the right click works properly with group selections, "Hold ALL drops" and "Allow ALL drops" buttons for the entire team, etc.)

That would be a much better way to select game types! What does a long ping run (50 or so) from the server show against tbgsoftware.com? Is there some packet loss or extraordinarily high pings? The dropships problem is because I gave you the wrong tag. It's really Team0NumDropships not NumDropshipsTeam0, etc. Sorry about that.

Yes, you can mix model types, Poesel. And to do what Tanki is talking about, just remove the HighTrajectory tag from the mortar to make it shoot straight into the ground.

Do both of those crash on the server? EDIT: The reason I ask is because one of them only has a Territory game type in it. So if the server is set to run Objective, and it reaches that scenario, it will try to find an Objective game type and fail, so then it will "fall back" to the CTF game type but that will also fail. Bad things may happen? [ September 08, 2006, 10:33 PM: Message edited by: ClaytoniousRex ]