Reality Factory

great work! Large environments were always a pain with RF. You approach seems to be simple but effective. I think that the framerate improvement is the more effective the bigger is the level.
Keep up the good work.

@Juutis

I'm thinking mainly for pawn scripts. Like... could it disable a script for a pawn that is, say, two rooms away from the player? With big levels and lots of enemies, the amount of scripts can bring the framerate down pretty much. So I'm just thinking that could the entity disable those scripts that aren't needed, even if the player was just on the other side of a wall?

He wrote that the scriptable entities aren't affected by the EAS. Anyway you can easily turn off the pawns by script letting them execute a simple highlevel order and turning off the rendering. The problem with scripts is that if you stop them by code (I mean modifying the CPawn source), then they will restart from the beginning and not from the last order. That's why I added in my build a "self.order_name" variable to read the current order name. I can put the script in a holding order when I need it, and then make the script return to the last order executed (storing his name before the change).

Juutis wrote:Great work.


I'm not sure I understand how this works, though...

Could this entity be used in a closed environment?
I'm thinking mainly for pawn scripts. Like... could it disable a script for a pawn that is, say, two rooms away from the player? With big levels and lots of enemies, the amount of scripts can bring the framerate down pretty much. So I'm just thinking that could the entity disable those scripts that aren't needed, even if the player was just on the other side of a wall?

Of course. That is the idea. But i think you would have to use a few tricks, because right now all areas have the same size (it does not look for walls only for the Players position), so you will have to try until it fits. When i was designing the Y divisions for example, i thought of a skyscraper that has many different levels. So that the Entities that are a(or a few) level up and down aren't taken into account.

That is then done automatically - Or you could disable them via a script (i am planning to write script commands later but that bug i mentioned has a higher priority). But this only works if you have an EAS in the level. Hm. I could also make it that you can do it without an EAS. I think that's what i will do then.

@federico
I meant you can still modify the Pawns from other scripts, i first had an approach that culled the entities competely (out of the engine) but then i thought that then it would be a pain to modify them with all this Enabling/disabling and stuff. Then i made it all simpler. Now they are still 'there' but they don't 'run' (their execution is stopped. For a pawn that means its script is stopped, a foliage entity does not even need to check its distance to be culled Flame entities are not drawn and so on)

That's actually the case for the pawn test - alot of scripts are stopped and because of that it is faster.

Global Entities aren't affected in any way by the EAS. That's why the scripted player still works.

About the script starting from the beginning, i have to see if it is like this or not.

-------------------
In case you did not see it, i copied the list of auto-culled entities from my above post here:
Attribute
Pawn
StaticMesh
StaticEntityProxy
ParticleSystemProxy
Flame
Spout
DynamicLight
FlipTree
Foliage
FlipBook
ActorSpout
FirePoint
FixedCamera
Rain
DSpotLight

The fixed cameras can still be activated by the ForceTrigger. All of these entities can be global entities.

So the level is divided into areas like a chessboard or something?

And if I fit my walls to be on the edges of the areas, the entitys on the other side of the wall aren't taken into account?

exactly.

This bug is really annoying. It happens when geWorld_Free() from the GenesisEngine is called but is not there when the EAS is not there. It seems that something inside Genesis wants to call some function on the EAS and somehow it does not work. I am totally confused. Does anyone have an idea where the error might be? maybe QoD or Nout?

Allright, now I think I got it.

I hope you can get rid of that bug...

Does anyone have an idea where the error might be? maybe QoD or Nout?

Can't say much without some code...

I sent you an email with my version of the source code and the changed source files of the Genesis source..

I've got it but I'm just too busy to look at it right now.

So....I can go ahead and make my environments ?And just wait for this to come along?

( not much of a programmer, but i do understand rf's script system)


I do see that the latest version of Rf now includes more rpg-like stuff, and you say more is on the way???? waaaaaaayyyyyy cool!



And just how did you do that flipbook inventory??????

Well i am out of ideas with this bug. I hope QoD can fix it as i am really clueless there.

About the flipbook inventory, i don't know what you mean (i said nothing of the sort i think), but something like this IS possible (i've actually done this before, requires extensive scripting)

Voltare wrote:And just how did you do that flipbook inventory??????

If you mean a scripted inventory, I have one of those in my game.
You can download the demo here:
http://koti.mbnet.fi/jutkula/NirhisInstall.exe

Sorry for going offtopic.

Ok, some new additions:

-Gravity is now represented as a 3 component (XYZ) vector. Means that the gravity is done like 2 to the left 6 downward and 0 forward rather than just 6 donwward. This could be used to simulate new effects. You can set the Gravity by script. Also the EnvironmentSetup entity was changed to fit the new system.
This could be used to simulate Zero-Gravity and also very strong wind that throws things through the air.

-We now have Particle Wind which can be dynamically adjusted. That means, you can set a wind value in EnvironmentSetup that then acts as a wind value for the Particles (there's no easier way to explain this, it really works like wind). And you can adjust it via script. But because this can then look blocky without transitions and everything, i invented a new thing:


THE WIND GENERATOR ENTITY
-generates more realistic WindValues
-interpolates wind speed between Max and Min values.
-interpolates it over a specified time
-adds the computed wind value to the base value provided in EnvironmentSetup, this way you can have the wind coming from the north but it will have some randomness in it to look more realistic
-you can specify a ThinkTime that works like in pawn scripts

Particle Wind works with Spout, Flame and Rain Entities.
You can set for every entity if it should use wind. The idea is that you have outdoors (use wind) and indoors (do not use wind) inside one level and still are able to use particle wind.

-The following scripts commands were added:

Environment_SetGravity(float x, float y, float z);
Environment_GetGravityX();
Environment_GetGravityY();
Environment_GetGravityZ();
Environment_SetWind(float x, float y, float z);
Environment_GetWindX();
Environment_GetWindY();
Environment_GetWindZ();

Awesome!!
Once I was about to post something like that in the feature requests - There was something cool I wanted to do with the wind. I just can't remember what it was right now. But I'm sure it all comes back to me when I get to actually test that thing.

Sounds really great to have "very strong wind that throws things through the air. "

And "Particle Wind which can be dynamically adjusted"
Nice work

I wonder what kind of hit this has to the frame rate?

The Wind has almost no effect on the frame rate. Really.

About the Gravity i have to see because right now it seems to cause alot of Collision detection when for X and Z numbers other than 0 are used. If they are 0 (like it has been before) then there is absolutely no effect on the framrate.

The ParticleWind however runs great. I will refine the WindGenerator so that it also has Pausetimes between the wind strokes.