ClaytoniousRex

The first beta of the GUI scenario editor for DropTeam is now ready for anyone who would like to try it out. You can download it here. Introductory documentation is here. The current release is for Windows only. Source code for the editor is available on request with a completely unrestricted license. Feedback, comments, and bug reports are welcome.

The wiki table is a great idea. You can also look in this post for a start.

You should now be prompted to update again and the fix will download (it's very small). Sorry for the bad release of 1.1.7, everyone! For the next 24 hours only, anyone who sees me in person is allowed to swat me (open palm and one time only!)

It will prompt you to update again once the fix is posted. We're waiting for Moon to bless the .exe's so it shouldn't be much longer (it's already 7am in Germany).

This was a problem with the way the .exe's were deployed for 1.1.7; it affects Windows users only. A fix is posting right now.

...is now available via Update. You should be prompted to update automatically the next time you run DropTeam. 1.1.8 fixes a crash for Windows users that was introduced by a bad deployment of 1.1.7. Changes in the original 1.1.7: </font> Fixed server crashes</font>Fixed slider buttons on tac display sometimes not responding to clicks</font>Fixed campaign bugs</font>Performance optimizations</font>Fixed handling of unstable objects</font>Increased acceleration for MBT's</font>Added 90mm AT turret</font>Improved bot formation driving</font> [ October 03, 2006, 02:46 AM: Message edited by: ClaytoniousRex ]

I would have thought that would have worked, Poesel. Will have to try it here and debug to see what's happening.

Marco did those by hand, but the Gimp filter called "Video" (under Distorts) works pretty well for making your own.

Yes, there are 3 special Names that CollisionBoxes can have. LeftTrack and RightTrack work just like their Contact counterparts (this is to make the tracks work when colliding with other objects instead of the terrain - such as driving on top of a bridge, for example). Also, the special name "Prone" for a CollisionBox can be used if the box is on an Infantry object. In that case, the box will only be active when the infantry is prone. You can use this to have one set of boxes for the standing infantry and a different set for the prone position. Yes, your summary about position and lengths is correct.

Yes, that's exactly how they work. For the existing vehicles, we put the SpottablePoints at the highest point, usually with one at the front and one at the back (so you can spot them when they only stick their nose or tail out of cover). We tried to only use 2 like this in order to minimize the amount of raytracing going on (it's pretty expensive).

The telescoping is limited with HiStop and LoStop. There's no way in the XML to attach a motor this kind of joint at the moment. If you need it, let us know what your plans are and we'll see what we can do... If you take a vector that is pointing in the shooting directiona and normalize it to unit length, then this vector is what the spread is applied to. The deviation for each outgoing round is a random from -1 to 1 * spread. So 0.45 is quite a tremendous spread! Your description of Contact is correct! Saw the docs on procedural objects, Toby and it's a good start - thanks for taking the time to get that one going! EDIT: yes, Poesel, units of measure for lengths are meters.

Yup.

New scenarios from Toby and Hub coming in 1.1.7, too!

This is a really good idea and it gives the cmd track more direct relevance than it has now. Toby's "whichever is closest" rule works really well for a first pass. LOS sharing could then be added pretty easily afterward.

Neutrino, that's how the scoring is working now except that it doesn't clamp to a maximum number of points. This is for the reasons outlined by Alex: the objective has to remain the focus for that game type. The Mercury and Cutter do, indeed, seem to absorb an awful lot of hits at the moment. Will get on the test range and see what I can find out... jby, do you mean some kind of irregular shape for the objective area? As for the 76mm, we've been very close for a long time now to making it overpenetrate. This alone would probably give it that little bit of extra "ummph" that it needs.

What was the problem and the resolution that you found, Joe? That info might help others.

Stelek, email support@tbgsoftware.com with your product key and we'll send you a link to a FTP site where you can download the update and install it yourself.

The documentation of the XML tags for objects has been greatly expanded on the wiki. We're still not quite finished but we're getting close.

Incredible work, Toby! Just to amplify on what we can all look forward to in 1.1.7, thanks to Toby: Mr. Haynes, your toolset must be pretty impressive judging from this. We would all love to hear anything you have to time to discuss about how you create such excellent work!

Yes. Looking at why they sometimes do that now. If you're on that team, then you can right click and extract the misplaced turrets and place them properly.

That definitely fixed it, Toby. Very nice.

Sure, Toby. Is the fixed one now linked in the mod forum? EDIT: Never mind; I see it. Tucked into 1.1.7 now for testing...

The problem that has been making Pavonis go down so often has been found is now in testing. 1.1.7 is strictly a performance and bug-fix release and will be ready soon.

The problem that's most likely to be causing your slowdown is now fixed for 1.1.7 and there are some other significant performance optimizations in it, too.

Faces are always going to be one-sided. If you really do *need* 2-sided faces, then we will have to give you a tag that enables that. Rendering all faces of an object this way generally causes a ton of redundant rendering to happen for the end user (since he can't see most such faces on any closed object). That's why we don't render things as 2 sided normally. So the question is: do you really need that? It's better, if possible, to make your model "well formed", which is to say it is a closed shape with no infinitely thin planes. The 2 tracks should be named LeftTrack and RightTrack. The meshes themselves should be so named. DropTeam looks at the names of the meshes as it loads a model and in the case of the tracks it uses those 2 special names to know that they need to be animated. Map your texture to the tracks so that the texture can be repeated along the V-axis. At runtime, DropTeam will move the V texture coordinate and leave the U coordiante alone. And, yes, the General is quite right - everything must be triangulated (if you don't do this, it may even crash).