ClaytoniousRex

DropTeam itself seems to handle lag extremely well (you can do some forum searching for comments). The main issues, when you have any, are being a long way from the few servers that are available or simply a bad path between you and the server you're playing on. Other servers come and go over time - we always run a couple that are in a data center in Chicago, USA, we run some on the US west coast from time to time, Poesel may be running one in Europe soon, another US player will probably be running one again within a couple of weeks, etc. The bottom line is that the game handles lag and Internet play very well, so the main issue you will have is finding a good server to play on from your particular location. (Of course, you can also play on LAN with your buddies. )

Yes, these are simple text files (XML files) and they are what Yurch has already put together for you. Open one of these files in a simple text editor and you will see that they're largely self-explanatory. They not only say that a Mjolnir is composed of this chassis with that turret and that gun, but they also describe the spatial relationship between these separate objects (where each object is mounted on its parent and what kind of joint links the two, including optional joint limites, etc.) For the collision models, you need a separate collision model for each facing. So first create your "non flair" mesh of the complete vehicle. Then delete all faces that aren't considered FRONT and save that as MjolnirCollisionFront.obj or something. Then go back to the original and delete all faces that aren't considered BACK and save that as MjolnirCollisionBack.obj. Do this for each of the 6 facings. In the end, you need 6 collision models, each one containing the 3D faces for one of the 6 directions. Since these 6 collision models will be loaded at runtime to read in the collision triangles, please do the end users a favor - make your collision models untextured and with a simple, flat material color. No need to wasre resources loading a textured model that the user will never see.

All AA shows up on tac now in 1.1.4 - Hermes, Bacchus, Galaxy, turrets, buildings, etc. Jammed friendlies don't stop showing their radii. Alexander ... SQUIDLORD ... Williams. That may be the very best forum name ever.

Finally made a start on the tags, Mace. Some useful stuff already there but plenty left to go...

Yes, as long as they're sufficiently small, that's a great idea.

OK, the "CollisionModel" thing I described above is now working in 1.1.4. If you haven't already made things work with CobDump then you might prefer to wait for 1.1.4 and get collision triangles "the easy way" instead.

I do, too. The usual worry is accidentally introducing something that greatly upsets balance. However, in the case of the Bacchus, the main issue isn't even balance per se; the vehicle's "unjammableness" and constant presence on enemy sensors are pretty good counterweights already. But it causes a required change of tactics that is sweeping. With these things out there, both teams now basically have to first earn the right to use dropships by first hunting down and destroying the other team's Bacchuses (or at least probing from the deployment zones to verify that the other team hasn't deployed them). This is an interesting and probably good thing, and not so different from attacking a team that has done a good job of placing the new Cobra missile turrets, but since it's such a big change to how scenarios are played a little caution is in order. I imagine SOP will be to bring in some mortars via the deployment zones and start working hard on those glowing Bacchuses in the distance. Tweaking this individual unit aside, you're absolutely right that more of these mobile units of high strategic value add a lot of interest to the overall gameplay.

Yes, you can do that with the 120mm with only XML changes (so you can Mod this right now without any code changes from our end). Doing #2 would be tricky, though. You could do it as a coaxial (even an invisible one so it looks like it's coming from the main gun).

OK, it's hooked up as unjammable and also always present on the other team's sensor net - you can always see this thing. I slightly reduced the ROF of that Vulcan just so we don't clobber network bandwidth with this thing (should still be high enough to meet its intended goal, though). This is, indeed, a new concept. You're right about that launcher staying busy, especially on the smaller maps. I think that for 1.1.4, we should put the Bacchus in the inventory on some of the scenarios instead of in the standard inventory. This way we can all play with it online and probably tweak it a bit before making it a part of every scenario by default. Sound good?

That page is already a very good read, Jay, and will be a big help to beginners. Well done!

The concept of a small, remote platform like this is great to see. I'm sure you can iron out the details, but the concept is great. It might even be nice in the future to allow the Mercury and/or the Cutter to carry 1 or 2 or 3 of these as cargo and be able to deploy them when needed, like moving turrets which can be returned to the parent.

The turrets are back in place in 1.1.4, which is almost ready to release.

Dead pods no longer deploy mines in 1.1.4. Their doing that in the first place wasn't intentional, but this bug demonstrates the main reason that we've been reluctant to introduce artillery delivered mines so far.

Two things that can help with this: 1. You can drop premade "clusters" of things by using an include file. See some of the campaign scenarios for examples. You could use this, for example, to drop premade "bases" into your scenarios where a cluster of buildings are all at the right offset from one another. 2. We're 99% finished with an actual "editor" mode that allows you, from within the game, to pick on the terrain to place objects and then save your scenario file from there. Unfortunately, this won't be ready for 1.1.4. In the meantime, every time you CTRL-click on the terrain a line saying "PICKED x,y,z" is written to your log file (where x,y,z are the coordinates of the point where you CTRL clicked). You can use this to quickly find places on your landscape. This can help just a little until you have the real editor.

Looks like a good objective battle - a simple raised plateau like that is a good idea for Objective. It's neither an impenetrable fortress nor a trivial terrain feature. I really enjoy the background text and overall settings for your scenarios (Hub also does these very well). Also good to see the thermal vents on there! Looking forward to playing this one on the LAN tomorrow and online with 1.1.4.

Yurch, do you need anything else besides the new "unjammable" tag to get this puppy wrapped up? If that's the last thing you needed, then send me your final .physicalobjectgroup for it and I'll put the new tag in and include the Bacchus in 1.1.4.

There's a probable fix for you in 1.1.4. Shouldn't be long.

Now fixed for 1.1.4 (thanks to Konstantine for the dump!)

Seems to be working correctly on the firing range.

B0nes gets 100 karma points for that one!

The "why" of Haven, in particular, is particularly weak. That particular hill isn't even of any significant value to conventional, non-drop forces since it's nothing special relative to other terrain elevations in the region. In cases like this one and in Twin Peaks, it is really the scenario author's responsibility to offer more explanation of why these locations are valuable and hopefully provide the needed flair elements (such as tunnel entrances) to visually indicate what's important about them. In that respect, on some of these scenarios created by us at TBG, we've failed to do a good job. As for the "who are we as players" discussion, please continue! It's excellent reading! Honestly, we've made no attempt to apologize for the fact that players at keyboards are ultimately playing this game, so we never attempted to justify things like taking control of different units in the back story. However, just the initial brainstorming that you guys have done above is outstanding and it would be great to update the background story with these details and, once that base is in place, to go ahead and start wrapping actual gameplay around those ideas in the future.

Native .obj support, including fixes to the Animation tags that Yurch ran into, is now up and running for 1.1.4. Same goes for the .3ds format. So you don't have to use .cob files anymore. Poesel, to answer your question, Yurch has managed to get a model into the game but only with some remaining significant problems (the animation thing I referred to above). With 1.1.4 it is Cake.

Now fixed for 1.1.4. Now fixed for 1.1.4. Now fixed for 1.1.4, and also the same kind of problem with squad mates is fixed, too. The reloading reticle now also shows to reflect the delay when you switch ammo types in 1.1.4. What you guys are probably both seeing is that if you do not have your own controllable unit on the ground, then you get kicked out of observer mode periodically. This won't happen if you do have a unit on the ground. Will fix, but probably not in time for 1.1.4. Not to excuse bad flying, but at least now in 1.1.4 you can hit the "special action" (b by default) key to exit the dropship at any time. You can use this to take a chance on bailing out early, and of course you can use it in these bad situations where you're "stuck". Now fixed for 1.1.4. Now fixed for 1.1.4, including all of those cases where the ammo indicator was lying when you took control of a bot, etc. Now fixed for 1.1.4 (thanks for pointing out the actual problem in the .scenario files!) We can't reproduce that one here, Dark. Can you send the crash dump .zip from your \bin subdirectory? That will let us fix it.

Oh, please don't Adz.

It's now available.