persistent=1

[SyB 0]

Did a search here in the forums and didn't find any appropriate thread reagrding the 'new' (in 1.4.0.5121) server.cfg parameter 'persistent'.

So... has anyone got any more info on how, why, where, when... yada, yada.

I would have thought that this parameter would mean that that MP mission that is launched on a dedi server will keep running irrespective of whether there is a 'live' person in the mission or not.

And, would possibly only 'finish' when objectives are met or the mission 'end' conditions are met, be they succesful or unsuccessful.

PS. apart from the biki...

Quote[/b] ]persistent=1; Enables or disables the persistent battlefield. Default 0.

Cheers, Sy.

[raedor 8]

You're right, but it does not yet fully work. After the patch it should.

[My_Shortcoming 0]

Quick question on the same area. Does ArmA clear its cache ingame or can it be forced too etc. I was thinking a never ending battlefield with the correct Respawn and randomisation scripts would be possible but would overload the clients or server in time with all the information.

Persistent=1 is going to a whole new world of online gameplay

[SyB 0]

Cool !

Well that answered my question...

My as well close this thread then...

[mattxr 9]

Wow i was also wondering about this command.

Quote[/b] ]Persistent=1

So if i get this right and Persistent=1 that is on the server cfg, and i have a big massive map which never ends because i have enemy spawning [DAC Style] so its not laggy the mission will go on for ever on the server until special condition is met?

[SyB 0]

yip thats right....

For a really good persistent mission/battle though you need to address a number of areas.

People's efforts such a network services, debug consoles, ui creation/modification, unit monitoring systems all sorts of stuff, will eventually culminate in what at least I'm hoping for...

but we shouldn't ramble on in another wishful thinking thread about persistent battlefields... except.... saving would be a nice easter egg for 1.05 dedi server.

[Maddmatt 1]

In order for this parameter to be truly useful, the dedicated server would need to have virtually no memory leaks during the mission, the mission editor also needs to make sure the mission stays clean (it mustn't keep loads of corpses or unneeded variables).

[walker 0]

Hi all

World persistence is indeed a very complex problem. It is not just bodies it is:

Terrain damage.

Position and state of all wild life

Position and state of all civilians

Position and state of all players

Position and state of all vehicles

Position and state of all static objects

Current  state of all buildings

Current bullets and effects

Weather

etc.

We all know that joining a server that has been going for a couple of hours means a long download.

I am guessing that like disappearing foot prints Persistent=1 may also allow scripts for terrain damage to repair after a while but the whole concept and how you deal with persitance is far more complex.

There are other solutions such as loss less compression for terrain damage, separate terrain servers and server farms with terrain and terrain clutter, streamed from central servers rather than held on clients.

I am happy to see BIS setting up a structure for us to test such an environment.

Kind Regards walker

[Espectro (DayZ) 0]

Would be nice having special 'save areas' where people can save their position etc. This could be in friendly bases.

Does the onconnect handler give the ID of the players game?

[zyklone 1]

Would be nice having special 'save areas' where people can save their position etc. This could be in friendly bases.

Does the onconnect handler give the ID of the players game?

Unfortunately not.

The id number it gives is the player number in the #userlist, first to connect is 1 etc. So each player gets a new id each time they reconnect.

This makes JIP pretty useless for CTIs where you want to stop people from joining the other team.

[Johnnie_Walker 0]

We all know that joining a server that has been going for a couple of hours means a long download.

Missions makers should take care of the ammo bugs and the corpses, in every mission I have played i have seen them everywhere. If there are thousands of grenades and clips in the ground, every jip player have to download all this data.

Also the server fps will drop when this happens, the result is desync for everyone.

[UnYx 0]

A few features that would be munch useful for a persistent mode:

The optional ability for the admin (the admin with a pass, but probably not a voted one) : to allow (or forbid) people to access selected slots (or all if wanted). This could be made activable through a flag in the mission file and/or the server cfg.

A "light" or interim version of this feature would be the ability to set a pass per side (Blue/Op/Res/Civ) or to leave some sides open

Two more options would be useful :

* A "freeze" mode allowing the admin to stop/save a game & relaunch it later (VERY USEFUL I.E. for team/community servers where U can set some daily / weekly 1-2hour game schedule during which ppl can play a chunk of a very long mission, in a fixed amount of time, some way like a TV series )

* A kind of black board on each side, where ppl can leave indications for the next ones & the rest of the team...

[-)rStrangelove 0]

How about deleting all AI grps / wildlife / civilians / wreckages after the last human plr left and then have probability scripts calculating how the conflict would've developed into a static state?

Areas still at war are now under full control of the side that had an advantage of some sort in that area.

When a plr connects again he finds the conflict has settled into a static situation and (even better) before going on a mission he'd have to recon what's going on now.