Battlezone Universe

my units don't have collision detection. they crash into one another and try to go through each other, and succeed after a minute or so. when i see it, i have to direct them to go around the unit point for point or they'll just continue melding through. some get stuck!
this all started with the Beta patches.

I saw something similar.

In instant action, I had two scavs roaming around. I called one over and it didn't come. I went to investigate and found them inside each other.

It looked almost like one scav, standing still. They were pointed the same direction in the same position. Only slight edge variations gave away that it was two scavs. I rammed them and pushed them forward. This caused them to roll forward at slightly different angles and eventually drift apart and become two scavs again.

So there is some kind of collision problem, but when they do collide, they stick and it hinders them from doing anything else.

That's weird. I thought that we worked on that merging issue.......

We did, but as hard as GSH tried, he couldn't get the treaded physics to work consistently. :oops:

Isn't it possible to "imitate" the 1.2  logic  or the code is copmletely different in 1.3? I see BZ boxes system looks the same. Any parameters or constants than can be experimented upon? 

Some points about treaded unit collision...

Battlezone units were intentionally made a little ghostly to allow their limited AI to eventually push through buildings they were stuck in/on/against.  When BZ2 introduced treaded units the physics of the treads didn't work well with shoving through a building, causing them to get permanently stuck.  Nathan worked long and hard on several ways to stop this, but it's always better to avoid the collision entirely than try to make the collision harmless.

To do that:

Remember that most units use a bubble for colliding.  Give the unit a shield and shoot it to see this bubble.  If any part of the unit sticks out of the bubble you'll have trouble when colliding with buildings.  If that's the case either give the unit a larger "collisionRadius" entry OR try "boxCollide=1".  People have reported mixed results with boxcollide, but I found it helped long, skinny treaded units collide when they actually bumped each other rather than after they'd already merged.  They may still merge as there are other factors involved in collisions.

Someone reported that collisions also depend on unit speed, so slow speed collisions are more likely to cause merging.

The AI insists on doing some things that help cause collisions, such as backing up and turning before finally moving forward.  Red Devil had some success limiting this, maybe he'll chime in on how he did it...  (personally I think treaded units should spin in place, and almost never back up, but that's just me...)

Don't go too nuts with "collisionRadius", as above a certain size will cause the unit to path funny.  For instance, too large a value will prevent them from being able to use bridges, or make them go all the way around a cliff, or not be able to approach the Service Bay, that sort of thing.  Use a radius just large enough to prevent them from ramming each other casually.

When making treaded units try to keep it real...  too large or too small has problems without serious physics tweaking.  Read the 1.3 changelog for all the new treaded unit physics options...  some of them really help but require a lot of work to tweak properly for custom units.

-Av-
(bored out of his mind at work...)

I experimented heavily with collisionRadius while testing 1.3 and got very good results.  Vehicles would all go to the Goto point and then spread out nicely.  That really helped with units in groups all being able to fire instead of just a few.

I also got the treaded units to rotate in place for turning purposes so they wouldn't do that 3-point turn and get stuck in things.

Which files should we manipulate for testing the collision thing, Red Devil?

The vehicle files, like ivatank.odf, fvatank.odf, etc.  They're in the .pak files.  Newer ones are in patch13.pak, older ones in data.pak. Use PakExplorer to extract them, a text editor to edit them.  Stick 'em in your addon folder to override the ones in the pak files.

You mean, each tracked vehicle needs fixing? O.K. What is your suggestion for the parametet value, what gave you better results?

Thanks

It's not just one value.  It's many values all working together.  I put many dozens of hours into it about year or more ago and I don't know what I've done with it. Best way is to just dive in and work it out.

I am not very familiar with the .odf structure and parms. Is there any handy documentation so I read it myself and not be of nuisance to you?
Right now browsing inside ODFs I could spot only a section called [trackedVehicle] that, I suspect, is related to the matter we are dealing.  My eye did not catch a "collisionradius" line but I will see more carefully.

You're not a nuisance and I'm not sure there's any documentation for it.  You'll probably have to add the collisionRadius entry to the ODF, like this:

collisionRadius = 8.0

To make things easier, you can fire up an Instant Action map, then Alt-Tab, tweak the ODF's, save them, then Alt-Tab back to the game, then build the unit(s) again to see the effect (might have to demolish/rebuild the factory so it will pull in the changes).

Do such changes work with every thing, except just units? Perhaps weapon effects and renderings?

 Yes, they should if i remember correctly.

Thanks Red Devil. I have already changed some things in ivtank, ibscav, ivrckt. I didn't try a collision factor  as high as 8.0 so the effects are minimal. I noticed a file named COLLISION.CFG in 1.3 root with a lot of parameters for interacting forces. Is it a system level control of the collision or it is not related to AI units behaviour?
My biggest problem remain the scavs that bump-and-carry other AIs half map, sometimes close to the enemy lines. I do not see any attempt to DETECT if any unit is in the path and they ride in a straight line to the other unit. Is there anything about the detection and/or awareness of close AI units?

I check ed out Collision.cfg a few years agao and then GSH said it's not referenced by the BZ2 code.

You'll need to  try the larger values to see the effect it (cR) has.  It's most notable when units go to a Dropoff point or directed to go to a spot on the map or Nav Beacon.  they'll all go to the spot, then spread out nicely, jostling a little bit to keep their "personal space" intact.

Since each unit differs in size, you need to compensate for that, plus it only works well if everything else has a cR.  Also, keep in mind that they have to navigate bridges and tunnels, in between buildings, etc.

Here's some old pics with the cR set to 20.0:

(http://imageigloo.com/images/4577AssTankCR20.jpg)

(http://imageigloo.com/images/5851Turrets-cR20.jpg)

(http://imageigloo.com/images/9463Warriors-cR20.jpg)

Quote from: llulla on September 06, 2006, 01:48:51 PM
Thanks Red Devil. I have already changed some things in ivtank, ibscav, ivrckt. I didn't try a collision factor  as high as 8.0 so the effects are minimal. I noticed a file named COLLISION.CFG in 1.3 root with a lot of parameters for interacting forces. Is it a system level control of the collision or it is not related to AI units behaviour?
My biggest problem remain the scavs that bump-and-carry other AIs half map, sometimes close to the enemy lines. I do not see any attempt to DETECT if any unit is in the path and they ride in a straight line to the other unit. Is there anything about the detection and/or awareness of close AI units?

Way to go RD! I didn't even think of cR=20 :-o. Your screenshots show perfectly the effect it has on deployment at navpoitns. Does the cR take care also of the movement? I mean when stopped units are in the path of the moving one, will the latter find a better path and avoid colliding? Maybe some other entries in ODFs deal with this thing.

Wow that looks useful :-)

 Yes, it helps some.  The biggest benefits are giving the units a clear field of fire and when the reduction of collisions when leaving a spot to go attack something.  They do wind up going single file following the first unit in the group list though, but then spread out after arriving.

Could you use a smaller value but have the same effect? Say 10~15? they do seem a bit spread, sometimes you need them to stay close, so a comprimise might be useul, though it seems useful for sending rats around a pool properly, you wouldn't have to select them and move them one by one

 Yes, that value was used just so you could easily see the effect (and that it does have an effect).  Having it too large will prevent units from using the Service Bay/Dower, but you can expand the field of those easily or use trucks.

If you increase the cR of the Constructor a little, he doesn't get hung up on stuff in the base.

Man this sounds so useful, perhaps a tweak in the settings for a later 1.3 release (if there will be any)?

These are ODF tweaks. You can make a recycler variant with them, which is the whole point of the recycler variants. As far as I remember, RD never submitted any of his tweaks for inclusion in 1.3.

-- GSH

 I was going to, met resistance, then finally realized that "You can't please everyone, so you got to please yourself".  And like GSH said, with variants, you can do anything.  I may post a variant down the road just for laughs.  Let's see....

All kinds of infantry:
Pilots that use hoverpacks after ejecting and snipe you and take your ride.
Riflemen
Grenadiers
AT missilemen
Rocketeers
Saboteurs (expensive littlle guys invisible to AI that sneak into your base and blow it up with C4).

Increased cR on all vehicles.

Thumper

All lights on all vehicles

1.2 physics (sans hover)

Gnat/Valkyrie

Better AI with better weapons.

Assault/Combat Blink

But then I thought, Natty's coming out with an advanced 1.3 G66.  Let 'em suffer.  :-D

RD, you shouldn't refrain yourself because of thinking what the others are thinkig of your work ( I hope that is not the case  :-D).  In the community there is thirst for everything new so pack your work in some kind of miniMOD and let the people decide what they like.
SFmod is small and not properly supported because of objective problems and yet, A LOT of BZoners, including myself, play using that mod continuously. 
IF you have enough time and tweaking is still fun for you man, lock, load and shoot whatever you have.

As a member of the "resistance" let me state that we had no problem with RD releasing his stuff separately from the patch. We felt that too many ppl were calling 1.3 a mod already and if his more extreme mods were released with the patch, it would only cement 1.3's reputation as a mod.

He also had a few "problems" with his stuff. One of these was with his AI that I pointed out (ex:  Misl scouts, when told to attack a extractor, would drop mines as well as launch TAG effectively reducing the ammo to about half). I believe he has since fixed that problem but by time he did, most ppl had pretty much stopped testing his stuff due to other concerns and problems. I've told RD several times that I would love to play his final Recy variant and hope he will release one after thorough testing.

 As stated before....

I never intended all the stuff I posted to be released with 1.3.  I just wanted feedback on multiple items is all.  Unfortunately, the testers weren't capable of parallel thinking and so I said, "*** it", ditched it, , and moved on to other, more interesting, pursuits.  And like I said before, Natty is coming out with G66 1.3, which is even bettter than anything I could dream up.

Don't sell yourself (or your stuff) short RD. Get yourself some good testers and get to work. ;)

Uhm..*Puts up a hand* Il be glad to help if I can RD :-)

I believe BOJ Man said  "Reality Sucks" when worked on SF mod. I interpret that, that every small modification of the stock BZ, whatever 1.2 or 1.3 it is, makes a break from reality. At this point is a matter of personal taste. The same as the unlimited preferences for food and clothes  is what ppl like on BZ mods.  There will always be  someone that likes something different.
My thanks go to everyone who tries and offers to the community his/her vision of a different BZ universe.

Quote from: llulla on September 07, 2006, 12:18:22 PM
Does the cR take care also of the movement? I mean when stopped units are in the path of the moving one, will the latter find a better path and avoid colliding? Maybe some other entries in ODFs deal with this thing.

First off I'm pretty sure I'm to blame for units going straight to their destination, ramming other units in their way.  I mentioned once that I thought it would be better if units weren't so darned polite and just ignored other units in their path.  This was back when units overbuilt at the Factory would crash the game as they tried to path their way out of the herd.  Remember that?  It was a serious issue at one time.

Anyway, it shouldn't be that big of a deal.  If Scavs start shoving your units around you're not talking care of your boys...  :)  tell them to go somewhere and 'hold' and they'll try to move back there if shoved too far away.

There is a setting for this, but it's for the game and not each individual unit, and I think it's just a list of what units worry about colliding with things.  I think Nathan has the Constructor in there, but am not sure...

-Av-

Thanks for clearing this point Avatar.

I believe that, the change you were mentioning, the one that affects all the system, IS NEEDED. Scavs being the worse one, ALL tracked vehicles suffer the same problem.  The change shouldn't be anything drastic but a slight improvement.
Is it really possible to modify the general behavior without changing one by one the units?

What about the tracked vehicles that get stuck :-(, moving back and forth, on vertical or inclined walls and are not able to get back on level ground. Is there anything that fixes that?

 Yes, you can make tracked vehicles spin in place instead of trying to do 3-point turns.

Quote from: Red Devil on September 19, 2006, 07:49:45 PM
Yes, you can make tracked vehicles spin in place instead of trying to do 3-point turns.

....to everyone's annoyance.....

 I was going to submit it for 1.3, but changed my mind and was going to put it in my variant.

When's the last time you saw a bulldozer make a 3 point turn?  Never.

When was the last time you saw a tank hover? Never.

 The point is that they're using tracked vehcile physics.  That being the case, they need to behave like they are using tracked vehicle physics, not like someone driving a wheeled vehicle.

Nooo, the point is...it's not real...it's just a game. Leave the quirks be!

The point is: the quirks WERE NOT in the game so why adding more quirks when the intention is to solve the existing. Whatever was wrong with the physics of 1.2 was much better than the actual where a small Service Truck displaces an Attila easily.

Dig up a copy with 1.0 on it and you'll find Scavs that do 3 point turns. This is what RD and myself are talking about.

I happen to agree with you about the ST being able to move an Attila though.

BZ2 is a ½ million lines of code that more or less resembles a very large patch work quilt with small parts related to physics sewn in the upper left corner, lower right corner, OH, there's some in the middle and some more over there in the middle left on the very edge, and ove....

Anyway, I hope you get the point that the code for BZ2's various sections weren't all nice and neat in one place. It's simply impossible for 1 guy to find it all.

 The Atilla/ST push is very easy to fix.  Just add a mass setting to the Atilla and it won't budge.

I guess some people prefer to have their treaded units get stuck in cliffs and buildings.  [shrugs]

Three point turn was there forever but did not cause the flying of the bumped unit in a very weird fashion. Three point turn is relevant when many units are too close in limited space. It  does not affect riding THROUGH other, distant units, in an open space OR, explains what a is Bulldog  doing back and forth on a vertical wall. These things WERE NOT present in 1.0 or 1.2  so the piece of code governing the tracked vehicles was somehow reasonable.
I agree, working on zillion lines of existing code is walking on a minefield ( see how Windoze gets from bad to worse). The work done on BZ is really unimaginable for me personally. 
I argue from a point of simple logic (that maybe very wrong) that "if it works leave it be" and wonder if it is possible to reinsert the old code at the piece BZ canvas that is now covered with the patch for Tracked Vehicles. Since this is coming from someone that does not know at all the work done for 1.3, it may sound stupid  :-D but better talk about things than avoid.
Do you agree?

 Just because it's PB3 does not mean that all the fixes are in the code.  The devs graciously pulled a lot of functionality out of the code and converted it into ODF options which *are not* in the ODF's themselves.  That's up to the modders to place them there.

Have you tried the new ODF options?

I do not know where to read about it RD, I would like to.
I tried CR=15 for Scavs, RTs and Assaults but it is not improving much the situation of riding through other units. I will play some more and get a better feeling of it.

Look in the ChangeLog*.txt files in the root folder of your BZ2 PB3 install.

Quote from: llulla on September 21, 2006, 03:26:28 PM
It  does not affect riding THROUGH other, distant units, in an open space OR, explains what a is Bulldog  doing back and forth on a vertical wall. These things WERE NOT present in 1.0 or 1.2  so the piece of code governing the tracked vehicles was somehow reasonable.

???

One the most MAJOR complaints about 1.0 and 1.2 is that treaded units become permanently entombed inside buildings.  Tracked units are virtually useless in 1.0, and personally I think 1.2 made it even worse when it comes to tracked units and Gun Towers.  I can't tell you how many Scavs I've lost to being sucked into a GT...

There are problems related to each 'fix' of another problem.  It's like a house of cards.  Toss in personal preferences being so different and there's no way to please everyone.

For instance,
I don't mind if a unit can eventually push through a building IF it's the only fix to them being stuck inside that building forever. 
I don't mind if a unit shoves another one out of the way IF that's the fix to stuttering the game because all of my units are trying to path around each other. 
I don't mind if two units merge when going through a narrow spot IF it stops them from jamming up there and locking everything into a huge traffic jam.

See?  It's a case of picking your poison...

-Av-

AFAIK, GSH tried many times to make the tracked vehicles work right, but to no avail. :|  The tendency to get stuck seems to be a little less than earlier in 1.3.

Correction: He gave us the tools to not make them get stuck.  Use them.

If the effects were only and precisely as you line them Avatar, I would agree too. The problem goes beyond that and, I believe, can not be limited simply as a matter of preferences.
I bet, no one agrees with the billiards-like behavior the tracked units have right now. Why the bumped units should spin strangely and hit the adjacent unit which also starts the same dance, creating a complete disarray of what you have planed? 
A bumped unit takes, sometimes, MINUTES to stabilize and get back to its position (IF ever); don't think is a preference. In the mean time that sector is open to enemy units. I have lost the Recycler several times because Assults and RTs were set off to travel in circles from Missile Scouts passing through :oops:.
And, if a vertical surface is nearby, be sure, the units will stay up there long enough to serve as target practice for any passing incoming units. Little hard to be somebody's preference.

These things go beyond your simplistic explanation because affect the game  too much. RDs constructive line is what must prevail in this topic : explain to and help everyone to make the possible correctins  to the problems he or she is suffering most.

Again with the ???

I didn't offer a simplistic explanation, I just pointed out that much of the merging/getting stuck behaviour you say wasn't in 1.0 and 1.2 was INDEED present in 1.0 and 1.2, and was in fact worse than 1.3 under some conditions.  Buildlings such as GT's, that have an inner room, were like quicksand to tracked units in 1.2.  As RD says, 1.3 is better in that regard, and for mods can be tweaked even more to keep units out of trouble.

The issues with Treaded Units behaviour when struck, such as the strange spin you mention, seems to be related to the reverse feedback the treads give to the body of the unit when the tread lifts.  A bump lifts the body, which lifts the tread, which lifts the body, causing a small feedback loop.  While it's been brought up on the 1.3 private board I'm not sure if GSH is done with the patch for good, so it may not be 'officially' fixed.

There are also apparently issues with the small increase in traction I gave treaded units.  It's been reported that it causes warping when treaded units are piloted by humans in MP.  It may also be the real culprit behind the tread lift issue, but as far as I know nobody's had time to really check into it.

Either way, with some research and experimentation, the values GSH gave us in 1.3 can be used by the Community to come up with a fix for the remaining physics issues.  He unlocked so many values for us that the problem is narrowing things down to exactly what needs to be changed AND making sure other problems don't come from the changes.

OTOH don't mention a 'Community Physics Patch' to RD, he had a bad experience before when he started such a thing.

-Av-

don't forget to make sure that your buildings have proper ODF settings to ensure that tracked vehicles don't get stuck.

A guntower is technically a vehicle to the AI and pathing engines, so set a fairly large collisionRadius (remember it's in meters) and use Shift+F9 view to see if it's large enough. And certain buildings will benefit from having 'tunnels' defined for them, where AI is allowed to pass through and where it is not.

This guide might help a bit.
http://www.bzuniverse.com/~zeroangel/reference/tunnel.php

Please note that I am severely procrastinating on developing the site further, so don't expect anything new unless I announce it.

Avatar, please read carefully what I wrote. I have never been for a " community patch" or similar. I hope the forums will have more user to user help. For that see the topic "wug AIPs".
I like the way RD and now Zero Angel try to advise EACH player about his problem or question according to THEIR personal experience. It would be great to see, like in some other occasions, pieces of ODF that have solved this or that problem or, an actual explanation what a param or  section of the file affects.
I am against non-specific advises or mesages type: I like it this way and you can go to hell... (I am exaggerating a bit about your first post :-D).

Look in the modlog?

I take it English is not your primary language?  Seems like there's some language barrier here...  for instance:

Quote from: llulla on October 17, 2006, 01:09:36 PM
Avatar, please read carefully what I wrote. I have never been for a " community patch" or similar.

I never said you were.  I listed it as one of the options the Community has for changing unit behaviour.  Many people haven't read the changelog, or the modlog, and don't know what's possible. 

I believe the problem is:

Quote from: llulla on October 17, 2006, 01:09:36 PM
I hope the forums will have more user to user help. For that see the topic "wug AIPs".   I am against non-specific advises or mesages type: I like it this way and you can go to hell... (I am exaggerating a bit about your first post :-D).

Then take your messages to email once you find someone who will help you with your specific problem.  This is a public forum for a reason, and the audience reading these messages are a diverse group many of whom find their own answers in "non-specific advises".

In Other Words I am NOT against non-specific advice or messages, often they provide answers to others than the original poster.

And you're exaggerating my first post a LOT.  You seem to have taken it personally when it wasn't intended that way.

I'll try to be clearer about that first post:  I said that what you see as a problem is/was not seen that way by everyone.  In fact, much of what you posted as a problem was intentionally put into the game by the developers to solve certain other problems.  The 1.3 patch opened up odf entries to allow us to change things on our own for just that reason.

I didn't say I liked it "that way", I just tried to point out that one man's fix is another man's problem.

Read the modlog, the changelog, search the forums, and don't rag on those of us who take the time to help newbies.  Also don't expect simple, direct answers to your questions.  You won't get them.  You'll get suggestions, "non-specific advise", and pointers to the source of the answers.  That's how the forums work regardless of what we're for or against...

-Av-
(who I think everyone will agree has helped more than his share of modders around here....)

llulla, Avatar has been in the BZ community since before rocks turned to dirt and has been modding and helping everyone all that time and is also the creator/owner of the BZ Classic mod for BZ2 and all of us here really like him a lot.  He is a senior member of the 1.3 patch test team and was very instrumental (and still is) in improving BZ2.  He has a *g-r-r-r-r-reat* sense of humor and is a great supporter of BZ1 and BZ2.

1.3 PB3 was released with hardly any modifications done to the ODF's due in part to complaints that previous patch releases were criticized as being mods because the ODF's were touched.  That being the case, any changes to be made with the expanded ODF entries is to be done by the modders, hence Avatar's and mine advice to look through the Changelogs and Modlog and experiment with things. 

To tell you the truth, there's so many new ODF entries that the devs added that I was overwhelmed with it all, so the advice holds for me too.  I'm still finding new stuff myself.

And watch out for Avatar's cane.  He'll whack you with it when you aren't looking.

[pictures Avatar in his wheelchair railing about 'those darn kids']  "Whippasnappa!"

:lol:

Haha. I agree and laughed.

RD forgot to mention that Av was also part of the FE Dev team.

I'm not much younger than Av and he even smacked me with that infernal cane of his. :|

Quote from: llulla on September 22, 2006, 01:53:49 PM
I do not know where to read about it RD, I would like to.
I tried CR=15 for Scavs, RTs and Assaults but it is not improving much the situation of riding through other units. I will play some more and get a better feeling of it.

Just saw this. OMG, CR=15? That's extremely high. And it cause a problem, because now units will avoid scavs to within 15 meters, which makes them big obstacles to the pathing engine. And if you have 4 scavs close together, AI units will take a big berth around them. Instead of simply dismissing and passing through them.

Harumph.  I'm not THAT old...well, maybe I am.  And that cane is nuclear powered so I don't always have full control of my whacking...  :)

And actually I think what he's saying is that units don't even try to not bump other units.  They'll drive right through them on their way to another spot. 

Collision Radius only applies to units that are trying NOT to collide, such as told to follow, or go to the same spot, or deploying when there, or figuring if they can fit through terrain or between buildings.  Units told to go somewhere just go, and will blast right through a crowd just sitting there in their path.

That was done on purpose to help with the pathing lockups around the Factory.

You'll never get BZ units to hold in any real pattern (other than turrets and even they have their moments).  The AI has a mind of it's own, and pathing is a major issue with most units as well as a load on the engines. 

IOW if you don't want that squad of hovercraft blasting through your carefully placed treaded units then use Navs to path the hovercraft around the treaded units.  Nothing much will make them carefully pick their way through the treaded units, as pathing just doesn't work that way.

-Av-

I printed all *log files and went through those carefully. Some years of programming background didn't help much :?.
It is not exactly a Reference Guide for someone who just decided to get in. It is, rightfully, meant for the people of the Inner Circle of BZ development/mod, already familiar with it. Hence, it is on the Inner Circle members to share bits of their knowledge when are asked for.
Being an engineer, my formation and work "forces" me to GIVE and REQUIRE detailed instructions.  If this is too much in this context, I excuse myself.

Back to the real topic. I am stating the clearly visible fact: right now, THE PLAYABILITY of 1.3 has deteriorated compared to 1.2, NOT that 1.2 is better than 1.3. I am not in the position to say that being simply a player.
Thanks again to RDs post, now I know that is all in the ODFs, and these, are so new and so full of unknown parameters that it will take some time to come to some acceptable balance.
Personally, I like to fiddle with the configs and shape the things for me, but, it will be like wandering in the woods, not having a few initial hints as key points.   

Just talking about issues (e.g. this, "sleepy" units) isn't as useful as actually providing cases (e.g. savegames) that quickly and easily reproduce it.

-- GSH

Just going to rattle off some stuff real quick here.

Increasing the cR just makes it easier for grouped units to have a clear filed of fire and gives units more room to navigate through them is all.  Easier to walk through a thin forest than dense brush and all that. That large cR=15 was just to show that it works.

Yeah, 1.3 physics need work.  All the code fixes and tweaks changed them. Spawn is supposed to be making a physics patch for it.

I'll be very happy to try to answer any of your questions.  Searching for keywords in the CL and ML will help answer a lot of them (so you don't have to wait for a reply from us).  Also, if you have questions about the interface and modding, Timevirus (TV) at http://www.timedisruptor.com/forum/portal.php  is very helpful.

Also, Fishbone and Liazard and most others at http://www.bz2md.com/smf/portal.php are very helpful.

Just saw that GSH had posted about providing savegames (made in Instant Action/Singleplayer) while I was posting this.  That's really the best way for him to track down most  bugs.

I am reading those files and, when the explanation is clear, I try something. Some other time the explanation refers to something I should know from previous work ( but I don't  :x).
What initially caught my eye was [TrackedWehicles] section. I changed the parameters in a certain range, but did not notice any  effect worth to speak for.  What is the role of this section?
Another VERY disturbing thing I would like to fix is the movement of  Constructor/Builder. It is NOT ABLE TO CLIMB the slightest slope anymore (in Chill I built  Haulers to send my cons to the Scavs). What parameters may affects the climbing ability of the Cons?

G.SH. I will try to catch the occurrence of the innactive behaviour and send a savegame. I think classic maps like Canyons, Chill, Iceberg will do.

There is no section by the name of [TrackedWehicles] but there is a [TrackedVehicles], unless I missed something.
Yes, the con is mildly retarded.

Try increasing the Construction Rig's:

accelThrust = 20.0

to something like this:

accelThrust = 32.0


Try these values for the Assault Tank:

COLLISION_RAISE = 0.5
SUSPENSION_MIN = -0.1
SUSPENSION_MAX = 0.5
SPRING_FACTOR = 3.0
DAMPING_FACTOR = 1.5   // critical damped
TREAD_STATIC_FRICTION = 2.5

Quote from: llulla on October 24, 2006, 01:55:44 PM
I am reading those files and, when the explanation is clear, I try something. Some other time the explanation refers to something I should know from previous work ( but I don't  :x).
What initially caught my eye was [TrackedWehicles] section. I changed the parameters in a certain range, but did not notice any  effect worth to speak for.  What is the role of this section?
Another VERY disturbing thing I would like to fix is the movement of  Constructor/Builder. It is NOT ABLE TO CLIMB the slightest slope anymore (in Chill I built  Haulers to send my cons to the Scavs). What parameters may affects the climbing ability of the Cons?

G.SH. I will try to catch the occurrence of the innactive behaviour and send a savegame. I think classic maps like Canyons, Chill, Iceberg will do.

Don't tell me the damn cRig is on skates again.... :-o

I wonder what caused it this time?

Yes! It is skating. You see it in Chill when the Constructor tries to go up some inclined paths. Skating in the literal sense of the word.

If you can make a repeatable save from just before it starts, send it to GSH and it should get taken care of.

The Cons has gone from 'climbing a stairway to heaven' to unable to get over even the smallest of bumps.  The darn thing just keeps messing with us...

The main thing is that 1.3 is probably 99.99% done as far as code changes.  Nathan's hoping he can keep the 'final' touches and fixes to a minimum so I doubt we'll see any big changes to physics.   It should now be possible to safely make a list of odf entries that will help put physics back to 'fun' playability. 

GSH DOES need examples of anything that can hose MP, especially any joiner bugs.  For various reasons the beta team is weak on MP testing...   Other issues, like those below, should be sorted out by the community.

The 'ramming through other units' was done on purpose and should stay.  Removing it could mean the game going back to locking up when units try to path their way out of crowds.

Some of the whirling, twirling, strangeness of treaded units, especially when colliding, is due to the body roll and lift feeding back to the treads.  We should be able to odf that out of there and I plan to experiment with it myself this weekend using the Phaer Ran units from Fleshstorm.  The Punisher especially suffers from it, although it's handy when they become entombed on Gun Towers and you have to ram them out.

Treaded units colliding with buildings can be addressed by various means.  RD mentioned the Colllsion Radius entry, but there's a lot that can be done with collision objects and other odf entries like boxCollide and steerFactor.  I've suggested several times that "boxCollide =1" be the default for tracked vehicles...    Vertical walls and sharp, right angle joints in collision boxes are very bad, as are interior rooms in buildings with thin walls.   I've already tweaked the ISDF Pgen collision box and would like to do a bit more of that as time permits.

Personally I liked the stage in the beta when buildings actively pushed tracked units away, and I'm sorry to see that gone.  It really helped those stubborn Scavs that insisted on ramming a GT...

-Av-

I will test the changes RD suggests for the Constructor on some IA maps and let's see. In the mean time, I will try to get as many e savegames as possible indicating typical flaws. I play only IA, so I don't know if this will be of any use.

I agree on bumping through if, what follows, is a displacement rather proportional to the supposed weight of the units (of course, without the infamous twirling). Example, if a Service bumps an Attila, the latter shouldn't move at all . I hope that the ODF tweaking will correct what, as Avatar explains, will be the default for the 1.3 physics.

Jammers act as a black hole :-o. Everything tracked, from Services or Titans are sucked in for a long time :lol:.

Something that *really* helps with the bumping/moving is adding the mass setting to ODF's. 

Using it, I was able to make Service Trucks immovable even when hit with an Assault Tank.  Adding it to all tracked units and Walkers would make them behave realistically and not so, um, flouncy bouncy.  Kinda hard to make it bounce when you can't bump it off the ground.  :wink:

Physics tweaks are a big gray area, which you're welcome to work on. However, things like the "sleepy units" that were complained about in so many threads, that ought to be easier to get a savegame on.

-- GSH

Can someone please elaborate on the sleepy units?  Not sure I've seen that.

See http://www.bzuniverse.com/forum/index.php/topic,6310.0.html for one set of complaints.

-- GSH

Thanks, I'll look into it later this afternoon.

(Pictures Red Devil setting up shop, pouring hot java for sleepy Sabre pilots and whipping up scrambled eggs loaded with tobasco...)

:-D

I would love to see the units all given the appropriate mass setting.  How much does an Attilla weigh, anyway?  :)  To see Scion Scouts just bouncing off one as it wades through Scion defenses to take out their Matriarch...  sweet.

Jammers are an EXCELLENT example of a BAD building.  Heckfire, at the beginning they weren't even true buildings and you could drop a GS right on top of one.  (loved that, though...)  All those angles, hjgh center, no collision object, tracked vehicles slip right under it...

Think of a ball shoving its way under another ball, one that's set a bit higher than the first.  That's what's happening, squeezes it right inside.  And to make matters worse parts of the treaded units often 'stick out' of the sphere used for their collisions.  This is one of those buildings that would benefit a lot from a decent collision object, or altered CR.  It might actually even be great to have it spawn a vehicle-only-shoving MCurtain as a lung...  but we're straying into mod territory there...

boxCollide = 1 helps a lot for normal collisions with treaded units, especially those that are longer than they are wide, but it would be nice to have a little more help for them in low-speed bumps...

-Av-

I miss the jammers in GS's too.

"Javajavajavajava..."  :lol:

I'm trying to find out which ODF controls what. Only for ConstructionRig there are  like 10: iconsb, icontt, iconsw.... (maybe not exactly like this).  The same for other units: ivtank, ivtank12, ivtank_lw  :?.  Inside each there are no remarks to explain the difference. Please help!

They are used for the missions, some can't build certain things, some can and so on.
Ever noticed that some ships have different hardpoints in the missions? Well thats what those ODFs are for, they hav different weapons and maybe other speed/handling related stuff.
The first mission where you can command a rec (on pluto) has a different build menu, you can only build scavs, turrets and pods? Again, thats what it's for (Might have missed one out, I can't remember.)

Oh and there are also rec varients to think of :-P

llula, I am sure the main difference between the different construction rigs is what they can build.  Basically what shows up on their build menus.

The following section within the construction rig's odf may be the main difference.

Quote[ConstructionRigClass]
buildItem1 = "ibpgen"
buildItem2 = "ibfact"
buildItem3 = "ibcbun"
buildItem4 = "ibarmo"
buildItem5 = "ibsbay"
buildItem7 = "ibtrain"
buildItem8 = "ibtcen"
buildItem9 = "ibbomb"
[BuildGroup6]
buildlabel = "Defenses"
buildItem1 = "ibgtow"
buildItem2 ="ibbstow"
soundBuild = "ivrecye3.wav"
soundFinish = "ivrecye5.wav"

Avatar, I never noticed boxCollide=0 actually helping.  The scavs in fleshstorm still seemed to get caught on one another, even with this setting.

Na ah! That exact segment is in > 1 ODF for ConstructionRig. I am looking for ODFs that govern units ONLY in IA games.

Playing Canyons I came accross another instance of sleepy units but couldn't catch it :-(. Two Sabres staying with the nose in the Extratctor while a Warrior melted it with the Arc. The moment Extractor was gone the Sabres took the Warrior out instantly.  :lol:Funny thing to see and a pitty I couldn't save it.

Quote from: llulla on October 26, 2006, 03:13:39 PMPlaying Canyons I came accross another instance of sleepy units but couldn't catch it :-(. Two Sabres staying with the nose in the Extratctor while a Warrior melted it with the Arc. The moment Extractor was gone the Sabres took the Warrior out instantly.  :lol:Funny thing to see and a pitty I couldn't save it.

Were they told to defend a scav or extractor?

Quote from: Commando on October 26, 2006, 12:31:13 PM
Avatar, I never noticed boxCollide=0 actually helping.  The scavs in fleshstorm still seemed to get caught on one another, even with this setting.

Before adding it to the Phaer Ran Scavs they 'merged' when bumping into a deployed GT.  The front part of the nose would entomb with no resistance at all, and then the suction would begin. 

Adding it made them bump the second the nose hit, rather than later when the collision bubble hit.  They still merge at times but the 'bump' occurs at the nose, rather than part way down the body. 

Slow speed merging still occurs, as does merging if they're anywhere near the build point while one is being built.  (You have to wait for a bit for them to clear the build point as they first turn and head into the building for some reason.  The Phaer Ran Factory is even worse, Walkers will turn right around and try to force their way into the building before heading for the dropoff point.)

Merging with buildings such as deployed GT's occurs if they're stubbornly trying to ram through them, but once entombed if they're jostled just right they'll shoot up to the top of the GT collision and fall off.

Like I said, it doesn't fix everything but it helps the collision occur at the right spot, especially on treaded units that aren't squared off, like the Phaer Ran (longer than wide).

I wish debug.collision showed everything that collides, including vehicles.  I'd like to see it show the collision as red/blue boxes and bubbles, without hiding the geometry.  I think that would illustrate better what's going on, as I see a lot of the collision troubles as bubbles meeting bubbles.  IMO even making the bubbles into flat topped cylinders would be better, if more drag on the engine...

-Av-

Yes the tanks were told to guard the Extractor.

This  "boxCollide"  line goes to any specific place inside the ODF or doesn't matter.

BTW Avatar, I think you said something about upgraded Phaer Ran GTs  at Fleshstorm forum. I am circling around but not finding a way to do it.

boxCollide = 1 goes under [GameObjectClass].

Ah, you've never played BZ1.  Use the Armory to drop weapon powerups on the GT's once they're deployed.  This is a BZ1 trick that doesn't work for stock BZ2 GT's.

The reason this works in Fleshstorm is that the GT's don't have a collision__hc object.  BZ2 doesn't specifically stop you from dropping new weapons on a GT, but with the stock GT's the weapon pod will hit the collision object and never actually touch the GT.

I think the reason it's this way is originally BZ2 used the mesh itself for collisions, but this is a very heavy load on the engine.  Collision objects were added to help with the load, and using a collisionRadius (bubble) is even less of a load.

For stock BZ2 there really aren't any better weapons to drop on a GT than what they come with, but for the Phaer Ran I've found the fireballs in the Incinerator" choice in the Armory (6-3) to be the best heavy hitting GT weapon.  They're a little slow but they take down the big enemies very nicely.  The stock pulse rockets do a good job on the Scuttles, so against the Swarm you might want a mix...

-Av-

I have BZ1 from day0 and continued to keep it for a long time in parallel with BZ2. The fact that I have not been regular in the forums is related to other reasons.

I tried what you are saying since the first time I read the post at FS but it seems my "aiming"isn't good enough or I am doing something wrong.   The pods keep bouncing under the GT. Maybe more practice needed :-D.

Quote from: llulla on October 27, 2006, 02:35:50 PM
Yes the tanks were told to guard the Extractor.

I'm not sure why that would happen then.

I know that if you tell a unit (tank, scout) to follow another unit that deploys into a building (such as a Scav), the unit told to follow no longer has anything to follow when that other unit deploys and it's attention will drift off to Never Never Land.

Quote from: llulla on October 27, 2006, 03:40:03 PM
I have BZ1 from day0 and continued to keep it for a long time in parallel with BZ2. The fact that I have not been regular in the forums is related to other reasons.

Sorry, it just seemed like you didn't realize you could drop weapon powerups on buildings.  In my experience that usually means the person hasn't played BZ1.

QuoteI tried what you are saying since the first time I read the post at FS but it seems my "aiming"isn't good enough or I am doing something wrong.   The pods keep bouncing under the GT. Maybe more practice needed :-D.

If that happens it's the wrong type of weapon.  The Phaer Ran armory is orgainized by what unit they go in.  It's only my own experimenting that found that the "Incinerator" weapons were cannon class and would drop into a GT.  Rockets, mortors, & guns will do what you mention, just drop through the unit and bounce on the ground beneath them.

Ah, sweet PYRO BLAST...  :)

-Av-

Quote
I know that if you tell a unit (tank, scout) to follow another unit that deploys into a building (such as a Scav), the unit told to follow no longer has anything to follow when that other unit deploys and it's attention will drift off to Never Never Land.

Might be an easy thing to test w/ the editor.

-- GSH

I got the same thing when I did a quick test using a custom aip.  Scout went dead once its scav deployed allowing me to kill the scav and the defender without the defender ever firing a shot.

Good savegame, Commando. Scout was stuck in 'wait' mode, and wouldn't drop out of that to attack threats.

-- GSH

You're right Avatar. I was using cannons from Exterminator menu :-D hoping to get the Railgun imn assault mode. Just following the logic of EDF combat-assault weapons. It seems Phaer Ran have an own type of cannon for GT and Inciniretor. It worked finally, thanks.

I could find a good, easy to understand, description of the parameters of modlog from General Black Dragon. It was in the archived forum of pb1.3. Now, if someone can help with a generic list of the *.odf files, mainly those that control the units, it would be great. It may be ISDF files only :lol:.

How do I send the savegames, directly to GSHs email?

There's an ODFPACK around here somewhere also, with all of the ODF's in it, but the better solution is to get PAKEXPLORER and unpack the 1.3 patch into a folder for study.

Once you've saved the game using the FILE menu, go to the Battlezone II directory and look in the SAVED folder.  There'll be a small file named whatever you saved the game as.  As I'm not sure if he's tossed his email out to everyone I won't list it now... there've been too many 'bots' crawling around the forums lately...

Hmmm, thinking about that maybe he or someone can make a savegame email address to send them to, one that can be tossed out when no longer needed...

-Av-

Unpack the Data.pak archive too.

A good way to get used to testing ODF tweaks is to tweak one setting in the ISDF default scout and add a DM map to your shortcut.  Fire up the shortcut and you'll load the map automagically and be in the scout.  Alt-X and you'll be back to the desktop.

Put the tweaked vehicle in a separate folder under addon so you can just move the tweak out so you can play online too.

Regarding Spawn's physics patch (Or whatever you want to call it.) I finished making the ODF's into a Rec Variant about a month ago and sent it along to him. I used all the values from 1.2, mass, a head-bobbing mauler; everything. All that's left is the actual physics tweaking and I've left that up to him since he knows 1.2 better than I do.

I have PakExplorer installed and I had already all the ODFs extracted in a separate dir. I simply get lost in the myriad of similar names like ivtank...,ivtank12...,ivtank_w..., etc. It was worse when looking for the Constructor files. for now I want to work only on ISDF units and mainly on those that disrupt more my way of playing. I prefer to build "lighter" bases and use heavy pieces similarly to automated defenses. In 1.3 this has become a nightmare  :-( . Can you tell me which are the ODFs for ISDF Constructor, Service Truck and Scav used in the IA?

Ivrecy is the basic IA recycler

Look at the end of the file to see that it builds ibrecy

ibrecy builds ivcons and ivserv, etc.

ivcons builds ibfact and ibarmo, etc.

ibfact builds ivtank, etc.

ibarmo builds the crates (apstab, etc.)

Basically, any unit that has something tagged on the end (like ivrecyst) means it is special purpose.

Thanks a lot RD.
Your suggestions are clear and detailed as usual.   
I will start testing as soon as I finish my attempts to produce a MicroXP :-D.

You're very welcome.

Make sure you make separate folders for the data.pak and the patch13.pak and bumps.pak and the xsi's all under a main folder and just search the main folder.  That way, the new files won't overlay the old files and you can tell where each one comes from when you search.

Also, when searching you can use wild cards:

?vtank*.odf  will find all tanks of all races.

?brecy*.odf will find recyclers from all races.

?p*.odf with 'powerup' in the text box below will find all powerups.  (using the wild-carded file string speeds up the search).

And like that.

I have extracted only what's in patch13.pak. I did not know that data.pak ODFs must be changed also. What is precisely in either of them?

data.pak contains all of the odfs that came off of the bz2 cd.  patch13.pak contains alll of the odfs that came with 1.3.  If you see the same odf in both pak files, for example ivtank.odf, the odf in patch13.pak is used because patch13.pak overrides data.pak.  A lot of objects weren't updated in 1.3 so you may need to open up data.pak to find a lot of unit odfs.