Macser

That's the first time I've ever seen that. Even after all these years the engine can still surprise us, with "features". :D I was leaning towards a display issue. But you mentioned two different systems. Is there anything at all that's unusual about the model? Something that you may have put in that's not usually in that class? I mean besides the fact it's a horse drawn carriage. :) Long shot again. But I'll throw it in anyway. How about memory points? Have you got any loose vertices? Or vertices at a large distance from the model centre?

Hello Faguss, I think the method I'm using at the moment seems to work well. I set the speed value of any of my custom anims to a max of 3.5. Then I tailor the animation to suit my needs. If I need to slow it down I can then do that from the config.

A small video showing a "race" between a default character and a custom one. Despite the default character getting a large head start, the custom one catches up and even overtakes it. There are no scripts running on the custom unit. Just in case it's not obvious from the video here's a size comparison. The main reason you never see any large sci-fi/fantasy oriented characters, is because of the instant death effect. Creating the model is easy enough. But once you get it in game it will fall flat on it's face, dead after a few steps. You can increase the armour value and even use a health check script, but usually to no avail. It seems there's a relationship between a couple of aspects. I don't know the technical reasons. Only what I've observed. They would seem to make some sense. The rtm definitions in the config have two settings called duty and speed. These obviously affect the outcome. Duty is how tired the character becomes as a result of the animation being played. And speed is the playback speed of the file. A faster playback might be multiplied by the duty to get a result. The higher the speed the faster the accumulated "fatigue" builds up. A large character might appear to move slower, relative to their size. So if you increase the playback to compensate you're likely hastening the "fatigue" effect of the animation. Thus killing them. I can't prove that of course. But I did observe that a speed value over 3.5 on my own character always resulted in death. Regardless of duty, or distance travelled. So I zero out duty,(If it's a sci-fi project it's not that unusual), and keep the playback speed under 3.5 for all animations. From there I achieve the results I want with the actual animation itself. The speed value can still be used to fine tune the results of course.

True. Although the bleeding isn't really a concern for me. I don't really notice it when engaged in a scrap with one. Or I'd be too concerned with getting shot myself to spend time watching it. Switching off blood is an efficient way of dealing with it though. :) The things I'd really like to see sorted would be the pushing around, and the blaster bolts. As you'll have noticed the rounds are always parallel to the ground. The scripting for that is a bit more complex I think.

It's possible you've found another limit. Which is a pain in the neck, as it looks great. Are you using any scripting?

Yeah. You're right. I forgot about that little detail, sorry. Has the proxy got anything wrong with it? I mean are there any textures accidentally mapped. Or was the shape inadvertandtly changed? Also. Could it be an alpha sorting issue of some kind? With the stagecoach texture. If there's any alpha sections, like windows, try taking them out for the moment. It's a long shot, I know. :)

I figure you've already thought of this and done it, but I'll say it anyway. Have you removed the driver's proxy from the cargo view? I don't know of any Cfg setttings that cover this particular situation. That's a strange one.

Hey spad. Thanks mate. And yes. The Warhound uses the same class set up. :) @Noob1 I know all about the limitations of the tank and man class. http://forums.bistudio.com/showthread.php?191415-Proof-of-concept-Large-non-standard-characters But despite that, I still prefer the man class for this particular unit. The bleeding I can't deal with in a local config. The pushing by other man class units, or getting stopped on objects may be possible to work around though.I just need something solid, script wise. :) If someone else wants to have a go at making it a tank class, they're more than welcome.

Thanks my friend. Much appreciated. But don't sell yourself short. You've created a huge amount of quality work over the years, in comparison to me. :)

Fair enough. Although everyone I know personally uses 1.99. Well. I suppose that's a compliment in a way. It's definitely my own work though. And it wasn't very difficult to construct. The painting took longer than the build. The mlod is in the pbo. So it would be very easy to compare meshes if someone was interested. :) As far as I know, this is the At-At from Battlefront II: I assume that's the one he/she meant. I don't bother with ports. It's more of a challenge to take it from a simple plane or cube to a complete mesh. And I find it more enjoyable too.

Hello Sapper. I didn't think there were too many people using 1.96 these days. But besides that, I may end up using some of the new commands. I'll make a decision at a later date. If I do I'll see about trying to make a 1.96 version. For now, it's a quick fix on the user's side. :) Model, texture and animations are made by myself in Blender. A lot of the actual painting was also done in Blender. The layer system has made it a viable way of working directly on the mesh. I'm curious. Does it look like someone else's work? :)

:) Thanks for trying it out folks. I do have a simple normal map ready. And I'll be finishing the specular map soon. So I might release it for A2 at some point. Of course, if someone gets there first, that would be fine too. Thanks for the thought anyway. :) Prof I know exactly what that is. Looks like I spoke too soon about bug testing. Thank you. It's simply a piece that missed being weighted before export. That's a throwback to experiments with SetPosAsl. I reverted to SetPos at some point. I just never changed the requirement field. Hey Lenyoga. That's probably the experimental healing script working on it. I needed it to balance the durability against making units actually fire at it. Without the script units chew through the armour. But raising the armour level means they stop firing. It's not invincible though. It should be possible to take one down with concentrated fire. Or by ramming it with an aircraft going full tilt. :D These days it'd be a very small section indeed. Links will be updated with new versions, on the first post.

ambient[]={0.24313726,0.24313726,1,1}; diffuse[]={0.24313726,0.24313726,1,1}; forcedDiffuse[]={0,0,0,0}; emmisive[]={0,0,0,1}; specular[]={1.9967556e-008,1,1.9967556e-008,1}; specularPower=100; PixelShaderID="Super"; VertexShaderID="Super"; class Stage1 { texture="#(argb,8,8,3)color(0.5,0.5,1,1)"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage2 { texture="#(argb,8,8,3)color(0.5,0.5,0.5,0.5,DT)"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage3 { texture="#(argb,8,8,3)color(0,0,0,0,MC)"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage4 { texture="#(argb,8,8,3)color(1,1,1,1,AS)"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage5 { texture="test\spec_SMDI.paa"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage6 { texture="#(ai,64,64,1)fresnel(3,3)"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage7 { texture="CA\data\env_land_co.tga"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; That's the RvMat I cobbled together for that image. You would save that as "YourfileName.Rvmat" and reference it when applying it to the mesh. "Stage 5" is where the Specular map is referenced. You would have to change the path for your own texture. The diffuse texture can be applied inside O2PE/Object builder, in the usual way. The process hasn't changed since A2 as far as I'm aware.

You could use that pattern to create a simple specular map. Then set the specular colour green, from the rvmat. Obviously the choice of colours is up to you. :) I suggest playing around with the values in the material editor for the diffuse and specular. This would be in combination with the textures. It should give you a nice simple effect, as it picks up the light. Example buldozer render:

And thank you. You've done a hell of a lot of stuff in a short space of time. :)

I think he means an emissive material. An rvmat assigned to the mesh that makes up the blades, set to emissive. I don't think texture based emission has been added. Though I'm open to correction. :)

Mocap has been used since OFP. What people seem to be talking about are transition animations. An intermediate sequence between states. Instead of coming to a halt the character might slow up first. Then link into the stand state. Or play an animation to indicate actual turning. I'm sure there's already a facility to do that via config. I doubt it's something BI haven't considered. Perhaps it was too much extra work. Transitions would be needed between every state. Or it could have taken the responsiveness/immediacy out of movement.

Great work Spad. There's some really interesting stuff going on in that video. I'm looking forward to seeing where it leads. :) You could use the Llaumax files as a means to update your data3d and data pbos with the new textures/models required. I experimented with it a while back. All I did was change the textures for the sky colour. Then took out the updated PBOs and dropped them into the appropriate mod folder. You could probably just put the bat files into the target mod folder along with the source folders. Newdata and bin I believe. The only problem I could see would be how the bat files are written. They were originally made for OFP res. So the paths might need to be altered. There was some discussion about that elsewhere on the boards. So the end user would only need a copy of the Llaumax mod files on their machine. They can create a duplicate of the newdata folder with your textures inside and run the bat. This copies and updates the 2 resistance data pbos and creates a new dta directory locally, with sub folders. The pbos in there could then be transferred to the appropriate folder in the dune mod. Of course someone with the right DOS skills could do up a more specific bat file. I'm open to correction on any of that. :)

There was a script or set of scripts for a UKF land rover. Which gave the effect of independent suspension for each wheel. It may have been experimental, or it may have been released with the mod/addons. Were you thinking it could be applied to the "feet" of a walker type vehicle? Via script? The only problem I could see with that, is the lack of IK. Characters have a simple version. But vehicles don't have any that I'm aware of.

Sounds good (no pun intended). Except maybe the part about skating around in blood puddles. :) For the upgrade issue, I suppose it's best to go with the method you have the most control over. Which seems to be the main weapon with some scripting. I assume the "cold water effect" is a reference to being thrown in at the deep end? Starting off not knowing what's going on?

No doubt the tank class has it's advantages. I think it's down to personal preference. I don't personally mind the limits of the man class ,too much. Especially when you see it on the move. For me it wouldn't have the same impact with config based animations. I believe the simulations are hard-coded. I think some classes can be hybridised. Like weapons. But that doesn't seem to extend to vehicles. The script you mention sounds similar to the DKM tank suspension. That animates the land contact points. In that case there was one or two axis points as center pivot. I assume with a car it might need some extra points for each wheel. Was that from the UKF team by any chance?

Great looking sculpt by the way. :)

@rewhymo I'm assuming you're using the incompatible version of CBA http://dev.withsix.com/projects/cba-a3/files Then click on CBA_A3_RC4.7z under CBA_A3_RC4. That's the one you need. Could it be related to that issue?

Hey Prof, Kenoxite. All suggestions are welcome, no matter how unorthodox. :) I'll give them all a try and see what happens. Although I hate using scripts excessively, a couple may well be necessary in this case. And the fact there should be fewer of the units in a mission is a plus.

:D Obviously like everything in OFP/CWA there's positives and negatives. The man class is ideal from a visual point of view, for the reasons you mention. They look the part. But it comes at the cost of flexiblility in weapons and environment interaction. The At-At has no head selection. In fact it now has no recognisable named selections as far as the engine is concerned. So the hard-coded procedural animations don't affect it. These are the non-keyframed animations that are played when a round hits a unit. Or when the unit looks around,up and down. I just tried 6 million tons to see what would happen. And noticed that explosions no longer affected it. I wrongly assumed that this was responsible for the lack of flinching though. The lack of any selections is the more sensible conclusion. I haven't done extensive testing to prove this. So it looks good stomping around.There's no flinching, or going airborne if a handgrenade,or tank shell hits it. It sounds decent too. That's the good stuff. Now for some balance. :) Cargo ability: You can't carry cargo. Although you could fake that to a degree with some clever scripting. Ie, spawned troops and vehicles. Class restriction with mass: Regardless of how much it weighs it's still bound by the unfathomable class restriction regarding mass. So as I said earlier, any other man class unit can push it around as if it weighed nothing. The only way I've managed to combat that is with a looping script that uses setpos'd geometry to keep other units at a distance. This aspect actually works fairly consistently. Multiplay might be an issue though. The mass problem also affects interaction with stationary objects and entities. This means that a moving (active) vehicle will be barged aside or kicked in the case of the at-at. Even a 60 ton tank. However. If the tank is inactive when contacted, it will halt the unit. This applies to anything. Even a small plant. If it has geometry and it's not active the unit will get caught on it. The ai will of course atttempt to navigate around it. But it doesn't always work. But that's something you would expect of a soldier. It doesn't know it weighs 6 million tons and the engine doesn't recognise that in a logical way. Perhaps the same script that keeps units away, could be used to predestroy certain items. Plants would be the major concern. Buildings are big enough that going around them would be logical anyway. One other thing. That scripted geometry still won't push a stationary object aside. It's simply there to keep man class units from making contact. Land contact: In OFP/CWA there is no provision for quadrapeds. So it doesn't matter how many points you put in, it only takes the position of two of them. On rolling terrain or steep inclines this becomes very clear. I don't know how that could be combatted. Although for me it's still not a deal breaker.Typically this means the back legs will be in mid-air when walking up a hill. The steeper the hill. The more obvious the effect. Geometry issue with dead units: I need to do a little more testing with this. But it seems the geometry becomes inactive after the unit dies. I didn't notice this before. This might be more of a problem to combat. No pilots, drivers or gunners: Obviously, it's a man. So no crew positions. Although you can see from the head because of the memory points. But it won't match up with weapon movement, as I set the dexterity so that the head(weapon) moves more slowly and smoothly. Personally this doesn't bother me much, as it's more fun running alongside or having to face-off against the machine. Now. That might sound all doom and gloom. But not to me. The video shows that the right setting and mission approach can make the unit work. Even with the limitations I prefer this method to config based animations on a tank. :)