stas'den - game

ACFTools+AC3D tutorial

Wed, 10 May 2006 01:22:10 -0300

My attempt to show how is it possible to make X-Plane models using AC3D editor and my ACFTools.

Open AC3D
Now you shall use Side (ZY) view to draw a shape of revolution object to be imported. You may wish to draw it as Polyline:

Note that the shape polyline has exactly 9 vertices and it is closed.
Put your shape a bit off-center. You will be revolving it around Y axis, so just create small gap between shape edge and Y axis:

Later you will see the meaning of this gap
Select your shape as group, and do "Object -> Revolve...". Enter with 180 degrees, Y axis and 11 segments:

Wow, look, you got half of your object:

By default it has flat surface but you may wish to set a smooth one like I did.
Go to Side (XY) view. Select your object and "Edit -> Duplicate" it. Then flip it on X axis. Now align both halves so they again have a very small gap between them. DO NOT SNAP THEM TOGETHER!. Then do "Object -> Merge". You should get this:

Note "move to" coordinates. X is 0.53 instead of 0.5! That 0.03 difference on both sides of Y axis makes that desired gap.
You may be wondering why to have yet another gap here? Well, 18 vertices in each section are supposed to be sorted automatically in counter-clockwise order. If you have overlapping vertices like in this case, algorithm treats vertices with same coordinates as being one vertex and thus messes everything. Sorry.

VERY IMPORTANT: switch to vertex selection mode. You should see exactly 216 vertices. If you do not have 216 vertices you're terrible wrong, start over!!!
At this moment you are ready for the most boring part. Split AC3D-generated object to sections that X-Plane would accept. Now a bit of theory. X-Plane treats all aircraft models as 3D objects with 12 sections with 18 vertices each one. If you try to feed it with everything else, surface will be mismapped. Thus you NEED to cut your AC3D object into 12 sections with 18 vertices each one. And 12 * 18 = 216, got it? . OK, to start section splitting you need to remove all surfaces. Sorry again "Surface -> Remove surface only". Now hurry up, "File -> Save" as original.ac.
Let the pain begin. >%E~
Go to Plan (XZ) view. Select 18 vertices:
1. Copy these vertices to clipboard. Delete them.
2. "File -> Save" original.ac
3. "File -> New..." and paste 18 vertices from clipboard.
4. Save as section01.ac
Now reopen original.ac. Select next 18 vertices:

Do the same steps as for first section, but now save it as section02.ac. Unless you are screaming in anger extract all the 12 sections in this way. Calm down, it's not that boring when you start to do it
Understood the meaning of the first gap? If you added none, when you try to select 18 vertices you select 48 each time you reach center, as you select some central vertices from other sections.
Supposing you were patient enough, at this moment your original.ac is empty and you have sections 1 to 12 in separate .ac files. Now merge them back. No, I'm not kidding. Merging all sections in sequence from 1 to 12 puts them in the order that X-Plane accepts. OK, I think that there is no need to explain how to "File -> Merge.." 12 section files in one. The result will look the same as original.ac (rest in peace) but internal order would be the right one. You should now "Object -> Merge" & Group 216 vertices (assure that you still have 216!). Call your group "body[45]", it will import to X-Plane as "misc. body 1":

Rescale this object to any size you want (in feets) and save all the stuff as importable.ac.
OK, now go and merge importable.ac in any model of yours using ACFTools:
```
acftools -e -acf C:\X-Plane\Aircraft\UPHO.acf -txt UPHO.txt
(prepare UPHO.txt to work with)

acftools -me -ac3d importable.ac -txt UPHO.txt

(merge! don't worry about warnings)
```
Fine! Next step is to edit UPHO.txt in your favorite text editor (I use Write) to mark that "misc. body 1" was added:
1. Seek for PARTS_WingBodyGear_part_eq[45] and make it "= 1"
2. Seek for PARTS_WingBodyGear_body_r[45] and set it to desired radius of your body (or Plane-Maker will mess the things up)
3. Seek for PARTS_WingBodyGear_body[45][0][0]. This was your section01.ac. Remember the second gap? Remove it setting all the X values for 1^st section to 0. Remember that each section has 18 vertices, so, don't harm neighbor ones!
4. Seek for PARTS_WingBodyGear_body[45][11][0]. This was your section12.ac. Make the same as for section 1
```
acftools -g -txt UPHO.txt -acf test.acf
(generate test.acf from edited .txt file)
```
Finally open test.acf in Plane-Maker and see what the heck you just did =D
It may be a bit broken, just fix it in Plane-Maker as normal body.

ACFTools (for X-Plane)

Wed, 10 May 2006 01:09:12 -0300

The Plane-Maker from X-Plane v7.x is fun and easy to use... Although I found it a bit limited to edit my planes' fuselage. 20 cross-sections aren't enough, sometimes. It would be nice to export the fuselage shape into any 3D-editor and fine-tune it there... This is exactly what my ACFTools are supposed to do. Please note that X-Plane v8.x is unsupported, unless you create & edit a v7 model and then import it to Plane-Maker v8. But I believe this isn't a problem: X-Plane v8 is able to use OBJ format files (which can be imported/exported by AC3D and Blender plugins) as parts of an aircraft, thus, extremely weird shapes are perfectly possible without even touching the ACF file.
Now, what exactly ACFTools does? It is able to process the file that stores all the aircraft data (except the textures), in the binary ACF format, and dump all the data in the human-readable TXT format. It is the same format as for Tony Gondola's ACF2Text utility, which inspirited my ACFTools. Then, ACFTools can extract the 3D model of the aircraft from this data, and export it in the AC3D format. After that you can edit the aircraft's shape as you want using AC3D and make the inverse process: from .ac to .txt, and then from .txt to .acf. Here comes the brief set of ACFTools features:

Convert from ACF (aircraft) & WPN (weapon) formats to TXT format and vice-versa.
Extract AC3D model from TXT file, along with wings and propellers (using the real airfoils!).
Import AC3D model into TXT file (fuselage, nacelles, wheel fairings & external fuel tanks only)

3D model extractor is also useful if you want to use X-Plane generated aircrafts somewhere else; as in your own Computer Graphics compositions.
ACFTools was written in Perl, thus it is able to work under Linux, MacOS & Windows. And it is Open-Source & highly modular, so you can modify it as you want, or use my functions for your own needs. When you start ACFTools, this is what you get at your console:

##############################################################################
[ACFTools v0.62a] Set of tools to play with ACF files outside of Plane-Maker
Perl script and modules coded by Stanislaw Pusep 
Site of this and another X-Plane projects of mine: http://xplane.sysd.org/

Allows you to:
 * export X-Plane (www.x-plane.com) aircraft data files to human-editable
   plaintext format and 3D mesh editable in AC3D modeler (www.ac3d.org).
 * import plaintext/3D mesh back to ACF file.
##############################################################################

Usage: acftools.exe  [parameters]
 o Commands:
	-extract [DEF]	: extract TXT from ACF (opt: using DEF definition)
        -generate       : generate ACF from TXT
        -merge          : merge body from AC3D file to TXT
 o Parameters:
        -acffile FILE   : name of ACF file to process
        -txtfile FILE   : name of TXT file to process
        -ac3dfile FILE  : name of AC3D file to process
        -noorder        : DO NOT sort vertices while merging bodies
        -noac3d         : DO NOT generate AC3D
        -(min|max)body N: write all bodies in specified range to AC3D
        -force LIST     : force extraction of bodies LIST (comma-separated N)
        -normalize N    : normalize wings to N vert/surface (N>=2 or no wings!)
 o Notes:
        * You can use abbreviations of commands/parameters (-gen or even -g
          instead of -generate).
        * The only required parameter for "extract" command is -acffile.
          Both -txtfile and -ac3dfile are derivated from it.
        * "generate" command and -txtfile has the same relation.
        * By default "extract" uses the latest DEF file.
        * "generate" doesn't need DEF at all (it is implicit in TXT)
        * If file to be created already exists backup is made automatically.
 o Examples:
        acftools.exe --extract=ACF700 --acffile="F-22 Raptor.acf"
        (extract 'F-22 Raptor.txt' from 'F-22 Raptor.acf')

        acftools.exe -e -acf "F-22 Raptor.acf"
        (same as above)

        acftools.exe -me -ac3d ladar.ac -txt "F-22 Raptor.txt"
        (merge *single* 3D body from 'ladar.ac' to 'F-22 Raptor.txt')

        acftools.exe -g -txt "F-22 Raptor.txt"
        (reverse operation; generate 'F-22 Raptor.acf' from 'F-22 Raptor.txt')

The most important thing you should know is that to convert from the binary ACF format to TXT, ACFTools uses one of the files stored in the defs directory. By default, it is a ACF740.def, which works for X-Plane v7.40 and later. You can specify any definition file you want, as shown on the screen above. You can also write your own definition files, if you have the structure specification. Note that to convert TXT back to ACF, no definition is necessary, as the TXT format itself holds all the data necessary to build the binary file. The second thing is to specify the file that ACFTools should convert. The name of the converted file and every of the intermediary files will be generated from this name. When converting from ACF to AC3D formats, TXT file is generated automatically. Please note that when you want to put the edited aircraft part back into the .acf file, you must save this part as a .ac separate file, then merge it into the TXT file, and after that convert it into ACF! Yes, it would be nice to have a GUI to automate the entire process, but I'm too lazy to do that! Anyway, may the source be with you
I strongly recommend you to read the docs\README.txt file contained in the ACFTools package before you start using it!

X-V8L model

Wed, 10 May 2006 01:02:36 -0300

General characteristics
X-V8L experimental joined-wing ultralight design
Crew	1 pilot
Engine	two small 2-stroke engines (similar to "JPX PUL 212" or "SOLO 210")
Power	15 hp at 6000 rpm (30 hp total)
Dimensions
Wing area	40 sq.ft (3.7 m²)
Wing span	12.2 ft (3.7 m)
Wing aspect ratio	8.0
Length overall	8.2 ft (2.5 m)
Height overall	4.3 ft (1.3 m)
Weights
Max. fuel on board	40 lb (18 kg)
Weight empty	150 lb (68 kg)
Max. weight	400 lb (181 kg)
Payload	210 lb (95 kg)
Performance
Max. cruise speed	125 knots (230 km/h)
Max. climb rate	1200 ft/min (6 m/s)
Service ceiling	15000 ft (4500 m)
Stall speed (flaps down)	45 knots (83 km/h)
Take off run	1000 ft (300 m)
Landing run	1000 ft (300 m)
Max. range	400 nm (740 km)

This is a model I developed for X-Plane to test this uncommon aerodynamic scheme. It's not unique, yet: some people actually think that joined-wing design is superior to the traditional one. Here are some examples of joined-wing & box-wing aircrafts:

My idea was to create some kind of a "flying scooter". So, my X-V8L ultralight was based on the famous MC-15 Cricket (a.k.a. Cricri), which is the world's smallest twin-engine aircraft:

A "real world" reference is also important to evaluate if this thing would fly at all
Thus, X-V8L has (almost) the same power plant, weight and wing area as the MC15 Cricket. In fact, to obtain this data, I had to peek into another X-Plane model, the MC15 Cricket by Emmanuel Sanvito (a.k.a. Namu).
Now, the design itself is completely different. First of all, X-V8L has more wings and a bigger wing area. Second, it makes use of a ducted fan. This is supposed to give 50% thrust increase, and can be easily made for smaller propellers. At the time I modeled X-V8L for X-Plane, there was no ducted fan-specific option, so I had to simulate it increasing the engine power up to 22.5 hp. And rudder/elevator surfaces are currently inside the duct. This is supposed to redirect air flux to give better handling, as X-V8L has no horizontal/vertical stabilizers. On this model the effect is reforced by applying "vector trust" option to our tiny propeller engines.
The flight test results are surprising. All the data from the table shown above were obtained from the "flight tests" performed under X-Plane v7.10. And it got quite close to the "real thing": the MC15 Cricket!

Duke3D D.M. cheater

Tue, 09 May 2006 16:47:51 -0300

E1L2 near the dark room elevator: enhanced brightness

Do you consider yourself a good Duke3D deathmatch player?! Neither I do
For our luck, 3D Realms released Duke3D source code under GPL license at April 1^st, 2003. No, I'm not fooling you! Since then, several people are enhancing this classic game, extending it's portability and adding some cool features to it. There are ports like icculus Duke3D port and JonoF's Duke Nukem 3D Port. So, with the source in my hands, I decided to make my own version. I called it Duke Nukem 3D v1.666. It is 100% compatible with the original MS-DOS Duke3D v1.5, and adds some cheats into deathmatch games:

Omniscience. You can peek at your opponents screen (using "Coop View", which now works even in the deathmatch mode!), and hear the sounds they make (you may hear them scream when hit at the long distances). You are able to see in darkness all the time, without using the night vision goggles, and without that ugly green screen tinting. You'll know when your opponent drops a holoduke, so you won't waste your ammo with it. And finally, you won't see that confusing steroids trail anymore!
Aim bot features. Aim bot (which can be turned off!) will track the closest visible opponent automatically. If you're close enough to your opponent, aim bot will also try to kick him while shooting. And it will auto-activate med kit when you get shot! Another cool feature associated to the aim bot is the auto-jetpack. Jump from a high place, and jetpack will be activated automatically when you're close to the ground.
Practical enhancements. When you find a new weapon, game won't switch to it automatically. You will always see which weapon your opponent is using, without activating the "Weapon Mode". Demo viewer doesn't switches camera automatically anymore. And game doesn't prompts you with credit screens/animations when started or finished.
DNCROZ during multiplayer?! Even this is possible in the cheater! The only problem is: both players should type it when the game is paused, or the "Out Of Sync" condition occurs. Other cheats that work in the multiplayer game are: DNSCOTTY###; DNCOORDS, DNVIEW; DNRATE; DNBETA; DNTODD; DNSHOWMAP; DNALLEN; DNDEBUG.
".ANM viewer". Just type DNENDING while playing, and the game skips right to the episode ending video

Please note that the most useful cheat, the aim bot, only works fine with the game's internal AI opponents (A.K.A. "PP bot", started with "duke3d.exe /q2 /a" command). It may work in the acceptable way on crossover 100 Mbps LAN connection (peer-to-peer), although... And the worst thing ever: Duke3D v1.666 will only work on real DOS mode, so forget it if you only have Windows NT/2k/XP (anyway, those who play Duke3D over network frequently do have Windows 9x installed for this specific purpose )
Still interested?! It's a bit difficult to install, though... First, you need to have the original Duke Nukem 3D v1.5 installed. Second, backup it!!! After that:

Unpack the DN3D1666.ZIP into your Duke3D installation directory, overwriting files.
Configure Duke3D. Run SETUP.EXE, and go to "Controller Setup", then "Choose Controller Type", and then select "Keyboard and External". After this, select "Setup External", "Change External Program Name", and type "DUKE3D.EXE" there. Now you can save config, but DON'T LAUNCH A GAME YET!!!
(NOTE: it would be great if you disabled Turn_Left and Turn_Right keyboard bindings, although, if you don't plan to use "AutoAimSelfCalibrate" setting in DUKE3D.666 file or won't use Auto-Aim feature at all, you don't need to do this).
Now, edit the file DUKE3D.666. Open it in your favorite editor (EDIT.COM ), and you'll see that it's almost self-explanatory. Note that your mouse is now configured by this file, any SETUP settings will be ignored! Also note that default mouse settings for v1.666 imitates the default settings for the original Duke3D v1.5.

I also recommend you to read the "DN3D1666.ME!" file, supplied in the download package.

Relative project: GRP packer plugin for the Total Commander.

Sorry, no source code is available for direct download. However, if you're interested in it, contact me and I'll provide it to you! Thus, GPL license of the original Duke3D source wouldn't be harmed, I beleive...

GibCounter QW stats

Thu, 20 Apr 2006 01:48:22 -0300

GibCounter is a tiny yet quite useful game statistics generator for QuakeWorld games. It operates parsing frag*.log files generated by the QuakeWorld game server. If your server doesn't generate such a log files by default, you may enable this feature executing the server as follows:

qw-server +set fraglogfile 1

Of course you can also edit your server's .cfg files to enable frag logging. You may run GibCounter on the same machine (and, on UN*X systems, as the same user) that runs the game server. If it's a QuakeForge server, then GibCounter will locate log files automatically at the path $HOME/.quakeforge/qw. For the different ports of the QuakeWorld server, or a QuakeForge server operating as a different user, you may specify the location of the qw directory manually. To do that, simply pass the new directory as an argument to GibCounter (using your favorite command line shell):

perl gibcounter.pl /home/qserver/.quake/qw

GibCounter outputs the generated HTML code directly to STDOUT. So, if you're going to add it into your server's crontab, don't forget to pipe the output to some file! For example, the following crontab line will regenerate GibCounter game stats every 30 min and make it available through the URL http://yourserver.com/~youruser/gibcounter.html (file paths & crontab format may be different on your system; so ask your system administrator if unsure):

0,30 * * * * perl $HOME/gibcounter.pl > $HOME/www/gibcounter.html

GibCounter is also highly theme-able: CSS style of almost every element may be changed within gibcounter.css file. Of course, you can also edit the HTML template which is contained inside the Perl source itself
The game statistics page generated by GibCounter is self-explanatory. On the top, it will show players ranking, sorted by (guess what?!) the frags they scored. Frags are computed as: kills minus suicides. GibCounter also computes how many times each player was killed by others. And, on the bottom of the generated page, some computed totals are shown. This includes the period of time for which the stats were made, the top fragger (the best) & the top fragged (the worst) players. Please note that players with default nicknames, such as "unnamed" or "user-#", are automatically excluded from being processed, simply to avoid useless information bloat (as many different players would be rated as one, with very high kill/death number)!
By the way, GibCounter preserves the colorization of the graphical font in players' nicknames (Quake console is able to print some ASCII characters in white, orange, gold & brown colors), and translates all symbols into readable ASCII.
So, after all, how does GibCounter-generated page looks like?! Look for yourself, here are some example stats. Also, feel free to modify the program itself to fit your own needs!