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 Scripts / Umans - Load and Unload Entities on the Fly - Files

Author
Message
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 04:28 Edited at: 21st Jun 2006 01:14
Umans - Load and Unload Entities on the Fly - Files

EDIT : The latest download to include a level .fpm map file is available at the end of the thread - go get it.

If you are going to use this after placing the files in FPSC you may well like to start inside FPSC by creating a new level as a test piece which will save you messing around in any existing level you may have in case anything goes wrong and also because its always a good idea to keep test levels of everything new you discover can be done and once its set up correctly - dont mess with it - then you can always go back and study what you have if things go boobs up in your level for real.

Here they are : Three files attached separately. As far as I am aware none of the files are folder dependant other than they should be in a script folder location somewhere in the main scripts folder and should work from there - FPSC should not be fussy about which Scriptbank folders you place them in as it can be with some other file types.

File 1. zone file : zoneactivate1.fpi

This is easy to use so you wont need a pic : Instructions are :

In editor place standard trigger zone in a basic level with just a floor so you have unrestricted view of whats going on - that way you can see if everything works. Right click trigger zone placed to go to the zone properties and change the default Main script file to this new one. Dont be fooled into using the FPSC default one although they are very similar - it wont work with this set up. Use this new one.

In the If Used field enter the name of the entity you want to activate and load / unload.

Remove the reference to any sound file attached to the zone unless you like odd sounds poping up for no reason or you want to announce your presence to the world and change the ref to a nice hot track.

Thats it for the trigger zone - all done nice and easy.

File attached :

"I am and forever will be your friend"

Attachments

Login to view attachments
Reality Forgotten
FPSC Reloaded TGC Backer
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Wichita Falls TX
Posted: 1st Mar 2006 04:29 Edited at: 1st Mar 2006 04:40
You said three files but all I see is one. uhm am I missing something?

"I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter."
-- Winston Churchill
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 04:50 Edited at: 1st Mar 2006 04:52
File 2. spawndestroy.fpi

This is the file that loads and unloads the entities.

In your new level place an entity or number of entities - for this test preferably all of one kind and of a dynamic nature. You best bet is to place one entity and copy it as many times as you want later.

Now in editor right click the entity and go to its properties. Now unusually you may think the properties file we want to replace is the default appear script - so replace it with this new one. That leaves the entities Main script to be anything you want so you can use this set up with enemies quite happily and they will behave as normal once activated.

Make sure that the entity(s) you place that use this file all have the same name which matches that which you have placed in the If Used field of the trigger zone.

The destroy script is not needed as normally you will want to have these entities spawn and be removed when they are out of your view so you can remove it - but its optional and you may in some circumstances wish to see the entities removal or destruction.

Thats about it - for precise settings which will ensure correct working of this set up I will also add a pic showing the how the entities properties should be set up in editor. Please study it carefully.

Entity load and unload file attached

Attachments

Login to view attachments
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 04:53
Patience man I have to write this stuff as well

Reality Forgotten
FPSC Reloaded TGC Backer
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Wichita Falls TX
Posted: 1st Mar 2006 04:53 Edited at: 1st Mar 2006 04:59
I now realise this bro. sorry.

"I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter."
-- Winston Churchill
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 05:08 Edited at: 1st Mar 2006 05:36
File 3. Jpeg image : Entities load and unload settings in editors properties dialogue box.

This is just as described - it will show you all settings including respawn settings used on entities for this to work correctly.

I would suggest you look carefully and dont miss out any and dont change any to begin with until you can ascertain correct functionality.

The only other changes you might like to make at a later stage is to the entity script file to change the distance parameters for activation to suit or to replace these with some other activation command other than relation to player proximity.

Now when you have set everything up correctly on one entity you can copy it multiple times or possibly just spawn more copies from one entity and test out your level.

If everything is set up correctly and is working properly - assuming you know where your trigger zone is as its invisible - (Place a visible object near it if you like so you know where it is)

Now walk into the trigger zone which will activate the entities.

These will be invisible if you have placed them far away from the trigger zone but will be already have recieved the activation instruction and await player proximity.

If you get to within 900 units of the entities they should spawn themselves - now walk away from them and when you get futher away than 1200 units they should be detroyed and will dissapear.

On approach each time they should continue to appear and every time you walk away they should dissapear.

Thas it - go to it and have fun.

You may like to save or print these instructions for future reference.

Good luck.

Jpeg attached.

Attachments

Login to view attachments
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 05:20 Edited at: 1st Mar 2006 05:21
Reality Forgotten,

Your welcome. Sorry it took so long but you have it all now so you should be able to get it all working as it should. If it dont work I guess something has not been set up correctly or FPSC is just being silly as it does. Personally I am using this extensively on all sorts of entities including enemies and it works perfectly every time.

The beauty of testing it as I suggested in an empty level is you can see it working or otherwise one has no proof of such if the entities do so out off player vision.

One tip for all :

In real levels If necessary when attaching these scripts to new groups of entities go back to the entity script file and adjust the distance settings to call the activation at closer proximity so that when I get into a room I can actually test to see the entities spawn and get destroyed as they should then when I can see everything works correctly go back and adjust the script distances back to my defaults - if you dont do this and cant see it work as proof the entities could possibly not be set up correctly and exist permanently and you would never know.

A nusiance I know but theres no other way of proving correct functionality in each case.
Reality Forgotten
FPSC Reloaded TGC Backer
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Wichita Falls TX
Posted: 1st Mar 2006 05:50
Thanks man, This is a big help. and is easy to play with. I don't have to have one single enemy loaded at start up in my map, sweet!

"I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter."
-- Winston Churchill
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 06:05
Sweet as a nut.

One thing Ive not yet gotten around to trying yet is how this can relate to static entities - but thats for another time. Its enough for the time being that dynamic entities influence on fps can be hopefully lessened or taken partly at least out of the equation.

transient
19
Years of Service
User Offline
Joined: 22nd Apr 2005
Location: Australia Zoo
Posted: 1st Mar 2006 07:28
I've only had a quick look, but you spelled settarget wrong in the 'oneactivate.fpi'.

Also, I wouldn't mind knowing why it's there?

I looked in the manual but it was a bit vague about it's purpose. I know it's used in 'shoot.fpi', but not why.

instinct is more valuable than intelligence.....
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 12:25 Edited at: 1st Mar 2006 12:38
transient,

settarget,

Does what It says or is supposed to I presume : that is sets the named entity as the target.

What that means in prcatice and how a target is named is anyones guess. As with most things FPSC practical application of the scripts are poorly explained and supported. There is no real or full explanations of the scriting language so we have to guess - thats real helpful I know.

Anyway no good asking me as you all know I stink at scripting and other than whats in the manual and understanding anything obvious script commands or actions with refernces in common english such as plrdistwithin=X which is self explanatory I have no idea how exactly and with any certainty how anything works and even when it does why ot does. The FPSC scripting language seems to be arse backwards to me so I try backwards first and just keep up with a trial and error method using commands I feel should do the job until something works - then add a bit more. The main probelm is I have no idea in what order things should be placed so I work in complete confusion, so its a matter of like the lottery trting every permutation possible and it will get done right. Not a very good way to work I know - though in the main I have not yet failed in trying to script anything into action. Point is I get it done by luck if you like.

Who cares about the spelling of settarget - Sorry it was not perfect for you - if you dont like it change it - then it might not work. Otherwise leave well alone an dont worry about it. And by the way you referenced and spelled "oneactivate.fpi" incorrectly.

Still thanks for pointing it out - its should of course be corrected - in point of fact some parts of the script was and in my case is usually derived or copied from other existing scripts and I cannot say exactly in this case which parts. I then add my own additional code inside what I have copied or mix and match lines or bits from various scripts to make up a whole with the addition of anything I add myself to get the job done. It may well be the case that some parts of a script dont do anything - sometimes I think that and take them out and a script wont work - so in parctice when a line seems to be meaningless in terms of any direct result that can be seen by the player in game it may still be needed by the engine for a script to function correctly and your guess is as good as mine there. One thing I have found is sometimes a well followed rule and that is if it works - leave it alone or you may find yourself going around in circles. So if you get a bit of script working back it up before you change evrything and mess it up and forget what you did earlier or youll get a headache.

Spelling - I write so much on these things my hands and brain hurts - you are lucky anything you get from me works at all - and if it dont well you have a go - your welcome to make things better and give it back to the community so I and all the rest of the community can benefit.

As the famous saying goes "It works for Me"

uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 13:57
UPDATE :

Heres a little info for those specifically wanting to load enemies and other dynamic objects which which get destroyed are exploded or killed and dont need to respwan.

I guess from looking back over my post I should have made this clearer. So I am doing so now.

You dont need to apply the new scripts to these kinds of enemies if:

1. You dont want the entities to exist until you get close to where they are in your game so they only appear on player proximity.

2. They dont need to respawn but are killed once and never need to come back.

To just achieve this you dont need these new scripts. All you need to is use the default scripts supplied with FPSC and in their properties dialogue box in editor set Spawn at Start to No and Max at any Time/Max Spawn/Number to Spawn all to one.

Thats all thats needed - you can see that for yourself.

These new scripts are particularly releveant and needed only to load and unload all the other dynamic entities that can form part of a level - if they use AI then you may benefit from these scripts.

Anything that performs an action can benefit, anything that is moveable that you can push around or anything that is animated. Under normal circumstances - all of these things take up a lot of AI think time and hog engine resources - possibly all at once.

Examples of these kind of objects are moveable or pushable entites (entities calling on the physics engine) e.g. boxes, crates, barrels, tables, chairs. Any dynamic entity which forms part of the structure - so it could be switches, lights, decals, entities with destructable glass, doors even if not needed to block vision or leaks and its debateable whether they even do that. Use on friendly characters that you dont kill but you want to always exist

"Sure You Can" - The other situation is you "can" use these scripts on entities that are explodable and can be destroyed or killed by explosion, shooting or any other means and use them on enemy type entities or enemy characters that in your case you may indeed want to respawn. Thats not what its designed for as most destroyed objects dont come back to life in reality - but your game may be different and you may want them to respawn. If you want this then by all means use them and replace the default files with these on all your respawnable objects.

I think that covers all options and trust that when and where you should use these files is a little clearer.

You will work it out I am sure - just use what you have to - to get the job done in each situation.

Its all common sense and self explanatory really and a little trial and error will find the perfect solution in each individual scenario.

Thats my lot - cant help any more. I'm going back to game making.

Good luck all.

transient
19
Years of Service
User Offline
Joined: 22nd Apr 2005
Location: Australia Zoo
Posted: 1st Mar 2006 14:37
I mentioned the spelling because I thought it would break your script and you would get noob-bashed.

I couldn't care less about proper punctuation, I was just trying to help.

instinct is more valuable than intelligence.....
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 15:20
transient,

Noob bashed - I dont mind that. I may eventually change it this end and anyone reading this may want to - though as said I am not sure that it has any bearing on the functionality - changing it will provide the answer.

Thanks for taking the time to look that closely and finding it - you have probably done that more than I. As with many things I work on the difficulties and constant testing of stuff for days on end means I get a little frustrated with working away trying to achieve something and as a result as the saying goes "cant see the trees for the woods" I am probably the last person to spot mistakes in my own stuff.

Thank god I use test levels for all experimental stuff - if I were to use a real level It would take forever waiting for test compiles to take place. Some things I have had to test run out in editor many hundreds of times to get something correct and the constant compiling for evry little teak takes so much time away from actual development construction that I will never finish my first level if I dont get a move on.

Recently I spent quite a lot of time perfecting a single character and how he interacts with the player as he has to carry out various things and also speak to the player when appropriate. Got it perfect in test level - then when inserted and set up in the real level the behaviour of the character changed and still differs somewhat being influenced by I believe all the other dynamic entities in proxinmity.

Still I am sure you did not want to know that but it may be helpful in case similar happens to others.
Reality Forgotten
FPSC Reloaded TGC Backer
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Wichita Falls TX
Posted: 1st Mar 2006 15:23
Thanks for the clarifacaion UMAN.

"I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter."
-- Winston Churchill
Reality Forgotten
FPSC Reloaded TGC Backer
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Wichita Falls TX
Posted: 1st Mar 2006 15:29 Edited at: 1st Mar 2006 15:41
Quote: "1. You dont want the entities to exist until you get close to where they are in your game so they only appear on player proximity.

2. They dont need to respawn but are killed once and never need to come back.

To just achieve this you dont need these new scripts. All you need to is use the default scripts supplied with FPSC and in their properties dialogue box in editor set Spawn at Start to No and Max at any Time/Max Spawn/Number to Spawn all to one.
"


Ok I tried this and once again I got the invisible enemy after I walked through the zone. so I changed the main to your zoneactivate1.fpi and it sorted the problem out. I think that having the entitiy invisible at the start before respawn is something we are going to have to deal with since it has to be int he game for the engine to call on it.

is it possible to create a trigger that will call on an entity from the library (objects loaded in the library and not the game) and place them at a marker pre-positioned in the game? This would take care of the invisible enemy problem. though you can shoot the heck out of the invisible marker and it will still spawn with full life when trigger is activated.

"I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter."
-- Winston Churchill
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 1st Mar 2006 17:55 Edited at: 1st Mar 2006 17:56
You did not read the download instructions carefully enough or otherwise you would see its says to use the zoneactivate1.fpi file as you have now done. You were too keen last night in not waiting for for the full instructions and I cant blame you - thats sorted.

The secomd point first paragraph is completely relative to the distance settings for activation in the script file - and you are not reading my post above. Its impossible to have the entity spawn unless you call it via actiavtion command - the command used is plrditwithin - so if you place the zone in a position relative to the activation distance i.e. further away than plrdistwithin setting in script the entity will always be spawned wehn the player gets within the activation range - in game and visible if you use the advised procedures - if you want on the other hand to spawn the enity to life at the time the player enters the trigger zone as you wish you can do that without any effort too if thats the way you want it - simply adjust the distance you want to spwan the entity at in script - then move or place the trigger zone (any size or placement) so that its position matches (encompasses) the distance that you specify in script. If both match up - walla the entity will spawn and activate immediately when you walk through the trigger zone. Flexible aint it. - a little thinking and thats sorted too.

Dont need to concern yourself with the library issue now - the above sorts your concern. You have no chance of doing anything related to the editor.

Just remember you can basically - work the adjustments to suit yourself - adjust settings, shape trigger zone ands size to suit.

I really cant see how anyone would be able to get an invisible entity (unspawned) unless they purosefully set up things to do that adjusting the range and trigger zone position will remove that possibility every time.

One other thing though - which needs looking at for future reference and anyone can look at this if they want to find a solution and post it back at this forum so we all can benefit.

In outdoor levels (dreaded words again) using this system is rather more difficult. Concievably this could be used to load and unload entities to great benefit in outdoor levels where fps is at a premium. e.g. we dont need a lot of perdestrians active say around a corner out of sight or enemies in buildings at the other side of a level which are active or walking about doing stuff so they could be loaded and unloaded as the player moves about (just think of the benefits of this)

One of the main problems with load and unload is similar to that mentioned above. e.g. Picture this : around the corner - those pedestrian entities which have not yet spawned dont exist yet do they? - if we get near the corner they will spawn into life and we see them when we get around the corner - now turn around and go back around the corner out of sight and the pedestrian entities are removed again - of course they will continue to spawn, die and respawn as we do this - now we go back around the corner so that the entities are removed - walk on a bit and we decide to go into a building up and onto the roof - now from the roof its posible to find a situation where we can look down and those pedestrian entities dont exist when perhaps they should - you could assume that they have walked somewhere out of sight but somehow the streets look kinda empty - no moveable objects anywhere in sight (dont get me started on static entities yet). You see they point - users with enough clever level design could aviod much of this but ultimately load amd unload based on player proximity alone may well not be flexible enough as relative distances and the important entity in view distances mentioned above are difficult in such situations to balance to meet with all scenarios.

Flexibility is important and perhaps someone perhaps myself at some later date will look at other activation control commands or methods to advance such a load unload system further. Maybe plrcanbeseen=X or "noiseheard" or whatever could be incorporated to extend the possibilities.

Anyone care to spend time and let us know how you get on? I will do it but you might as well wait for TGC to do it - they will probably get it done before me.

Les Horribres
19
Years of Service
User Offline
Joined: 20th Nov 2005
Location: My Name is... Merry
Posted: 3rd Mar 2006 03:12
Cause it needs one

Merranvo Nunticaelitusphobic (Scared of Internet)
Noob Justice League, Cause We Have More Fun
Support Merra XJ9, cause the name is cooler.
Skitza
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location:
Posted: 12th Mar 2006 15:50
Bump- this should be a sticky.
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 13th Mar 2006 00:17 Edited at: 13th Mar 2006 00:21
Well it may help some if they want to get into the work it involves - which is not really a great deal.

I am still evaluating its potential and affect if any on gameplay speed issues and if nothing else its certainly useful for certain game benefits.

e.g. In already complex levels I can add another 20 + dynamic entities (barrels to a single vast open room) and no idea how many more might possibly go in - without any affect on fps - Users can easily use this to stop those annoying 3D sounds playing all at once on entities everywhere through your entire levels from one side to the other - starting them and stopping relative to player proximity and that must take the strain off the engine and cpu when there are so many other dynamic entities active which would otherwise all be active in your levels at the same time.

Just two benefits I am finding - at least I dont find any disadvantages myself - except it takes a little work to set up throughout a level if you have large numbers of dynamic entities you want it to work upon.


Apparently - FPSC should disable any Dynamic entities by default if the player is beyond a certain distance to save of the engine processing of unecessary entities if the player is not near to them - but that still leaves them and their polys in the level - even if frozen - perhaps? who knows how this is supposed to work. I am not sure exactly what criteria the engine usees to make this decision (player distance or player visibility) but recent testing of mine seems to indicate at least that if an enitiy is in direct line of sight to the player i.e. the player can be seen then this does not take place. In test it does not with me in an empty level with an enemy at one side and the player at the other side the enemy moves directly to the player across the entire level to attack. The entity in this case certainly is not disabled at distance. Perhaps a reason that AI entities drain fps more than they should - more of them may be active at any one tme than you may think - this can only be seen or proven to be the case if you can see exactly what the entities are doing at all times - difficult unless in wireframe mode inside the test run in editor. I will be posting more of this elsewhere.

One things for sure you can remove them physically using this load/unload method - whether or not they still have any influence at such time until they are respawned I cannot say for sure.


FredP
Retired Moderator
18
Years of Service
User Offline
Joined: 27th Feb 2006
Location: Indiana
Posted: 7th Jun 2006 00:30
I stickied this and I recommend reading it.

FLa
Where you can find my demo:http://www.savefile.com/files/6970524
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 13th Jun 2006 21:07 Edited at: 13th Jun 2006 21:08
In case some users are finding difficulty in getting this working.

If you can wait a litlle while - I will be updating the L&U entities this thread to include a level .fpm for users to download. That way they should be able to run the level file and see it working and thus study and copy exactly the settings across to their own game levels and get it working more easily.

Hope that will help.

Cant say exactly when I will get around to doing it but I will do so as soon as I am able.

Keep a watch on the thread - I will let you know when its posted.



"I am and forever will be your friend"
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 21st Jun 2006 01:08 Edited at: 21st Jun 2006 01:22
As promised I am attaching a new download here to include a working demo level .fpm file showing the load/unload functions in action.

With this a user should be able to open the level file and see exactly how the entities need be set up by studying the setting for each so that they can understand more easily how it works and apply the same procedures to their own game levels if they wish.

Everything you need is in the one download. The level uses default media.

To use this after download :

1. Copy the script files into a script folder inside FPSC - the main scriptbank one if you want.

2. Copy the .fpm into your mapbank folder.

3. In FPSC editor open the map file (.fpm)

4. In editor window zoom out until you can see all objects. To the right you see a box behind the player marker - the box is just a positional marker itself.

To the left you see 4 boxes - they are the ones that Load/unload (spawn/destroy/respawn).

In the middle you will see a small room segment with a dark floor tile in front and a trigger placed over it. That trigger zone is the entity which activates the load/unload functions attached to your box entities.

5. Now before you do anything else you may need to make sure that all of your entities can reference the needed script files you have copied into your directories as no doubt they may be located in a different place on your computer to where they are on mine - so right click each entity in turn and in the entities properties dialogue box click the option next to the relevant script files and loctate the correct scripts as named in the text fields.

Once done you are ready to go - you should not need to do anything else.

6. Test run the level. When it loads you should be looking towards an area where the 4 boxes will spawn or load but they are non existant to start with. As said you need activate them - and once only is all is needed. So walk over to the single room segment where the invisible trigger zone is located on the dark floor tile. When the player gets to the trigger the 4 boxes are activated and should come into existance if you are too far away from them move towards their position and they will appear. This is controlled by distance settings in script so you can edit the relative distance suitable for your own use - I find my defaults to be suitable for most of my requirements.

Now that the boxes exist you need to move away from the boxes - back in the direction from which you came (any will do in real game) which is why I placed the box marker at the player start position - move back in that direction - best backwards whilst facing the 4 boxes so you can see what happens.

The 4 boxes should now dissapear when you get close to the start location where the box marker is.

So we have spawned or loaded and destroyed or unloaded the boxes. But what if in our game we want to go back into a room where the boxes existed - they would now be gone - well not really as we can load them again.

Simply face the position where the 4 boxes were and walk forward towards them and they will load up or spawn again - back up and they will dissapear again and so on.

In this demo they are set to respawn 99 times and that should be enough for most games but you can adjust this in the entities properties in editor.

Again Please Note : once activated by the trigger zone and scripts they will remain active until no more spawns are available - you only need enter the trigger zone once and only one is needed - so if you have a room with door in and door out say the single trigger zone would only need be placed outside on the approach to the room at a suitable distance from the first entry door a player encounters on his way to the room - then when the player gets to open the door and enters the room the boxes or any other entity with these scripts applied having the same entity name which would not have existed before trigger activation now exist and will always do so if the player enters the room and will be removed when he exits.

Remember for that to be so you may have to adjust the distance settings in script and set up your levels accordingly.

I would suggest that you make backups of the download files and keep them safe and also print this post contents for reference.

Do not be tempted to cut corners and use any old trigger zone activation script - it wont work - use the supplied activate1.fpi script file.

I dont support this in great detail and theres no need to - thats why you now have the demo - and its not rocket science.

Hope that helps and good luck with your endeavours.



"I am and forever will be your friend"

Attachments

Login to view attachments
xplosys
18
Years of Service
User Offline
Joined: 5th Jan 2006
Playing: FPSC Multiplayer Games
Posted: 23rd Jun 2006 20:49
As I read through your walk-through above, one question came to mind. I will ask because you probably already know, but if not, I will be working with this and check it out soon enough anyway.

In the course of a game, we set up player checkpoints to help get us over difficult spots. When we die, we return to start play at the last checkpoint, however all does not return to it's pre-dead state, if you will.

The important part here is that any entities we have destroyed or items we have used, remain destroyed and used upon our return. Because the script remains intact, I would think that a player checkpoint would have no such affect on it, but sometimes I just can't follow things well enough in my head.

Is that the case here and do you know of any such thing that would affect the script?

I hope I made myself clear and I appreciate your work and response.

Crazy Grandpa
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 24th Jun 2006 02:34 Edited at: 24th Jun 2006 02:37
xplosys,

I must admit that I do not quite fully understand what you are asking so you will have to excuse my ignorance.

Anyway if you are asking - do checkpoints have any bearing on how this works - I must say that I guess it depends on how you design the levels with regard to the positioning of checkpoints in relation to this systems usage and the positioning of associated entities.

I have personally not even myself carried out enough testing with this system in all game scenarious one could think of - far from it. For instance I have not applied this say to outdoor levels where it might possibly be used very effectively for obvious reasons in calling enties only when required thus removing the burden of them in areas where that would be particularly important in keeping fps high. For eaxample one could concievably remove much detail content from say an outdoor street : vehicles, lamposts and all such external detail - even characters until needed - thus one could have an almost empty environment until a player needed to turn a corner and enter a street and at such time entities in a street could be removed. In effect only those entities likely to be in view are called and everything else removed. It will require carefiul level design and gameplay plan but may work well in the right circumstances.

I can say that in the levels I have tested it out it - the way I have set it up and designed the levels I have not found it to interfere in any way with inserted checkpoints which behave independantly as TGC have currently accounted for them to do. That may just be the way I have things placed.

I do have checkpoints within range of the systems effectiveness - I can say that those checkpoints do not interfere with this system working correctly.

Hopefully any update may change the influence of checkpoints in ways we do not yet understand so a new set of rules may need to be acoounted for.

As said hopefully at some stage I will do more work on this and in the meantime I am sure other users can and will develop such further and find improved possibilities for its use.

On its own its not enough to give users enough power to ignore level complexity and fps as there are many other issue out of our hands. Given that we can see some improvements in those areas then such as system as this will come into its own and the real benefit will be seen.

If you think of an improved performance all round then you could possible think of larger FPSC worlds - well worth contemplation.



"I am and forever will be your friend"
xplosys
18
Years of Service
User Offline
Joined: 5th Jan 2006
Playing: FPSC Multiplayer Games
Posted: 10th Jul 2006 21:21
Thanks for your response. Sorry it took so long to get back to it, but I just have begun using your scripts. They work great and I can add and remove entities at will. My previous question has been answered by my experimentation, and the results are excellent. When you are sent back to a player checkpoint, the scripts once again do their assigned job and the level is much more the same as it was the first time you tried, instead of being void of entities that were destroyed on the previous attempt.

The only issue I am having is with enemy entities. They appear and disappear perfectly, however the transporter beam has fried their brains, and they just stand still, no matter which script I assign as their main or default.

Any insight will be much appreciated. Thanks.

Crazy Grandpa
Dr Cuddles
18
Years of Service
User Offline
Joined: 8th Jul 2006
Location: In your toilet...*Splosh*
Posted: 11th Jul 2006 15:19
I am using this script on all the entities in my level and even some of the stationary characters i am using for detail but i know you explained this before but i still don't understand how to load entities only once and never respawn

,thanks

"I dont' know what weapons will be fought with in WW3 but in WW4 it will be sticks and stones" - Albert Einstien
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 12th Jul 2006 10:48 Edited at: 12th Jul 2006 11:00
Dr Cuddles,

Using the scripts you still have right click an entity in editor to set the number of times an entity respawns in the entities properties.

xplosys,

Its been a long time since I actually worked with the scripts in respect of characters and even when I did it was not in depth as I have few of them in my early levels and they dont really have a need to respwan once passed by the player.

These scripts initially were not designed specifically for use with characters and indeed they are or were a WIP so more work needs to be done with them to extend if possible the functions which I would do when needing more functionallity later in game dev. They did what i needed them to do.

If I remeber correctly enemies may not be activating correctly - this is probably due to the fact that they in fact dont actually do just that - theses scripts spawn them but not actually activate their brains as you put it so they are unaware of the player and thus just stand ignoring him and their environment without reaction.

If you do a test and use the main script and change the appear script to the default appear1 then they should activate OK but that would mean that they would only spawn once and then be removed once the player has passed them in the game scenario. In this instance they would then never respawn - not whats wanted in some scenarios.

I think thats what I remember as happening anyway - So whats needed is for myself or someone else to combine the appear script I made (activate1.fpi) with some additional scripting to get the whole thing working with the points we make here.

Not sure if it can be done as again briefly from my tests I made it may be a case that the non activation of enemies is caused by the engine not recongising the need for them to do so while using this script. Enemies are a particular case to the engine and the source is the source - if it conflicts with any script we make then it takes precedence. It may need to be overcome in source though thasts not certain.

A study of the point I made regarding activation and the default appear1.fpi in relation to the activate1.fpi script and the way FPSC treats enemies may provide and insight into why they dont activate. A little further study of how the activateifused command and a little more scripting should do the trick - however that could mean a condsiderable amount of actual work and experimentation in levels to solve the issue.

Im no expert scripter so I will do more work on this when I need to - a knowledgeable scripter here at the forum of which there are many may well be able to improve the scripts more easily than I.

If I get around to extending the script functions I will certainly pass them on here.




EDIT : Thinking about it quickly - it may be that in the case of dynamic entities - the associated trigger zone only activates once or not at all in some instances as FPSC trigger zones are very finnicky and dont work well with all entities - I use simple invisible cubes sometimes instead and they work when FPSC default ones dont - using a different trigger/activation script such as plyrinzoneactivateifused may work so its a matter of further experimentation.

It may be possible that in the case of entities activation using triggers the activation "Switch" needs resetting as it were so if that cant be done then it may have to be the case that an entity can be removed but would need a second trigger zone to reactivate it.



"I am and forever will be your friend"
xplosys
18
Years of Service
User Offline
Joined: 5th Jan 2006
Playing: FPSC Multiplayer Games
Posted: 12th Jul 2006 22:53
Thanks again, uman.

I will try a few things and let you know what I come up with.

Crazy Grandpa
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 13th Jul 2006 10:49 Edited at: 13th Jul 2006 10:50
xplosys,

Hopefully my post above was of some little help - I dont fully understand what goes on in the engine in regrad to dynamic entities and how they respond to the Always Active issue which may have a bearing on this.

Originally as I have said I only worked with these scripts to try and reduce world polys in aid of optimisation - and it works increasing fps dramatically in my games.

I load and unload my NPC's and any other dynamic entity which appear in numbers i.e. boxes, barrels, pipes, light fittings, even cave walls and ceilings.

As with enemies in many areas they are a special case - their inbuilt activation/sleep commands/routines (always active flag) are perhaps both complex and possibly flawed - their behaviours are always going to be difficult to precisley control.

Anyway these scripts are open source as it were and free for everyone to advance if they can and hopefully give any improvements back to the community.

I made the scripts out of necessity and have not really worked with them since as they do the job needed - more work needs doing with regard to enemies in many scripting areas not only this one.

However - this and those other areas are really a job for TGC to advance AI in the engine itself as anything we can do is limited and a workaround at the end of the day.

TGC I believe could achieve a better, smoother and more efficient version of an in built, default Load and Unload Entities on the Fly System with a clickable user interface for some parameters and I hope they will consider doing so in any upgrade.

This is why I have not progressed this in particular - I await any upgrade and if one thing or another is not forthcoming then user progress of some of these things will need to continue if possible.

In my case if the upgrade is not here when I need to work in outside levels again the dynamic calling of enemies and other entities on the fly I will need to work on more extensively for obvious reasons of gameplay speed and fps efficiency.



"I am and forever will be your friend"
xplosys
18
Years of Service
User Offline
Joined: 5th Jan 2006
Playing: FPSC Multiplayer Games
Posted: 14th Jul 2006 19:58
uman, again thanks.

I too will work with it as I need to. I am not normally concerned so much with enemies, and spend more effort trying to create a realistic and interesting environment. After looking at the work of people like yourself, crow, jon etc... I know I still have a long way to go. I give it what time I can between working and family.

I started screwing around with enemies because I decided to enter the level design comp, and that's why I asked you about it. As I get more into enemies, I will continue to work with it and see if I can figure it out. No big deal now, though.

For now I know I don't have to spare the little things that make the game more realistic, because I can load and unload them on the fly, keeping the FPS where it needs to be.

Crazy Grandpa
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 14th Jul 2006 22:19
xplosys,

Ive not worked much with FPSC lately - like you I am very busy at work and have a family to fit in. I also await with eagerness any FPSC update and I have done enough with it currently to fully understand most of its limits and benefits - further development of mine will be utilising any improvements any update may offer and personally I dont want to finalise any levels until I know what those might be.

Just a comment on numbers of entities - I have in one single level something approaching 600.

There may be a trade of in using these scripts in as much as it may fall within the laws of diminishing returns. Eventually FPSC may have to do so much work handling any data relating to loading and unloading - keeping track of everything - there may be a limit to its usefulness and a balance exist somewhere along the line. I have not yet fully ascsertained where that balance may be if it exists.

I guess there must be a limit somewhere.



"I am and forever will be your friend"

Login to post a reply

Server time is: 2024-11-23 01:29:16
Your offset time is: 2024-11-23 01:29:16