Jump to content
Sign in to follow this  
KilJoy -SFG-

Evolution V1.0 Large scale respawn coop

Recommended Posts

@ May 11 2007,19:28)]that sounds interesting but i dont see how a script could detect the majoity of players who cant run an extended view distance.

I was initially thinking of an additional set of action menu options alongside the existing ones, purely for setting flight view distance, but thinking now, it would be better to add the action menu options somewhere closer to the jets/choppers themselves.

You almost need a new dialog just for all your configurable options! whistle.gif

There was/is a set of scripts for OFP that at mission start calculates  the lowest average (or something like that) for all connected users. works really well.

it was made by daddldiddl or joltan or daddl (or whatever he calls himselfs) he usually hangs out at www.suicidesquad.co.uk

Yes it was Daddl, but I aint seen him around SES lately although maybe somone there (or I could) look into converting it to armed assault.

The thing was Daddls script set the view distance on the server so every1 had that viewdistance if you had a bad or good machine, wheras Kiljoy's script lets each client set there own viewdistance individually.

Share this post


Link to post
Share on other sites

Kiljoy,

I noticed that in 1.07, all Special Forces (SF) soldiers have the new black helmet. Since most of the Evolution soldier slots are SF soldiers, just about everyone in game is running around with the black helmets. The only soldier with a regular helmet is the medic now. I'm not sure if you intended this, but I just wanted to make you aware if you are not already.

Share this post


Link to post
Share on other sites
WarWolf @ May 11 2007,18:11)]Does the new 'save stats' feature of 1.07 mean that Evolution will be able to keep your rank between sessions when it's updated for 1.07, or will that not do what you need for the map?

It exports stats, basically you can create stat-based site for your server

How does it work?

Share this post


Link to post
Share on other sites

for me it's exactly otherwise ...

1.07b is definitely better than 1.05b smile_o.gif

Share this post


Link to post
Share on other sites

First off thanks for the great mission Kiljoy, was the first mp game for arma I played and still takes up much of my time.

One thing I'd like to see in game is a little love for the medic. As it stands the medic class is mostly inconsequential as it's easier to just die and respawn than get patched up. I think a system where respawning as we know it is removed and replaced by a new system. For example if you get heavily wounded in combat you fall to the ground incapacitated and put in a call for a medic. You have X number of minutes/seconds to be patched up by a medic until you die. If you aren't patched up by a medic you die and respawn at base with a loss of points. For real hardcore realism you could have total loss of points on death, but that might not be for everyone wink_o.gif

Also a drag script or carry player script would work well here. IE a squadmate could drag/carry a wounded buddy back to a medic or a medevac point. Just a thought, and keep up the good work smile_o.gif

Share this post


Link to post
Share on other sites

hey Killjoy i have a small idea.

How about having about 5-6 live guys at east side? (about 1 for each town)

Have them raise in rank and put em on defending towns missions (maybe let em select which town to spawn in, only they cant choose a lost town). Could spice up the game a bit no?

Let's call it Revolution :-))

Share this post


Link to post
Share on other sites

another Idea I had I forgot to post. For realism if the drivers of apc/tanks were restricted to mp5/ak-74u weapons and pilots should only get m9's. maybe helo pilots with mp5s. If they want weapons when they get to where they're going store em in the gear selection of the vehicle. Just sayin cause I can't imagine how you'd drive an abrams with a m240/163 strapped to your back

Share this post


Link to post
Share on other sites
KilJoy,

we played Evolution last week-end (4 then 5 guys in total) on a LAN server.

It took us quiet some time to finish the mission !

Anyway, it was fun but we have some comments about the mission.

Here they are:

Missing features:

* the ability to save the choosen weapon so that we don't have to reselect weapon at each death -- Since people rank up every other death and have new weapons its probably a waste of time

* give points to all pilote, gunners and commander of vehicule for kills. -- Arma bug

* IA should give points to the squad leader when they're doing kill. It's already the case for medic (BTW this seems to be easy to abuse). -- try to abuse it medics only get points for healing enemy inflicted wounds

* mobile respawn point -- then transport points are worthless

* more 5t truck. We need them to move tons of IA (necessary because they can't properly handle bridge) I can add a few more. but it seems to me there always at spawn an noone usses them

Hindrances:

* too much night (we were playing with the 1h = 1 day option): we'd like to attack the 21st of june when the day is the longest possible. -- As far as im aware i did set it to summer solstice for the shortest night. The end date shown is accelerated too for the party (its my birthday 29th july)

* repairing vehicule is far too tedious, especially with trucks having to be refueled. I think giving infinite fuel for the trucks would make if far better. A simple set of truck (fuel, ammo, service) would then be enough to repair vehicules except when they are destroyed by the ennemy. -- they get no fuel to stop people driving them when they respawned damaged.

Bugs:

* the M1A1 gunner gets no points if a commander from a different squad is in the tank-- Arma 6 year old ofp bug.

* points for clearing a city or destroying a secondary objective should be awarded to all players -- only players in the zone get points. people alreddy give out about campers afk in the zone. At least this way they cant get more then 10 points afk.

* Corazol secondary objective destroyed using a vulcan without been noticed by the server (the tower is destroyed but we didn't see the message) -- Yes this is a bug , fixed in next version

* unable to destroy the secondary objective of Bagango (IIRC) -- again fixed next version

@Daemon weapons will be ristricted to class in the realistic version. I want to keep vanila evo more casual. I really want to wait for the ability to change a players model in game before I do this , I would prefer if everyone started out as a normal soldier , then by the second rank they could choose medic or sniper maybe and by 3rd pilot, maybe spec opps ect ect.

Medics do have it hard , but on the upside they get more points for healing if they are of higher rank in the next version. loss of points on death is tricky becuse of weak teamkiller detection in the game.

@Yoma , because of the way the enemy spawn system works It would be hard to just throw in a few human east players. Also all scripting has been designed around west so it would be a lot more work then just plonking in the slots in the editor.

@Kenbow Yeah they give us bicycle helmets but no bicycle's, whats with that?

About the stats thing, would be intersting way to record a players rank for the next session as it might not require an external program to reload the stats. I will look into it.

also

The version 1.5b that is out there is a fake.

because of this the next official version will be 1.5c unless Someone decides to make a fake release of that too. In any case the latest can always be gotten from the first thread. This is getting ridicules

Share this post


Link to post
Share on other sites

KilJoy, i have played this for some time now and there

are some things i think is missing or wrong.

1: The rank system. In RL Pvt´s can drive just anything.

Well maby not Helis but still..in sweden for ex Pvt´s

are both drivers and gunners on the Strv121. And

doing a great job. So i would like Pvt´s beening

able to Drive all Weeled/Tracked vehics. I see

your point in not beeng able to man as gunner.

2: I would like to be able to LOCK vehics, like in RTS4.

That way you could have all vehics respawn. Or even

make them buyeble by POINT system. The more points

and rank, the more vehicles and mtrls to buy. Maby make

them timeconsuming to buy: A MG Humvee let say 30s-

1Min, a T-Truck up to a Rep truck 1-1.5min and so on.

3: I would like to have the option to stash mtrl.

Let say i have a 4WD and im on a mission far up

N Saharani. Its a ambush mission so i need lots

of M136 or satchels. Could be possioble to stash

it in back of the 4WD

4: A penalty system for intentional TK´s.

Ok a guy kills a nother player, but didnt intended

to do so. Fine. But it happens again, again, again

and again. He´s a prick, right. No, if it happens

once or twice its ok. But when he/she kills for

the 3rd time, he/she get droped to Pvt with

NO POINTS at all.

My wishlist for SantaJoy notworthy.gif

Share this post


Link to post
Share on other sites

Aaah, reality...

My personal view is that what has really made this mission a success is that "noobs" cannot join a server and within five minutes taking and destroying all vehicles.

Most 14 year old CS players don't have the stamina to stay on the server long enough to get any rank, therefore it works great. Those that do, usually learn to apreciate their virtual life enough so that they in the process become 14 year old valuable Arma players instead biggrin_o.gif

Share this post


Link to post
Share on other sites

Kiljoy, first thanks for the mission its great! Couple of thoughts, maybe all vehicles should respawn hmmwv would do so in few minutes, but M1A1 like an hour irl and so on...and could there be a version for like 2-10 players meaning little less sla in towns so that it doesnt take an 4 hour battle to conquer one town. I would try to do it my self but can´t unbdo the mission, not take greadit or anything shity, but to do one lighter version for me and my friends to play...

Share this post


Link to post
Share on other sites

First of all I would like to say that this is easily the best mission out there for ArmA, great work!

1: The rank system. In RL Pvt´s can drive just anything.

It can't always be about realism or "that's how it works in real life", concessions have to be made to make it fun to play.

I know I will never be able to convince people on these forums about it, but gameplay trumps realism.

3: I would like to have the option to stash mtrl.

Let say i have a 4WD and im on a mission far up

N Saharani. Its a ambush mission so i need lots

of M136 or satchels. Could be possioble to stash

it in back of the 4WD

... you can? Just take stuff from the ammocrate(s) and place it in whatever vehicle you want, I do this all the time.

4: A penalty system for intentional TK´s.

Ok a guy kills a nother player, but didnt intended

to do so. Fine. But it happens again, again, again

and again. He´s a prick, right. No, if it happens

once or twice its ok. But when he/she kills for

the 3rd time, he/she get droped to Pvt with

NO POINTS at all.

There's no way of detecting intentional TKs, it's even hard to detect TKs at all. Sure you could make a system where someone gets demoted after too many TKs, but the system would be flawed as there are many situations where the killed player was the one responsible for the TK situation. Who here hasn't experienced the "oh I'm gonna run infront of this firing machinegun and hope it'll work out" type situations?

It's better to just use the built-in votekick system to remove undesirable players.

Share this post


Link to post
Share on other sites

KilJoy [sFG], for my and ktotte's cti we also had problem with reloading weapons, this is what ktotte made.

Just start it with:

somewhere init:

frearm = compile loadFile "funcs\rearm.sqf";

then:

[_veh] call frearm;

_veh is the vehicle.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_veh = (_this select 0);

_type = (typeOf _veh);

_hasTurrets = (count (configFile >> "CfgVehicles" >> _type >> "Turrets")) > 0;

{_veh removeMagazine _x;} forEach magazines _veh;

_magazines = if (_hasTurrets) then

{

_ms = [];

for "_i" from 0 to ((count (configFile >> "CfgVehicles" >> _type >> "Turrets")) - 1) do

{

_t = (configFile >> "CfgVehicles" >> _type >> "Turrets") select _i;

_ms = _ms + (getArray (_t >> "magazines"));

};

_ms

}

else

{

_ms = getArray (configFile >> "CfgVehicles" >> _type >> "magazines");

_ms

};

{_veh addMagazine _x} forEach _magazines;

Share this post


Link to post
Share on other sites
KilJoy,

The version 1.5b that is out there is a fake.

because of this the next official version will be 1.5c unless Someone decides to make a fake release of that too. In any case the latest can always be gotten from the first thread. This is getting ridicules

fully agree with KJ so please read below:

i would like ask these who mod KJ mission to use different name scheme than original mission name

so instead

EvolutionV1.5a_.Sara.pbo

use

EvolutionV1.5a_modABC123.Sara.pbo

reason is simple, if two servers use same name of mission with different content and user switch between he downloads this mission EVERY time again ...

result is increased load on server, waste bandwidth on server and time of users ...

i know that KJ prefers noone mod his mission but IF you for some reason DECIDE to mod it, please follow this simple advice ...

same goes for any other mission

thanks

There's no way of detecting intentional TKs, it's even hard to detect TKs at all. Sure you could make a system where someone gets demoted after too many TKs, but the system would be flawed as there are many situations where the killed player was the one responsible for the TK situation. Who here hasn't experienced the "oh I'm gonna run infront of this firing machinegun and hope it'll work out" type situations?

It's better to just use the built-in votekick system to remove undesirable players.

wait for AC framework from MadDogx and his team

that solution helps a lot in most problematic areas ...

Share this post


Link to post
Share on other sites

Heheh...

Well for thouse who knows me, im not your average

14y old CS player...

Im 37y old ArmA player  yay.gif

PS: I tried the stash/drop item. And it works

just fine, thanks..It could be a bit tiresome

though when the vehicle you use respawn to

base mad_o.gif

That seconds my request of buyable vehicles

that you OWN and does not respawn....

Share this post


Link to post
Share on other sites
The thing was Daddls script set the view distance on the server so every1 had that viewdistance if you had a bad or good machine, wheras Kiljoy's script lets each client set there own viewdistance individually.

I'm not a very active player anymore, and on these forums I usually restrict my reading to the offtopic section. Thanks to Lolsav who pointed me here.

Fist a few words on how the script worked:

The principle of the script was very simple. On startup the script determined the 'optimum' view distance based on the result of the benchmark command multiplied with a correction value (depending on the mission a value 0.5 or even lower often was necessary for good performance in OFP and VBS1). Clients did then start broadcasting their local view distance using a specific public variable, while the server started sending his own value in a different public variable.

Basically both - clients and server - were running in a loop, checking their respective public variables for changed values every second (i.e. the server checked the public variable send by the clients and the clients the one sent by the server). If the value was less than their own view distance then they would change their local value to the new, lower setting, and then send their (adjusted value) again. Clients would stop sending once they had received a server answer equal or lower than their original value, while still continuing to listen for further reductions of the view distance. The server would continuously resend his value.

This loop would run for a certain time (about 1-2 minutes) to allow for some desync on mission start, then stop and display the final view distance value as a hint. By then the machines would have been synchronized to the lowest value, thus keeping the game playable and fair for all.

There were a few ways to start the script: you could give a maximum and a minimum view distance (to avoid too low or to high view distances for a given mission setting), and you could choose between a 'high' and a 'low' setting (using a different multiplicator for the original view distance calculation) allowing adjustment by the actual players via the mission parameters.

The view distance script has some problems with ArmA (probably just the changed syntax, maybe something else, don't know). The problem is that I barely find the time to even start ArmA (or other games) lately - scripting anything new or even fixing my old stuff myself is therefore out of question. If anyone feels the urge to fix that for ArmA, then feel free to do so. Just don't start claiming it as your own.

Share this post


Link to post
Share on other sites
The thing was Daddls script set the view distance on the server so every1 had that viewdistance if you had a bad or good machine, wheras Kiljoy's script lets each client set there own viewdistance individually.

I'm not a very active player anymore, and on these forums I usually restrict my reading to the offtopic section. Thanks to Lolsav who pointed me here.

Fist a few words on how the script worked:

The principle of the script was very simple. On startup the script determined the 'optimum' view distance based on the result of the benchmark command multiplied with a correction value (depending on the mission a value 0.5 or even lower often was necessary for good performance in OFP and VBS1). Clients did then start broadcasting their local view distance using a specific public variable, while the server started sending his own value in a different public variable.

Basically both - clients and server - were running in a loop, checking their respective public variables for changed values every second (i.e. the server checked the public variable send by the clients and the clients the one sent by the server). If the value was less than their own view distance then they would change their local value to the new, lower setting, and then send their (adjusted value) again. Clients would stop sending once they had received a server answer equal or lower than their original value, while still continuing to listen for further reductions of the view distance. The server would continuously resend his value.

This loop would run for a certain time (about 1-2 minutes) to allow for some desync on mission start, then stop and display the final view distance value as a hint. By then the machines would have been synchronized to the lowest value, thus keeping the game playable and fair for all.

There were a few ways to start the script: you could give a maximum and a minimum view distance (to avoid too low or to high view distances for a given mission setting), and you could choose between a 'high' and a 'low' setting (using a different multiplicator for the original view distance calculation) allowing adjustment by the actual players via the mission parameters.

The view distance script has some problems with ArmA (probably just the changed syntax, maybe something else, don't know). The problem is that I barely find the time to even start ArmA (or other games) lately - scripting anything new or even fixing my old stuff myself is therefore out of question. If anyone feels the urge to fix that for ArmA, then feel free to do so. Just don't start claiming it as your own.

Glad to see your still around Daddl, you probably know me better as Jim Bond.

I was just trying to explain your script in simple terms :P and that it was set server side, wheras Kiljoy's script is client side is all.

Share this post


Link to post
Share on other sites

Thanks GranQ and Daddl for that info. I would of hoped 1.07 fixed all the reloading problems, but in the beta version at least I know mk19 only gets the current magazine refiled. Dont think I tried turrets yet. Daddl what command specifically did you use to make a benchmark?

RuisRuutu someone mentioned a smaller version before It may happen someday.

Fk Andersson a private may be able to drive one but not assign it to a duty. The ability to drive it represents the command decision to utilize it in a mission. Also there is a form of tk punishment.

I have thought about players locking vecs and allowing players to purchase them for points maybe. But its not top of the list for now. It represents quite a change I think as people would no longer repair taking away the support element which may be rewarded soon and you could end up with 30 cobras in the air and nothing else.

Share this post


Link to post
Share on other sites
@ May 14 2007,00:27)]Daddl  what command specifically did you use to make a benchmark?

The principle was simple, as he explained me back then. At some point we noticed the AI would engage evryone no matter if they could see it or not from far distance. So we got to the conclusion AI would engage if a player could see him, no matter if the others, due to have a lower computer specs, would not.

To make it fair the script would measure the lowest viewdistance of a player connected and apply the viewdistance to all, server included. Of course there was a minimum considered to be the lowest, just because it wouldt be fair to all have 900 meters viewdistance just because one guy. So, if the value was lower it would apply the minimum selected in lobby or in the script. If all players had specs that could allow better viewdistance it would apply a bigger one.

Answering to your direct question: There was no specific command. He used public variables as he stated, to exchange values between clients (users) and the server, to reach and agreement between machines. The final value would result in a public variable. Imagine old days 56k negotiation protocol between pcs to arrive to a connection speed. Even if your modem was a 56ker you would get a 44k or a 52k connection, depending on many variables.

Basically it was a benchmark who measured the capacities of all clients + server and applyed the rule after knowing evryones pcs condition.

Edit: His Webpage backup site is here:

http://joltan.net/daddl.net/

There, on download sections, u can find the latest work he did on that script

Share this post


Link to post
Share on other sites

If you know the answer to this one, pls add your reply. This may be a bug fix for BI, not KJ.

I've personally viewed the success of rearming T-72s, BRDM ATGM, and UAZ AGS30 vehicles next to the US AMMO Truck after my squad repaired and refueled them. However, the Shilka we disabled at and saw the crewmen bail out of at Samato when the warning tones sounded, would not rearm next to the US AMMO Truck when the Shilka's AMMO counter was at 0.

I was operating the guns in the Shilka next to the compound where the smoke stack objective is, and hoped to quit firing before 0, there were many SLA coming to defend the point, but its as if the Shilka fires in bursts of 20 rounds per click, or something close to that burst length. We staved off the counterattack, and have a Shilka on our side, but it has no teeth to bare at this time.

So our team is on the look out for the Ural AMMO as a high priority objective when we cross over at Corazol. Somewhere along the west coast roads, north of Corazol, there are Ural trucks (types unknown) and infantry up there on guard.

I'm still enjoying 1.5a, but look forward to the next rEvolution from you, KJ when the 1.07 patch is available.

~S~,

=dB=Sniper121

Share this post


Link to post
Share on other sites

Daddl script

;negoview.sqs V1.3

;script by Daddldiddl (daddldiddl@gogodot.net)

;idea based on a script by Dinger (dinger@raf303.org)

;----------------------------------------------------

;----------------------------------------------------

;NEGOTIATE THE VIEWDISTANCE IN MP GAMES

;----------------------------------------------------

;----------------------------------------------------

;global variables used:

;DDL_globalserverdistance -> type numerical

;DDL_globalclientdistance -> type numerical

;----------------------------------------------------

;Use in init.sqs: [parameter] exec "negoview.sqs"

;----------------------------------------------------

;Parameter must be numerical. A value of zero will cause the script to determine

;the viewdistance automatically based on the weakest system in the game, while

;higher values can be used to set specific viewdistances (again limited, but at

;a much higher level, by the weakest system).

;Parameter = 0 -> automatic negotiation (low viewdistance)

;Parameter = 1 -> automatic negotiation (high viewdistance)

;Parameter > 1 -> fixed viewdistance (configure in SETUP section below)

;====================================================================

;SETTINGS

;====================================================================

;Use this section to adapt the script to your needs

;Allow iterative viewdistance adaption during negotiation?

_allowImmediateAdapt=true

;Minimum and maximum viewdistances that the program may set.

_mindistance=1000

_maxdistance=5000

;time for the negotiation process - the process is quick, but to avoid problems

;with lag in internet mp games you should use a value of more than 10 seconds.

_maxtime=30

;The factors for the 'high' and 'low' automatic modes. They will be multiplied with

;each machines benchmark. The lowest result will be the viewdistance. This is still

;modified by the _mindistance & _maxdistance settings. Setting these higher than

;0.8 may result in major lag, especially in high-res, high number of object areas

;like Nogova or some towns. Tune to the island and mission you want to use this

;script with.

_highfactor=0.7

_lowfactor=0.35

;Fixed Variables that are higher than the automatic 'high' value will be lowered

;accordingly. This is to prevent missions with high viewdistance settings to become

;unplayable on slower servers or clients.

;====================================================================

;INIT

;====================================================================

_parameter=_this select 0

?(_parameter<0):_parameter=0-_parameter

_endtime=time+_maxtime

_fixedViewdistance=true

_fixedDistance=_parameter

?(_parameter==0):_fixedViewdistance=false;_adaptHigh=false

?(_parameter==1):_fixedViewdistance=false;_adaptHigh=true

_maxlocalviewdistance=_highfactor*benchmark

_minlocalviewdistance=_lowfactor*benchmark

?(_minlocalviewdistance<_mindistance):_minlocalviewdistance=_mindistance

?(_maxlocalviewdistance<_mindistance):_maxlocalviewdistance=_mindistance

?(_fixedDistance<_mindistance):_fixedDistance=_mindistance

?(_minlocalviewdistance>_maxdistance):_minlocalviewdistance=_maxdistance

?(_maxlocalviewdistance>_maxdistance):_maxlocalviewdistance=_maxdistance

?(_fixedDistance>_maxlocalviewdistance):_fixedDistance=_maxlocalviewdistance

?(not(_fixedViewdistance) AND !_adaptHigh):_localviewdistance=_minlocalviewdistance

?(not(_fixedViewdistance) AND _adaptHigh):_localviewdistance=_maxlocalviewdistance

?(_fixedViewdistance):_localviewdistance=_fixedDistance

?(_allowImmediateAdapt):setviewdistance _localviewdistance

_refreshViewdistance=_localviewdistance

~0.01

?(local server):goto "server"

;====================================================================

;CLIENT

;====================================================================

DDL_globalserverdistance=0

@(DDL_globalserverdistance>0)

#clientsendloop

~1

DDL_globalclientdistance=_localviewdistance

publicVariable = "DDL_globalclientdistance"

?(DDL_globalserverdistance>_localviewdistance):goto "clientsendloop"

#clientreceiveloop

~1

?((_refreshViewdistance>DDL_globalserverdistance) AND (_allowImmediateAdapt)):setviewdistance DDL_globalserverdistance

_refreshViewdistance=DDL_globalserverdistance

?(time<_endtime):goto "clientreceiveloop"

goto "end"

#server

;====================================================================

;SERVER

;====================================================================

DDL_globalserverdistance=_localviewdistance

DDL_globalclientdistance=_maxdistance

~1

#serverloop

publicVariable = "DDL_globalserverdistance"

?(DDL_globalclientdistance<DDL_globalserverdistance):DDL_globalserverdistance=DDL_globalclientdistance

~1

?(time<_endtime):goto "serverloop"

#end

;====================================================================

;END

;====================================================================

?not(_allowImmediateAdapt):setviewdistance DDL_globalserverdistance

exit

Share this post


Link to post
Share on other sites

I'd like to see a version where Dead IS Dead. Meaning if you die you start off as a private again.

This could really make for an interesting mission where people are realistically careful when trying to win a campaign.

Share this post


Link to post
Share on other sites

Great job KJ!

I like your mission very much, I hope someday You will give us version with addons smile_o.gif or just switch sides... to play as russian soldiers.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×