Romolus

That screwed up face texture is highly suspicious at least I would say!

Fighting the engine for allmost 4 years makes you either give up or go creative

To help with the visibility at those speeds, the tracer particles could be made to slightly grow over time. But I don't know if that wouldn't affect it's flightpath.

@Uziyahu: Just look at the script and you'll see that no matter how much you claim those tracers to be accurate, they aren't. The script creates a particle that is given a certain velocity and has a certain weight. So as long as the velocity and the weight of the particle doesn't match the velocity and the weight of the original bullet, the tracer particle is off. Period. Wolfbane allready mentioned that the script makes the tracer particles slower than the bullet so that it can be seen better. It's simple physics that in this case the way the tracers are traveling doesn't match the flightpath of the bullet and therefor aren't much of use for aiming. @Wolfbane: The only solution I see, is to make the tracer particle act like the real bullet by giving it the same velocity and weight. That way both the bullet and the tracer get treated the same by OFP and therefor take the same flightpath. Another method is to track the actual bullet with a fast loop like glowing lights are done in the script. But that fast loop hogs the CPU quite a bit, especially when the script is used with a fast shooting gun. I didn't have a look at your modified version of the script yet, but in the initial one you are calling the nearestobject command for every bullet while the tracer script only fires every x round. The nearestobject command is quite a CPU hogging one, so this might cause problems especially when the tracer script is used on many units. I know that it's time-critical to catch the bullet before it gets out of reach of the nearestobject command and that the walk through your array can be too long to put the nearestobject command in there. What you can do to speed this up quite a bit is to put the tracer settings right into the fired EH with the wbe_tracerfx.sqs <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_unit addEventHandler ["fired",format [{[_this,%1] call WBE_TRACERFX_FIRE_EH},[_unitID,_tracers,_ricochet,_numrounds,_tracersize,_tracercolor,_tracerglow]] The first argument _unitID is the position of the unit in the WBE_TRACERFX_UNIT_ARRAY. You can get this id in the wbe_tracerfx.sqs by checking the size of the array before you add the unit, or if you want to get sure, then search the unit inside the array after you added it to get it's position (id). The id then gets also put into the fired EH and you can directly access the unit your want without having to walk through the array to find your unit. This makes the fired EH script much faster and allows you to call the nearestobject command only when the tracer really needs to be fired. Fell free to contact me if you have questions concerning the above.

Haha, verry good news OE! Glad you're back and that it worked out THAT well for you

The method I described can be used for pretty much everything where you want to have details in the texture that you don't want to have in the model (for poly count reasons) or you don't want to paint by hand into the texture.

I really don't want to add fuel to this, but I find it interesting how ppl are called stubborn just because they don't agree with someone else and trying hard to explain their point of view. Instead of explaining what she meant she threatened to quit. Now who's stubborn? No one ever said that there weren't some nifty methods to use Bump or Normal mapping to enhance textures to be used with OFP. @nephilim: No one ever said that you are lying, or that you have no clue what you're talking about. Some people (including me) just stated that the way you put your words implied something that's not possible with the OFP engine as far as we know and explained our point. So why don't you just explain in a few words what YOU exactly meant and all is settled? @others: Could we please keep on topic and don't just heat up this discussion by attacking other ppl? About using Normal maps for OFP: AfaIk there isn't any freeware tool that renders normal maps to textures, but I would be happy if someone prooves me wrong here The process is basically that you take a high poly model and generate a Normal map from it. (There are some freewaretools available from ATI and nVidia for this.) Then you take that normal map and use it in a 3D rendering program like 3ds max (other 3D programs work as well) to apply this Normal map to a low poly model and render a flat texture from it. The texture then displays the geometry from the high resolution model without having this geometry actually modeled on your low resolution model. With some extra effort you can also render some global illumination shadows into your texture to make it even look better.

If you look at the first post in this topic then you see that this is about whether the OFP engine can use Bump mapping and how it is done. Then some people just refused to accept that the OFP engine can't use this kind of stuff and that talking about OFP using Bump or Normal mapping isn't really appropriate if you use it to create textures, since you can do that for pretty much every game. So what does this thread have to do with what you mentioned?

Just to clear this up a bit: You probably all mean the same thing, but what DeadMeat tried to point out is that when you say Bump mapping or Normal mapping, you normally mean a technic that is used in the rendering process. Normally Bump mapping describes the method to use a greyscale (or rgb in case of Normal mapping) bitmap that is fed into the rendering process in combination with other textures and stuff (like a specular, or diffuse map, reflection map,...). The renderer then looks through all those maps to determin how the pixel he's currently rendering should look like. That's what DeadMeat is describing. OFP also includes a renderer that takes all kinds of things into account, like from where the light comes and what textures are mapped onto a face, but it doesn't use Bump mapping! Since OFP only uses a single texture for its rendering process, you have to put all the details you want into that texture. How you do that is up to you. One method is to take a graphics program and paint it all by hand. Another one is to use a seperate renderer that can use all sort of stuff like for example Bump mapping and to render your texture with it. So the point here is that OFP can't use Bump or Normal mapping. Whether you use Bump or Normal mapping to create your textures, doesn't have anything to do with OFP being able to use those technics. If you're a pretty good artist, then you can get the same results by painting your textures by hand. And in that case you also don't say that OFP can use handpainting, do you? What makes the Bump or Normal mapping so nice and hyped in Doom3 is that its renderer really does use this technic for the rendering process. So the models get dynamically shaded like if theres modeled geometry while it's just a Normal or Bump map. The only way to get this done for OFP is to use another renderer like DXDLL that adds those features while postprocessing the results that the OFP renderer spits out. But as Kegetys allready pointed out, this wouldn't be a practical thing to do. Also the difference between Bump mapping (greyscale map) and Normal mapping (rgb map) is that Bump mapping is only 2D and the greyscale value determins the ammount the surface gets bumped along its normal at a specific point, while Normal mapping is 3D. The rgb values in the Normal map define a normal vector that is used to calculate the lighting at a specific point instead of the normal vector of the face this point is on. Conclusion: OFP can't use Bump or Normal mapping. What you use to create your textures for OFP is up to you, but doesn't have much to do with OFP.

No it's not, I just didn't see the point your post provided for the topic of the thread. Thanx for clearing it up Can't we all just leave the rivalries between mod makers out of this thread and stick to factual arguments?

I somehow fail to see your point Totmacher. You are also mentioning poly count numbers without telling much about the rest of your test environment. On what island did you do those tests? What other addons did you have in the testmission? The meaning of the results of your tests are verry different when you test on desert island without any other addons or if you test on Nogova with 2 tank groups trying to navigat through some villages. Just the poly count doesn't really say much. And what does the poly count of some old BAS weapons have to do with the arguments mentioned in this thread? It's well known that SelectThis made the BAS Blackhawk models and that he took them with him to BIA. That's why they look so similar. Somehow I don't get rid of the feeling that a BAS signature is a red rag to you

Well you're definately not clear enough when you just state rough numbers without any relation to other things that influenced those numbers. Without these relations, such numbers are not much help for beginners, since they are only valid within their relation to the rest of what poses load on the complete system. Without knowing those relations you are better off with general advices. On an island with many objects, an addon might still be lagging when created after your numbers for example. Also the specs of the PC play a big role. You don't mention those anywhere, which makes your numbers allmost useless. Doing all the tests to get some valid average numbers is quite some work and I doubt that any addon maker ever did that. So all you are left with when creating an addon, is to try to estimate in what kind of environment your addon will be used in. Then look how other addons behave in that environment and check how they are done (face count, number and size of textures, scripts,...) to get a feeling of how much load your addon can pose on the system to work without creating lag. This is something you need to learn and get a feeling for it (if you don't want to do all those scientific tests I was mentioning). Modeling by numbers doesn't help much with it since you only know the numbers then and not how they were found. It's the knowledge how things work together in OFP that enables you to create better and lagless addons.

I think it's obvious that if you raise something like the poly count or the number or size of textures that it poses more work on the CPU and the GPU. The balance you need to look at is the balance between every object that is rendered on the screen at a certain time. If an object uses so many recources that it causes lag, then reducing the texture size while raising the poly count or the other way round doesn't help at all. What you should do instead is to try to keep the system load for an object as low as possible. This can be done by reducing the polys, reducing the size of textures or reducingt he number of textures. Especially reducing the number of textures helps since swapping textures is one of the slower things, even on todays graphics cards. Apart from such general advices it is really hard to give certain numbers that are safe since there are so many factors that need to be taken into account. So try to stay as low as you can with your poly count, texture size and number and balance it against the other things that pose a load on the CPU or GPU. PS The abbreviation of "polygon" is "poly" and for the plural "polys" is generally used.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_vehicleList = [] {if ( (vehicle _x != _x) and (not ((vehicle _x) in _vehicleList)) ) then {_vehicleList = _vehicleList + [vehicle _x]}} forEach units _group _vehicleCount = count _vehicleList

Well the finished scripts and config can be tweaked for that one too of course once they are finished (still takes a while). The cargo script coud also be tailored for all kinds of other vehicles that need to transport things. @smokebloke: I like the h2 sound best, since from further away you would only hear the deeper sounds from the rotors and not so much the screaming form the turbines and the air outlets at the front that you hear in the other sound files. I also searched for some videos to see how this thing is moving and I found those: http://www.cpf.navy.mil/rimpac2002/videos.html @AgentFox2: The boat config worked quite well compared to an APC (not really usable for water) or helicopter (allmost impossible to correct with scripting). Thanx to Extraction for the F1 link.

Thanx for the flowers Scrub I would like to do the whole scripting for the LCAC, just to keep the the various scripts consistent. But that doesn't mean that I'm not open for discussing the features, quite the opposite. I encourage everyone to state ideas about how things could be done. The more ideas, the better the chance that we find the best solution for a problem @AgentFox2: Any idea where to get those F1 racing boats? I looked around at the main download sites for addons but I couldn't find them.

What I would need is an editable model (3ds max file is fine too, doesn't need to be p3d) to place the cargo proxies for the scripts.

I don't know any other company that can meet WACOM with their professional series (formerly Art Pad now Intuos). I didn't see a Volito yet but to me it looks like another low end tablett like the Graphire. If I had to buy a new graphics tablet i would go for the Intuos 2 since that's the successor to the Art Pad line. But of course that quality has its price. The Intuos has more preassure levels for the tip and also recognizes the tilt of the pen. But for normal graphics work you really don't need that. So with a used Art Pad II you get professional quality but for a low price. You might even be able to catch an A4 one for a verry reasonable price. I really doubt that even the new budget tablets meets the quality of my 8 year old Art Pad II. The Graphire was introduced as a low end (budget) line in addition to the Art Pad series and afaIk it came with a different driver than the Art Pad. I never had any problems with the Art Pad II for more than 8 years now. It even worked with the DOS based game Warcraft II (good old DOS days). No driver problem at all with all the programs I'm using. Don't expect to use the tablet as a replacement for your mouse. Doubleclicking in a specific location is a real pain with a tablett since you tend to move the pen when pressing the buttons or the tip. Most things are faster done with a good mouse. It's just for art work like photoretouching, painting textures or basically everything where you need to move the mouse pointer to get a certain shape. That's where there's nothing better than a tablet. Using the tablet in addition to the mouse works like charm for me.

Search for a WACOM Art Pad II on ebay, you can grab them as cheap as 30$ there these days. WACOM is top quality and the Art Pad II is still sufficent for most graphics work unless you're really into digital drawing and painting. I'm using an A6 sized one for allmost 8 years now (was about 150$ new) and just got another one (30$ on ebay) for the girlfriend.

@Scrub: Just had a look at the pics you posted and I have to say that it's really a nice model. Allthough there are many details modeled that are better done with textures, like the grooving on the driver's cab and the fine surface details on the turbines behind it (both sides). You will need those additional polys on the rubber hood. It's important to optimize the model of the hovercraft and loose as many polys as possible since the vehicles that will be attached to the craft will allready add quite much to the polycount themself and probably make it lag if you model all those details. @Asmodeus: Don't hesitate. I made the offer and so that hovercraft will definately be able to transport vehicles once it's setup and textured. I just don't want to spend weeks on the scripting work and then it won't ever be released because of missing textures or LODs. I'm working on this cargo idea for allmost a year now since the release of the BAS MH47 cargo and I planed to put it into the desert vehicle pack that got scraped now, so it will definately work

If someone creates decent textures for it then I'm willing to make it transport vehicles and add some other scripting. @Scrub: What's the current poly count of model? Does it allready have a complete set of LODs? How about texture mapping?

Pitufo, read what I posted 6 posts above. Once again for everyone to take notes: The missions are crashing due to the fact that we first tested them with Sebastian Müllers original BTR-Ts. That way the BTRT_A got into the mission and OFP doesn't remove it itself when you delete the units again. So when we replaced the original BTR-Ts with our Tonal version the BTRT_A still stuck in there but no one noticed the error because we all still had the original BTR-Ts (BTRT_A) installed. So the solution is: - to just install Sebastian Müllers original BTR-Ts, - or open the mission pbos yourself and remove the BTRT_A from the addOns[], - or wait until we release a fixed version of the missions (whenever that will be). All this was allready posted by me in this thread only an hour after the issue was first mentioned by Dauragon back on page 3.

I allready posted it on the 3rd side of the thread: Sorry about that. I guess it got in there when we were using the original BTR-Ts to test the mission and stayed there when we switched to the Tonal ones. So you either need the original BRT-Ts from Sebastian Müller loaded too to run the mission or you just remove the BTRT_A from the addOns[] section of the mission.sqs. All you need to do to search in a thread is to hit CTRL-F and enter "BTRT_A". Even if you have to do that on all the 13 sides the thread has now it would have been faster than writing two new posts

Sorry about that. I guess it got in there when we were using the original BTR-Ts to test the mission and stayed there when we switched to the Tonal ones. So you either need the original BRT-Ts from Sebastian Müller loaded too to run the mission or you just remove the BTRT_A from the addOns[] section of the mission.sqs.

Well, I can't see a reason why you should only critic someones work if you can expect a fix I for my part would like to know what you like or don't like about the TSF and also what bugs we missed. No matter if they will be fixed or not