Romolus

I can't find anything funny about this. Most BAS members are also working on projects with other MOD teams. So what's the point of your post? I also have the impression that most of the ppl posting here and requesting things didn't ever try to make something similar on their own. Otherwise I really can't explain why ppl are asking (and even demanding) allready for the next addon before the actual one is even finished. People typing a sentance in 10 seconds requesting crash models and more types of choppers and so on without even thinking that those small things take a hell lot of time to be done. Those guys (and gal) are working day and night for free just to give you something to play with and that's not meant literally. All they ask for is a little respect and polite treatment and everyone can read in this thread what they get instead. Being respectfull and polite to anyone should be normal and nothing someone has to ask for. All this doesn't only apply to BAS but all the other MOD teams and individuals who are spending their time to make OFP more enjoyable for everyone. Maybe BAS only gets this treatment because they show themselves, answer questions and try to explain even when they were asked the same stuff over and over again.

The trick to make the chopper land and stay down is to give him a stop order (commandStop/doStop) before making it land. When the chopper has landed, it's no problem to give it a doMove/commandMove order and it takes off again and flys to the given location. Normally the chopper switches off the engine after landing but you can prevent this by issuing a _Chopper action ["Engine on"] command. The chopper then still stays down but keeps the engine running.

Of course we continue on developing our tool Actually the release of Visitor didn't change much. We only skip our first alpha release since all those things can now be done with Visitor too and there is no urgent need for it anymore. There might not be so many updates in the next time since we are currently planing the features and structure of the final tool (until now it was more or less testing of what's possible). But maybe we can keep you happy with some screenshots of the test of our more advanced features

@MadDogX: You can change the grid settings in the map config. I don't think that those grid settings have anything to do but with the AI using the grid names for navigation. When you don't change the grid settings in your map config then the grid names repeat themself and give the AI problems. But you shouldn't get problems because of this in Visitor or when loading the map in the game.

Your first problem can be solved by changing the settings for bulldozer to 512x512. You can do this in: Tools->System Preferences -> Real Time Viewer -> Standard dimensions of world in viewer. (Don't forget to change this again before you load a different sized map) Your second problem seems related to missing textures. Sometimes you place a combination of basic textures on your map where not all secondary textures (automatically placed by Visitor) exist. In bulldozer such missing textures are shown as white. When you load your map in the game and press "show textures" in the editor the missing secondary texture isn't found and the game crashes. If you don't let the textures display in the editor then the game doesn't crash but the missing transition texture is also shown as white ingame then. You can regenerate all the secondary textures with an option in the Texture Manager: Tools -> Texture Manager -> Regenerate secondary textures. One problem I came across when trying to edit bigger sized maps is that the maximum zoom level on bigger maps is less than on 256x256 maps so you have quite some problems with placing and editing objects on a 1024x1024 map.

You could use the CoC network services: http://www.thechainofcommand.net/cgi-bin....17;t=25 When the network services are started then you'll have an array with the server and all payers in it. This array then exists on every client and the server. So for your sidechat problem you wouldn't have to rely on the named playerslots, you would have the actual players right at your hand for your sidechat. In MP scripting the network services make things much more easy.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (reedkiller @ 11 May 2003,16:33)</td></tr><tr><td id="QUOTE">Aye! A tech demo of sorts would be nice<span id='postcolor'> There is allready a techdemo for bigger maps from a_lone_Wolf called wrpdouble and wrpquad. The plan was to release the 3 in 1 map as some kind of playable techdemo (wrpdouble and wrpquad had quite some lag) but it's simly not ready yet. Be patience

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (N.o.R.S.u @ 11 May 2003,16:02)</td></tr><tr><td id="QUOTE">Hmm how about releasing this "test map" to public ;).<span id='postcolor'> Like I mentioned in the earlier posts there are still some issues with the textures. The 3 seperate islands had too many textures to put them into one big map. Right now only Everon has it's original textures and Malden + Kolgujev are only covered with a basic green grass texture (no beach, no airfield,...). So there is still some work to do until you even can think of a release. I also need to ask BIS for permission since I only put their original islands together in one map.

I'm working on a program to create bigger maps than the normal sized ones you can do with WRPEdit. Placing objects is still a thing on the todo list since it will need a GUI for this, but importing terrain and objects from normal wrp files is allready possible (but far from any public release) So the 3 in 1 map is just a test map where I imported the terrain and the objects from the original islands and combied them into one big map with lots of water between them. There is still the issue with the textures and some problems with forest on steep hills but I use it as a testmap for plane addons where it's nice to have a bit more space

The scripting approach still woldn't work for multiplayer. After all bigger maps (up to 16 times: 50kmË›) are quite possible in OFP. I once made a map with Everon, Malden and Kolgujev and there weren't any problems with lag. The only problem I encoutered was the 512 texture limit per map. The original maps all used over 250 textures so I had to make compromises there. From what I've read, OFP2 won't have much limitations concerning map size

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Harnu @ 11 May 2003,05:16)</td></tr><tr><td id="QUOTE">You can't make then land without scripting with some setVelocity/flyinheight/Setpos.<span id='postcolor'> Even with scripting you'll have a really hard time. I once tried to script a landing but I couldn't get the AI to put the gear down. So unless you have a plane with a custom animation for lowering the gear you are out of luck. </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (edc @ 11 May 2003,06:05)</td></tr><tr><td id="QUOTE">I wonder if you could change the airport in the config for it or whatever it uses.<span id='postcolor'> What you can do is to make another seperate config and put it into a pbo where you set the ILS settings for the AI to use the other airfield, but you will have to get the right coordinates for takoff, landing and taxiing. You can change the location where the AI lands with a new config, but you are still limited to 1 airfield.

keyboard + mouse for infantry joystick + throttle + pedals for planes and choppers programmed buttons on the throttle + mouse for tank commander

Changing the physics of planes and choppers would be nice. I understand that OFP will never be a flightsim and that the handling of planes and choppers should be possible for everyone. But it wouldn't hurt if planes and choppers don't behave that different from their real counterparts. Like beeing able to steer the chopper while ascending and not just beeing able to slow the chopper down with turning or flying up to the moon. For planes it wouldn't hurt if turning doesn't slow the plane down too much and if you don't have to pull the stick all the time just to keep the plane airborne. Those things don't make the handling harder for beginners but will help ppl alot that are used to flightsims. A good solution in my eyes would be to make much more of the variables editable for addons that control how vehicles behave.

It's not the MP mission scripting I'm concerned about it's the scripts that are included in addons for advanced features. In addon scripting you can't use triggers and such editor depending things, you only can use the scripting language. There are many advanced features possible in the game that work perfect in SP but are in the easiest case a real pain to get them working properly in MP and in some cases simply impossible to do. The whole addon install issue is made even worse when the mission designer has to place gamelogics or fill in some scripting code in the init field of some units just to make the advanced features work. So simplifying the MP scripting should also be part of the enhancements for addon handling, not just easy installing. Allmost every higher quality addon that's been released in the past had some sort of advanced scripted features and the tendency to include more scripted features is still growing. Nothing is won when the addons install really easy and the mission designer has quite a hard time to get the addon to work in the mission just because of the way scripts in addons have to be done for multiplayer.

Simplify MP scripting. It shouldn't depend where you use commands if they are working or not. The need for some commands to be executed where an object is local is making MP scripting verry complicated, especially with the actual system how and where actions and eventhandlers can be used.

This is my setup I used for createUnit a gamelogic: I have a vehicle that runs a script with its init eventhandler (the script is allways run on the server no matter if the vehicle is local to a player or not). The script createUnit a normal SoldierWB into the group of the vehicle, then joins this soldier to grpNull and createUnit a gamelogic into the new group of the SoldierWB. If the vehicle is local to a player the game hangs completely, if the vehicle is not local to the player it's fine. So the only way to createUnit a gamelogic is to place a gamelogic on the map at design time and then use its group wich is bad for use in a standalone addon.

There is another serious problem when using createUnit to create a gamelogic. If you create the GL with a group that isn't local to the server the whole game hangs (no ALT_TAB or anything else, only power off worked). It works fine when the group passed to createUnit is local to the server. The problem is that the only way to make sure you have a group that is local to the server the mission designer has to place a gamelogic. If you are using createVehicle in the scripts of an addon then you really want to avoid to force the mission designer to place additional things to make your addon work. Every extra effort an addon requires to be used makes it more unlikely that ppl will use it.

Scorpio, right now I'm working on a dev kit for addonmakers to easily include cargo capabilities to their addons. With this cargo system all sorts of different cargo can be transported by all the vehicles using the system (if their cargo capacities allows). Also the cargo capabilities can easily be adjusted for all sorts of vehicles. The cargo setup used in the BAS MH-47 is only a small perview of the whole system since the release date was pressing and the cargo system is still under development. Just contact me if you're interested to include such a system in the CH53.

Somehow the plane action ["LAND GEAR"]; only raises the gear when it's allready down but I can't get it to make the gear go down. Any ideas?

One problem of texturing for OFP is also the fact that OFP is using DXT1 textures with only 16bit colors and a compression that makes the textures look verry different in Max than in OFP depending on what colors you use and how. I think many ppl would make the textures by themself if the difference wouldn't be so big of what they create in Photoshop or Paintshop Pro to what they see ingame then. Also not everyone is an craphics artist. I think it's actually easier to learn how to make low poly models than to learn how to paint a good texture for the model.

One thing I noticed are that the textures of the periscopes are too bright. They make the tank clearly visible even at night. In RL I bet the glasses are especially made so that they don't reflect light so much. Beside this it's a really nice model!

Yes it would. JPEG dithers also this way but the pattern is different. Using JPEGs for textures is not a good thing I think because they have to be converted by the game while running. The paa/pac textures are in a format that the graphics card can read directly so no further processing is needed for them. I finished the small tool I mentioned some posts above and I have some good results so far. The usage of the tool is quite simple: Save your color pallette as an .act file in Photoshop then open and convert it with the tool. Save the file and use the converted pallette to save your texture as gif again. You can tune the dithering options in Photoshop if you like to get better results. No support given for the tool and if it screws up your computer it's not my fault, etc. If you still want to try it, then you can get it here Â

The number of colors isn't important at all. Because even if you reduce the colors in your texture to a single one texView dithers the color while converting and you end up with lots of dots that have different colors instead of one single color. When you choose a color in RGB space you can adjust the three color channels (red, green, blue) from 0 to 255. That means that each channel is stored in 8 bit. The whole colors is stored in 3x8=24 bits. But the colors in a pac texture are stored in a different way. The DXT1 format stores the whole color only in 16 bits. The color format of DXT1 is RGB 5:6:5, that means the red and the blue channel are stored in 5 bits and the green channel in 6 bits. So you have only 32 different color values for the red and the blue channel and for the green channel only 64 different color values for the green channel instead of 256 for each of those channels. The conclusion of this whole tech talk is that a pac texture can only have some special colors, all others are dithered. All colors which red and blue channel color value can be devided by 8 and it which green channel color value can be divided by 4 are shown undistored as a single color. For example the RGB color 56;64;40 is shown as undistored as a single color where as the RGB color 52;64;38 is distored and shown with different colors because the red and blue channel value can't be devided by 8. Unfortunately I don't know a way to set Photoshop up so that you only can have the RGB 5:6:5 format colors so I will write a little program to convert at least the colors of a color pallette saved with Photoshop. This way you can save a texture as gif then save the pallette with photoshop, convert the colors and save your original image again with dithering to the converted pallette. I think I can get much better results than with the current methods of converting textures. Sorry for all the tech talk

Increasing the dpi doesn't help since you simply change the resolution of your texture. The paa and pac format of OFP is nothing else than different DirectX formats for textures. By changing the header of the files you can make a DXT1 .dds file show up in texView as a pac file. The DXT1 format is only 16 bit color so the colors of a 32 bit tga image have to be dithered with a special procedure. For further reading of the file format and the color dithering read here: http://msdn.microsoft.com/library....ats.asp and especially here: http://msdn.microsoft.com/library....res.asp The more different colors you use in the alpha channel the less colors you have for your image. So it's best to use only black and white in the alpha channel so that you have the full 16 bit colors for your image. This is the theory. So the ugly looking textures come from the way texView (via DirectX) is doing the color reduction. Since you can't do anything about the way the convertion is done it has to do with how you paint them and what colors you use. Unfortunately I experience the same problems than you. So I'm also still on the search for the best way to paint textures so that they look good after converting them to paa/pac. Perhaps someone who knows how to paint textures for DXT1 format could share some knowledge how to paint them? BIS, anyone?

May I ask how you solved it?