Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

FPSC Classic Product Chat / FPSC hidden tricks, tips and hints

Author
Message
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 15th Jun 2012 16:34 Edited at: 26th Jun 2012 23:09
This thread is to throw out some of the knowledge that not only applies to FPSC but is required for games design in general. Some things are not always obvious as you cant see them under the hood so to speak.
________________________________________________________

1. Collision and physics:
________________________________________________________

There is always a heap of advice about improving performance in FPSC from keeping entity's low poly to making dynamic entity's static and turning off physics etc, some have their own methods and preferred ways of reducing the weight on the engine.
One very important and necessary factor always seems to be overlooked......physics collision.
I only ever see two settings being used again and again, box or poly.
There are actually other collision settings which can be used to reduce the calculations required for physics in FPSC.
Unless you really need to get under that table to find something its always best to use box collision on static immobile objects, the player wont notice that the round table has a box around it, nor will they notice that the car they just jumped up on is using a reduced collision envelope.

There are five collision settings you can use.

For static objects the collision works as follows:
1 is Polygonal collision
2 is box collision
3 is reduced collision

For dynamic objects
3 is cylinder
4 is sphere
Any other value is defaulted to reduced

Always take the time to think about how you want the player to react with objects in your level, you really dont need poly collision on everything in your game and using reduced will often be enough for any complex static object.
When you have hundreds of objects in your level design and reduce the collision on these the engine has less to calculate in real time and your frame rate will benefit greatly.
If your entity is small/medium sized and dynamic turn off collision completely via via script.
________________________________________________________

2. How to make a character walk/run on large entity's
________________________________________________________

Three different methods to have npc's move freely on larger entity's

Its well known that npc's have issues with any surface larger than 100"x100" (one segment) they will either run on the spot or worse...bounce up and down or fall through the floor completely. I myself have had to face this many times, particularly with terrain and the only solution was to slice up larger meshes and create individual segments from the larger model.

Fpsc has lots of hidden gems which can be utilised to make things work, not perfectly but still usable, and this is a couple of them.

Here's the simplest and most effective method:
Replace the appear script with appearantigravity.fpi, this will turn off floor logic and will maintain character height in the level allowing the npc to move entirely freely, even allowing character to cross from entity to segment and vice versa.
This can be used with both dynamic and static entity.



Another way if you want the npc to use null space (stay within a boundary or prevent them walking off the entity)
Place your terrain or whatever entity you want to use in the editor, your entity should be dynamic, this wont work for static and your character will simply fall through it when it spawns. Next you want to go down a level and place some floor segments underneath the area you want your character to move around in on the entity above, this has an advantage that npc's will stick to this particular area due to null space.
Open your character .fpe and in :orientation change offy =0 to 100. This will raise the character one level in the editor. Place your character on the level of the floor segments. When you first place the character in editor you wont see it, its above the level your placing it on, however when you raise the level in editor you can see the character fine and will be able to edit and move it around as usual.



When you test the game your npc should have collision with the entity its standing on and should be able to move around freely over the area represented by the segments placed on the level below.



It should be noted that as the entity is dynamic it does not use poly collision so its best to use this in areas that dont have too large a height difference, its barely noticable in areas where the terrain or whatever your using rises and falls by around 10-25" and its really not noticable at all to player collision. It gets obvious when the height starts to exceed 30" so use it only in more level areas.
You may also find that characters do not attack and run at you as much if the player is on the same surface, they will for sure strafe etc but aren't as aggressive in pursuing you for some reason, this can be cured by having the player on different surfaces or segments around the terrain the npc's are on or it might be fixed by better scripting I haven't had the chance to go too deep with this one yet.

Here's the really weird part, the npc is using collision with the terrain not the segments below, if you place standard segments next to your terrain and place same on level under it, the character will walk off the terrain and fall through the segment floor down onto the level underneath where it begins to act normally, as if no offset existed....go figure.

Please don't try to use this with huge full map sized terrains that have mountains (make these separate entity's)you will not get it to work. It is perfect for smaller wasteland style areas.

I do think a better workaround to this in some situations is simply to place segments and then dynamic terrain entity with collision turned off directly on top of these but you will get parts of the segment floor poking through the terrain and I have noticed that the npc seems to use an average from the height of the terrain which simply looks better.
I discovered this when I had to have collision on road entity's which would be destroyed revealing a crater beneath so I didn't have that option, if you wanted to blow things up and still have characters move around on them before destroying (such as floors which reveal traps etc this is definitely the way to go and it may have other uses I havent thought of yet.



More coming soon

Awesome! Its one of those threads.
Poloflece
10
Years of Service
User Offline
Joined: 14th May 2010
Location: Australia
Posted: 15th Jun 2012 18:32
Wow thanks, I'd never thought of collision as a performance killer, I'll probably need to keep that in mind.


Quote: ""How to make a character walk/run on a dynamic entity"

"


, could this be the answer to my terrain woes?



Poloflece

Scene Commander
Support Manager
12
Years of Service
User Offline
Joined: 3rd May 2008
Location:
Posted: 15th Jun 2012 18:50
This is excellent advice Rolfy, and is something I'm sure many users will find extremely useful.

Thanks for sharing with everyone.
ncmako
8
Years of Service
User Offline
Joined: 19th Feb 2012
Location: Hendersonville,NC
Posted: 15th Jun 2012 20:33
Yes, thank you. I will certainly take note of these.
Beno09
9
Years of Service
User Offline
Joined: 3rd Jun 2011
Location: Bosnia and Herzegovina
Posted: 15th Jun 2012 21:14
Many thanks Rolfy for this and future advices.

-In trouble you know a hero;
-If you don't start, you won't finish;
-Without suffering, there is no learning.
Marc Steene
14
Years of Service
User Offline
Joined: 27th Mar 2006
Location: Bahrain
Posted: 16th Jun 2012 09:22
What is reduced collision? Is it polygon collision but using a simplified physics model?


Official LightStorm Engine BETA Tester
/?m=forum_view&t=190541&b=21
bond1
14
Years of Service
User Offline
Joined: 27th Oct 2005
Location:
Posted: 16th Jun 2012 11:06 Edited at: 16th Jun 2012 11:07
And to take it a step even further, for smaller dynamic objects, just turn off collision COMPLETELY through scripting to prevent further processsing.

You'd be surprised what you can get away with even for small to medium sized objects - most times the player won't even care/notice if you pass through certain objects if they don't contribute to the structure of a level.

SPECS: Intel Corei7 3770k, Nvidia GTX680, 16GB RAM, Win7 Pro
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 16th Jun 2012 11:08 Edited at: 16th Jun 2012 11:50
Quote: "What is reduced collision? Is it polygon collision but using a simplified physics model?"

Thats exactly what it is, it would be handy to have some control over this perhaps as a percentage and a means to view it (I cant say for sure what percentage is used by default), it depends on the complexity of the model shape. Its one of the handiest features to use in a first person game as you wont see the feet or body parts disappear into parts of the surface, so perfect collision for the player is not as important as it is with third person games.

Quote: "And to take it a step even further, for smaller dynamic objects, just turn off collision COMPLETELY through scripting to prevent further processsing."

Also could be applied to larger non reachable objects, only problem with it is dynamic to use script and cant use lightmapping, although with distant objects it would work simply by lowering or raising the texture brightness to make it fit.

Awesome! Its one of those threads.
seppgirty
FPSC Developer
11
Years of Service
User Offline
Joined: 3rd Jul 2009
Location: pittsburgh, pa.
Posted: 16th Jun 2012 15:52
bookmarking this thread now! keep the tips coming rolfy.

gamer, lover, filmmaker
DarthBasicVader
14
Years of Service
User Offline
Joined: 28th Nov 2005
Location: Cyberspace
Posted: 16th Jun 2012 21:56
Good tips Rolfy! A man with your experience it's ok in my FPSC learning book
Keep it up !!

Riccardo
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 17th Jun 2012 00:59
Added 2. How to make a character walk/run on a dynamic entity to first post

Awesome! Its one of those threads.
BlueFox
10
Years of Service
User Offline
Joined: 2nd Nov 2009
Location:
Posted: 17th Jun 2012 04:06
Quote: "There are five collision settings you can use:
0 = Box
1 = Poly
2 = Reduced
3 = Cylinder
4 = Sphere"


Some great tips rolfy. One question to ask. I understand box, poly, cylinder, and sphere collision modes. Could you explain the "reduced" and possibly give me an example of when it would be used.

- BlueFox
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 17th Jun 2012 04:27 Edited at: 17th Jun 2012 04:31
Thanks Bluefox,
This is a full poly collision model for a set of stairs.



This a reduced collision model for the same stairs at 20%.



I have no way of knowing what percentage FPSC uses to calculate the reduced collision model so cant say exactly what it would look like. But as you can see collision would still work fine in game with reduced poly collision. TBH it should be used on anything that doesn't need better collision (which in a first person shooter is just about everything that you cant get away with simply using box,sphere or cylinder, such as stairs) the only thing I can think of using full poly straight off is terrain and then only for area's with npc's where collision with the character mesh is visible to the player.

Awesome! Its one of those threads.
BlueFox
10
Years of Service
User Offline
Joined: 2nd Nov 2009
Location:
Posted: 17th Jun 2012 04:36
I was thinking about stairs or a staircase using reduced collision. Your explanation clears it up. Now when I make models and media in the future, I will keep this in the back of my mind so I will remember to assign proper collision to help with the performance.

I appreciate your time answering my question.

- BlueFox
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 17th Jun 2012 04:42
You are always welcome

Awesome! Its one of those threads.
Dar13
12
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 17th Jun 2012 06:25
Quote: "There are five collision settings you can use:
0 = Box
1 = Poly
2 = Reduced
3 = Cylinder
4 = Sphere"

Not really, according to this code(taken straight from Google Code):

Seems that reduced defaults to box and box defaults to polygon. Reduced collision meshes would've been cool, but probably a ton of work.

The Zombie Killer
9
Years of Service
User Offline
Joined: 27th Mar 2011
Location: Gold Coast, Australia
Posted: 17th Jun 2012 06:34
@rolfy
If you apply the polygon-perfect collision to the dynamic surface, the entities should work fine on it, with less collision bugs.

-TZK

rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 17th Jun 2012 06:51 Edited at: 17th Jun 2012 10:29
Quote: "Seems that reduced defaults to box and box defaults to polygon. Reduced collision meshes would've been cool, but probably a ton of work."

I just tested reduced on terrain (collisionmode = 2) and sure enough it retains much of the contours with some loss of detailed collision (in a couple of areas I sank into a hill,its a very large entity, but overall it had good collision) it certainly doesn't default to box (V1.19) Have also tested with poly collision and the contours are perfect.The reduction in collision is quite noticable with reduced on such a large entity so I can assure you it works even if its not supposed to. Maybe Scene Commander could throw more light on the actual goings on in the code. Box defaulting to poly wouldn't make any sense as that's an increase in calculation or am I misunderstanding you.

I am no coder but are you sure that the code snippet you show isn't part of some kind of boolean function for producing the reduced collision model? You would know better than me.

Quote: "If you apply the polygon-perfect collision to the dynamic surface, the entities should work fine on it, with less collision bugs."

Its my understanding that dynamic entities cant use poly collision...unfortunately.

Awesome! Its one of those threads.
The Zombie Killer
9
Years of Service
User Offline
Joined: 27th Mar 2011
Location: Gold Coast, Australia
Posted: 17th Jun 2012 07:16
@rolfy
Really? I tried it on some and it worked fine. I don't mean as in that setting, I mean by using the limb finder method.

-TZK

rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 17th Jun 2012 07:19 Edited at: 17th Jun 2012 07:27
Ahh you mean polygon hit detection, I dont think its the same thing as collision detection. TZK could you describe what you mean by using limb finder as I might be misunderstanding you, have you found a way to use this for collision with npc's or player with an entity?

Awesome! Its one of those threads.
The Zombie Killer
9
Years of Service
User Offline
Joined: 27th Mar 2011
Location: Gold Coast, Australia
Posted: 17th Jun 2012 07:25
@rolfy
Yeah, sorry, I got mixed up. Anyway, the hit detection seems to work better than the collision detection method.

-TZK

rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 17th Jun 2012 07:28 Edited at: 17th Jun 2012 07:30
Yeah thats one of the things I have looked pretty closely at myself.

Awesome! Its one of those threads.
The Zombie Killer
9
Years of Service
User Offline
Joined: 27th Mar 2011
Location: Gold Coast, Australia
Posted: 17th Jun 2012 07:42
@rolfy
Yeah, I've used it since it was implemented, it truly was a godsend for collision. And I almost forgot, I haven't thanked you for these tips yet, so:



-TZK

rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 17th Jun 2012 07:44
Your most welcome TZK

Awesome! Its one of those threads.
Disturbing 13
15
Years of Service
User Offline
Joined: 12th Apr 2005
Location: Murder Capital of the World
Posted: 17th Jun 2012 08:14
Is the community guide still being updated? If so this definitely needs to be in it!

Disturbing13
Dev Forum Store
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 17th Jun 2012 20:21 Edited at: 17th Jun 2012 21:14


Okay, I said you can use five different collision settings and it was said that this isn't the case, due to the code snippet above, its suggested reduced defaults to box collision, so I did some more intensive testing with this to be a little more sure of the facts.
I tested a simple terrain piece which seemed to me to have different collision with different settings when using poly and reduced, after further testing I found odd things, no matter what collision setting I used the player would follow most of the contours even setting to box still allowed the player to follow some parts of hilly terrain, though each setting seemed to have a different 'feel' to it. Collisionmode=4 sphere seemed to have a smoother feel than others but it might just be my imagination playing tricks on me.

I took one of the stock door frames and tested with box,poly and reduced (lets ignore sphere and cylinder for now). The poly setting allowed the player to pass freely through the frame, box prevented the player from passing through and so did reduced. But hold up before jumping to assumptions that reduced is defaulting to box collision, it could simply be that the reduced collision is too much for this particular model to allow access.

So I did further testing on a model of a set of stairs I made just for the occasion.

With poly collision the player could walk up these stairs no problem even having the usual 'bounce' associated with walking up stairs, with box setting the player was prevented from ascending the stairs as expected. The clincher for me is that using reduced did allow the player to walk up the stairs and it wasn't much different from using poly.
If reduced (collisionmode=2) was defaulting to box as suggested the collision would have been the same as the model with (collisionmode=0) but it acts much same as poly collision (collisionmode=1).

Only Lee can give a definitive answer to what reduced is actually doing, as far as I am concerned it does what it says it does, it does not default to poly (or you could walk through the frame) and it does not default to box (or you couldn't ascend the stairs).

Awesome! Its one of those threads.
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 18th Jun 2012 19:37 Edited at: 18th Jun 2012 21:08
As is always the way with these things you find a way to do something in FPSC then take a closer look and find a better, simpler way
The method I gave above for npc collision on entity's larger than one segment using offset is still viable as it may have its uses in certain situations. I have however discovered another way that I think works far better.
I will update the first post after a little more testing to see how far it can be taken and if it has any issues, meanwhile here's a taster of it being used.

This method works for both dynamic and static entity's so lightmapping can be used.

Please excuse the choppy video my capture software is behaving badly.



Awesome! Its one of those threads.
Marc Steene
14
Years of Service
User Offline
Joined: 27th Mar 2006
Location: Bahrain
Posted: 18th Jun 2012 20:54
Keep it up rolfy These tips are invaluable. Could this technique be used on your terrain (the outer grid)?


Official LightStorm Engine BETA Tester
/?m=forum_view&t=190541&b=21
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 18th Jun 2012 21:02
Quote: "Could this technique be used on your terrain (the outer grid)?"

Thanks Marc, actually I have no idea yet but considering that npc characters still refuse to follow terrain contours using this I am doubting its use for the outer terrain pieces of that particular terrain for the simple reason that they have such a height difference and the characters may walk through parts of it, I will keep plugging away at it and see what can be done

Awesome! Its one of those threads.
s4real
Valued Member
14
Years of Service
User Offline
Joined: 22nd Jul 2006
Location:
Posted: 18th Jun 2012 21:16
Nice work on the tips Rolfy keep up the good work.

Here my tip :- Press F1 in the map editor will show you all the short cut keys lol.

Best s4real


Pack ya games with vishnu packer its free. Vishnu game launcher is now released.
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 18th Jun 2012 21:21
Thanks S4, and your tip has been duly noted

Awesome! Its one of those threads.
Hockeykid
DBPro Tool Maker
12
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 18th Jun 2012 22:17 Edited at: 18th Jun 2012 22:19
Quote: "I am no coder but are you sure that the code snippet you show isn't part of some kind of boolean function for producing the reduced collision model? You would know better than me."


I just took a quick look.

For static objects the collision works as follows:
1 is Polygonal collision
2 is box collision
3 is reduced collision

For dynamic objects
3 is cylinder
4 is sphere
Any other value is defaulted to box

Sean

rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 18th Jun 2012 22:42 Edited at: 18th Jun 2012 22:52
I wouldn't want to argue with someone who knows how to understand the code, but having tested it thoroughly collisionmode=2 is not box if it were the stairs I tested above would not have allowed the player to walk up them in same way as poly does, setting the collision to 0 for the stairs certainly did have box collision but as you say
Quote: "Any other value is defaulted to box"

so this would explain the setting working.

I didn't test 3 with the object but will do so now that you mention it and see how it goes.
I didn't go by any of the remarks in the code snippet as these can be in error (happens sometimes) I am glad someone is at least looking a little closer at this and all that counts is that the engine does use reduced setting, now after what you say its a matter of actually finding out which.
Thanks Hockeykid.

Edit* Tested the stairs with colmode=3 and found collision to be similar to colmode=0 so its either a sphere setting or defaulting to box.

Awesome! Its one of those threads.
Hockeykid
DBPro Tool Maker
12
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 18th Jun 2012 22:46
Quote: "f it were the stairs I tested above would not have allowed the player to walk up them in same way as poly does"


If you provide a video of the stairs in action, I might be able to tell you what's going on.

Sean

rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 18th Jun 2012 22:53
I will go one better and post the test models

Awesome! Its one of those threads.
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 18th Jun 2012 23:02 Edited at: 19th Jun 2012 20:22
Here you go, it contains the door frames and stairs all entity meshes are exactly the same just with different names as I didnt want to confuse myself if forgot to delete bin and dbo after test, it means you can place them all at same time in the level for testing.
Thanks for taking the time to look at it

Awesome! Its one of those threads.
Hockeykid
DBPro Tool Maker
12
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 19th Jun 2012 05:40
Your FPEs have the wrong "collisionmode" values.

"stairsbox.fpe" should be "collisionmode = 2"
"stairsreduced.fpe" should be "collisionmode = 3"
"stairssphere.fpe" should be "collisionmode = 4"

If "collisionmode = 0" then it will default to box collision, which would explain why you thought box was working.


Sean

rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 19th Jun 2012 05:58 Edited at: 19th Jun 2012 06:07
This was the point Hockeykid if you test them with the collision settings I used you will notice that collisionmode = 2 does not use box collision.
Setting it to "0" uses box, this setting has always been the one I used for box when creating models for FPSC since using TGC entity maker from way back, which says the settings for collision are as I describe.
Simply try the entity's as I provided them and you will see yourself that "2" is definitely not box collision.

Quote: "If "collisionmode = 0" then it will default to box collision, which would explain why you thought box was working."

As I said above
Quote: "but having tested it thoroughly collisionmode=2 is not box if it were, the stairs I tested above would not have allowed the player to walk up them in same way as poly does, setting the collision to 0 for the stairs certainly did have box collision but as you say
Quote: "Any other value is defaulted to box"
so this would explain the setting working."


I think the code for this is confusing or maybe more likely the remarks are misleading, using it in a test game says different.

Awesome! Its one of those threads.
Hockeykid
DBPro Tool Maker
12
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 19th Jun 2012 08:53 Edited at: 19th Jun 2012 08:53
Quote: "If "collisionmode = 0" then it will default to box collision, which would explain why you thought box was working.
"


Sorry, I meant to say If "collisionmode = 0" then it will default to REDUCED collision, which would explain why you thought box was working.

Sean

Flatlander
FPSC Tool Maker
13
Years of Service
User Offline
Joined: 22nd Jan 2007
Location: The Flatlands
Posted: 19th Jun 2012 09:01 Edited at: 19th Jun 2012 09:05
The code is more complex than one might think. There are so many different variables that collision mode might change for one reason or another.

Let's just use the following remark as an example.


Quote: "rem reduced mesh and poly col modes remain full polygon shapes for the uuniversephy.dbo"


One would have to really look at the surrounding code to figure out what is going on here.

Then there's this code:



This is code, I believe, that ensures that leaves and branches of trees, shrubs and such do not cause collision.

Then you have this code:



Again, one has to look more closely at what is going on. I'm especially confused by the fact that tcolmode is reduced by 1 if the entity's collision mode is larger than 0 and less than 3. So this just makes it a little more confusing. In the FPE POLY is 1 but apparently it is 0 within the code. Perhaps to make it compatible with ODE? For BOX, in FPE it is 2 and in the code it ends up being 1. The above code is scattered in different parts of the collision code which is somewhat extensive.

I have no time to really check it out, so will leave it those who might have more time.

"A programmer is just a tool which converts caffeine into code . . . reminds me….. if I had one more brain cell, I could have a synapse! woo hoo, Sparky!

~I'm the Terry of the Flatlands.
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 19th Jun 2012 09:34 Edited at: 19th Jun 2012 20:29
Quote: "Sorry, I meant to say If "collisionmode = 0" then it will default to REDUCED collision, which would explain why you thought box was working."

LoL now I am even more confused than ever.


This does not fall into line with TGC entity maker settings which was originally a tool created by Lee when FPSC was first being developed.
The Entity Maker settings are:
0 = Box
1 = Poly
2 = Reduced
3 = Cylinder
4 = Sphere

If Lee created this tool for making media to be used in FPSC when in development surely he had it fresh in his mind what he was doing?

Just out of interest, concerning the remarks for static trees and shrubs,leaves grass bushes etc, how would FPSC know if a particular mesh or even mesh part was a tree,grass or shrub etc? I am not being cynical...merely interested since it has always been believed that collision can only be turned off through scripting a dynamic object.
Maybe a lot of this is redundant code that has never been in use or was never fully implemented, or even better is to be implemented go figure.

Awesome! Its one of those threads.
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 19th Jun 2012 20:39 Edited at: 20th Jun 2012 04:34
After yet more testing with collision it appears that I was using wrong settings as Hockeykid suggested. I can only humbly apologise and will promptly eat my own liver as penance for my error.

The TGC entity maker settings are wrong and for many years now not only myself but many other users have been using collisionmode=0 for box collision, this NOT the case.

As above these are the actual settings.

For static objects the collision works as follows:
1 is Polygonal collision
2 is box collision
3 is reduced collision
Any other value is defaulted to reduced for static objects.

For dynamic objects
3 is cylinder
4 is sphere


FPSC does use reduced collision and I am guessing at around 50% reduction as it appears so close to poly collision as to be unnoticable.

Thanks to Blackfox for helping me out with testing, if he hadn't been around to assist I would never have noticed this. (it was a very basic error on my part and probably explained by sitting up too late at night)
And thanks to Hockeykid for posting the correct values for collision.
Thanks go to Flatlander as well for looking a little deeper into the source from what I understand the collision is scattered throughout the source and very difficult to get real handle on.
This thread was supposed to be about 'hidden' and not so obvious features but who would have guessed how well hidden some of this would end up being.
I have changed the first post to reflect this and added other users valuable hints also, if you have any further tips that can add to anything I post, myself and other users would be grateful for them.

Awesome! Its one of those threads.
BlackFox
FPSC Master
12
Years of Service
User Offline
Joined: 5th May 2008
Location: Knight to Queens Bishop 3
Posted: 19th Jun 2012 21:03
Glad to be of help. I'll send over some BBQ sauce to help with the liver digestion.


Twitter: @NFoxMedia
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 19th Jun 2012 21:05
lol, will add tip that barbecue sauce goes well with liver and helps the digestion.

Awesome! Its one of those threads.
Marc Steene
14
Years of Service
User Offline
Joined: 27th Mar 2006
Location: Bahrain
Posted: 19th Jun 2012 21:28
Wow, I didn't know that. So for static entities we should use collision mode 2 for box collision (and so better performance)?


Official LightStorm Engine BETA Tester
/?m=forum_view&t=190541&b=21
rolfy
14
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 19th Jun 2012 21:34 Edited at: 19th Jun 2012 21:49
It depends on what you require, but yes if box suits set to collisionmode=2, it appears that many of the stock entity's have collision set to '1', even crates, which at first glance doesn't make any sense but Blackfox reckons this is due to when the engine was first in build. Its probably the first collision setting implemented so it would be there from the ground up.

It should also be noted that placing entity's with poly or reduced collision near a segment and the mesh intersects, can affect the collision properties of the other (this would explain the falling through floors or getting hung up when getting near these entity's) so setting an offending entity to box would probably cure this if it happens.

Awesome! Its one of those threads.
Wolf
12
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 26th Jul 2012 00:27
just wanted to bump this as it comes in extremely useful as I optimise Catathrenia...

"This thread has been locked for the following reason: Too much EPIC" - Thraxas

Login to post a reply

Server time is: 2020-08-12 20:05:35
Your offset time is: 2020-08-12 20:05:35