+- Frictional Games Forum (read-only) (https://www.frictionalgames.com/forum)
+-- Forum: Amnesia: The Dark Descent (https://www.frictionalgames.com/forum/forum-6.html)
+--- Forum: Custom Stories, TCs & Mods - Development (https://www.frictionalgames.com/forum/forum-38.html)
+---- Forum: Development Support (https://www.frictionalgames.com/forum/forum-39.html)
+---- Thread: Script for proper physic enabling[MAP START] (/thread-9308.html)
Script for proper physic enabling[MAP START] - Rel - 07-22-2011
So i was thinking.
With the amount of objects with physics, is there a script to make sure all the physical props dont just all act physical on a maps start
By that i mean, usually you wont get every prop to be touching a surface perfectly so there wouldnt be any interaction on a maps load, and having every prop use physics at once could cause some annoying stutterting/freezing/ and possibly crashing on lower end machines.
Is there a script or a good way to have it so you can trigger when you want physics to load for props so they dont just all go at once?
RE: Script for proper physic enabling[MAP START] - MrCookieh - 07-22-2011
One possible way would be to fade out the screen OnStart instantly, so you won't notice it.
Don't know if there's such a function
RE: Script for proper physic enabling[MAP START] - Rel - 07-22-2011
(07-22-2011, 06:04 PM)MrCookieh Wrote: One possible way would be to fade out the screen OnStart instantly, so you won't notice it.
Don't know if there's such a function
Its not as much as seeing it happen, but more for optimizing, having so many things interact and use physics all at once cant be good.
RE: Script for proper physic enabling[MAP START] - MrCookieh - 07-22-2011
well, you can't see the lags too, and I don't think too many things using physics in the beginning, won't break the following game
RE: Script for proper physic enabling[MAP START] - Rel - 07-22-2011
(07-22-2011, 06:24 PM)MrCookieh Wrote: well, you can't see the lags too, and I don't think too many things using physics in the beginning, won't break the following game
aight thats good to know, because i know some game engines do, like when some random person makes a map but all the physical props drop or move at the start causes crazy lag and stuttering
Perfect example is TTT in gmod, at the round start it spawns a ton of weapons randomly around the map and causes bad stuttering for a few seconds.
good to know this wont.
RE: Script for proper physic enabling[MAP START] - GraphicsKid - 07-22-2011
It does that on a few of my maps in Amnesia.
RE: Script for proper physic enabling[MAP START] - MrCookieh - 07-22-2011
Rel Wrote:aight thats good to know, because i know some game engines do, like when some random person makes a map but all the physical props drop or move at the start causes crazy lag and stuttering
Perfect example is TTT in gmod, at the round start it spawns a ton of weapons randomly around the map and causes bad stuttering for a few seconds.
good to know this wont.
Well, I said I don't think so, not sure if it really does. But I've never encountered heavy lags in my own map.
RE: Script for proper physic enabling[MAP START] - Rel - 07-22-2011
(07-22-2011, 07:02 PM)MrCookieh Wrote: Well, I said I don't think so, not sure if it really does. But I've never encountered heavy lags in my own map.
It would only be for a few seconds at map start anyways.
RE: Script for proper physic enabling[MAP START] - palistov - 07-23-2011
When placing entities, use the create on surface option as often as you can. This way you can avoid the physics lag at the beginning. Also, the fade-in option is always a good choice.
RE: Script for proper physic enabling[MAP START] - Apjjm - 07-23-2011
Make sure all your dynamic entities are not colliding with the object they are standing on. I always use a small spacing on the grid and have most of my dynamic entities start slightly off the ground, which avoids the problem for me by having all the objects collide at slightly different times at the start. If your entities are placed correctly (I.e no collisions using create on surface or fine-grid placement), and you do not have an obscene amount of them, you should not be having to find a scripted solution to this problem.
However, if you really want a scripted solution, one idea is to use prefixing, and something along the following lines:
Code:
Entity naming conventions:
Stage 0 entities: s0_<NameHere>
Stage 1 entities: s1_<NameHere>
...
Stage n-1 entities: s<n-1>_<NameHere>
Eg: s0_book0, s1_book1, s1_book2 etc
Specify n in the code, along with the time between activations.
Entites which do not follow this naming convention will obviously not be effected. Entities which do follow this convention will only be effected if they are set to deactivated inside the editor.
Again. This is very hackish. You shouldn't be having this problem.Code:
//Sample code (Completely untested!)
void OnStart()
{
cbTmrActivate("Blah");
}
const float _activateTimeStep = 0.05f; //Time between activations
const int _activateStages = 4; //Number of stages to activate.
void tmrActivate(string &in asTimer)
{
//Read in the stage of the timer
int stage = GetLocalVarInt("tmrStage");
//Activate this stage of dyn-props
SetEntityActive("s"+stage+"_*",true);
//Next Stage
stage++;
if(stage == _activateStages) return;
//Writeback the var, loop the function.
SetLocalVarInt("tmrStage",stage);
AddTimer(asTimer,_activateTimeStep,"tmrActivate");
}Of course, setting up the naming conventions, and de-activating all the props that are to be re-activated in stages is really much more time-consuming and difficult than just moving the entities so that they are not longer colliding at that start of the map.
If you do have a lot of entities over a huge area, this can be used with script-areas and some parsing to extract numbers from the collided script-entity and activated the appropriate section of objects as a form of physics de/re-activation, but i highly doubt you have a map big enough for this problem to occur, and it may be prone some some quirky behaviour if not set up correctly.