dreadpirate
-
Content Count
537 -
Joined
-
Last visited
-
Medals
Posts posted by dreadpirate
-
-
v1.41 (2017/12/29)
- Stopped units moving to default spawn position when using RESPAWNMARKERS
Download
Installing to a sub-folder
- Copy the jebus folder into your mission sub-folder (eg scripts)
- Copy description.ext into your mission folder (or merge description.ext with yours)
- Edit description.ext to point to sub-folder (eg #include "scripts\jebus\cfgFunctions.hpp")
- Proceed as normal
On 06/10/2017 at 10:25 PM, katipo66 said:Does the caching remove units from the memory to save on performance or just hide them?
Also if I had one request it would be nice if the system could remember a units probability of prescence.
Otherwise this is a another great system for mission making.
It just hides them and disables simulation, which does provide a small performance boost.
Not quite sure what you mean by probability of presence. Perhaps give an example of how you would like it to work.....
-
2
-
1
-
v1.40 (2017/10/2)
- Moved JEBUS into its own folder. Reorganised code
- Dynamic Loadout support
- "START=" added. Initial spawning delay
- Multi vehicle groups support RESPAWNMARKERS
- Various tweaks and fixes
Download
I've turned JEBUS into a function, so the setup will change slightly.
Instead of
0 = [this] execVM "Jebus.sqf";
it will be
0 = [this] spawn jebus_fnc_main;
-
2
-
On 16/08/2017 at 3:34 PM, anfo said:Hi Dread
What would you think if something in this code is preventing CACHE and REDUCE from working in MP?
waitUntil {!isNull player}; [] execVM "scripts\briefing.sqf"; [] execVM "scripts\aide_memoir.sqf";In SP/Editor the AI will CACHE and/or REDUCE, but not in MP. All other parameters seem to work ok.
Are we talking about a dedicated server here? Because "player" doesn't exist on a dedicated server, so that code will never execute.
I think something similar might be affecting CACHE and REDUCE. They both use the scripting command playableUnits. Maybe it doesn't work the same on dedicated as it does on a listen server (where I do all my testing)?
I might try switching it to allPlayers and see if it makes a difference
-
On 22/07/2017 at 11:18 AM, anfo said:Hey Dread
If you were being paid for this I reckon I'm making you earn it!
(and you're probably still not earning enough)
Another question or maybe a feasibility case. As you would imagine I try to limit FPS drops on the dedicated server wherever possible and it appears that spawning many enemy groups at once can contribute to performance loss.
Take for example I have 5 groups of enemies that are syncronised to one trigger. They all obviously spawn once the connected trigger fires and possibly impacts the server at that one moment. Of course I could put in 5 separate triggers with different countdowns, but I feel suddenly we have a messy editor situation with triggers lying on triggers.
What is the chance a new variable could be added called "START="? The objective of the the new start variable (or whatever it might end up being called), is to define the initial spawn delay of the unit or group. This is contrary to "DELAY=" which controls subsequent spawns if applicable to the unit. The hope is the load of spawning could be spread out with varying start values and hopefully reduce performance loss and help manage the editing process.
It's not the end of the world if this is an unreachable objective and I'm happy using (and continually learning) about Jebus and what it achieves for our clan games.
Anfo
Hi @anfo,
I will implement "START=" in the next version of JEBUS because I can see your point about server lag when multiple groups spawn at once.
I was hoping the next version would involve a comprehensive clean up of the code and implement some new features, but I may just make a quick release for now and work on more ambitious things when I have more time.
-
18 hours ago, anfo said:Hi Dread
Can I pick your brain again please mate?
Say recent enemy mortar fire have got all the AI in the immediate area spooked and unable or unwilling to follow waypoints etc. I was trying to introduce a "calm" spawned AI that would immediately be SAFE and would follow waypoints as set. It seems however that even after the mortars have fallen, the new spawned AI will "inherit" the mood of his fellow AI and be generally uncooperative and combat ready.
Any known way to overcome this?
I've noticed this as well and it's strange because a group respawned by JEBUS is a completely new group and should have no prior knowledge.
Are you running any AI scripts / mods? Maybe they are being alerted by other groups?
-
6 hours ago, f2k sel said:Once they start moving it sees to default back to normal and looking North for the most part, it should be no different than using the can method at least.
If you need them to look a certain way at various waypoints then use setformdir in that waypoint.
I'll give it a try. Thanks for your input.
-
41 minutes ago, f2k sel said:You could move the dowatch to the jebus.sqf file and do away with the can.
//Spawn infantry // _tmpGroup = [_tmpRespawnPos, _unitSide, _infantryList] call BIS_fnc_spawnGroup; sleep 0.1; { _x setdir _respawndir; _x dowatch (_x modelToWorld [0,10,0]); _x setUnitLoadout (_infantryInventoryList select _forEachIndex); _x setSkill (_infantrySkillList select _forEachIndex); sleep 0.1; } forEach (units _tmpGroup); (units _tmpGroup) joinSilent _newGroup;It seems to work for me in simple test.
Interesting, but what happens to units that are supposed to head out on patrol? Will they continually turn to face that position?
-
46 minutes ago, anfo said:Hi Dread
Another curiosity for you
The frustrating part about this is that JEBUS already uses both setDir and setFormDir internally to try and get units facing where they should but to no avail.....
But, as usual, I have a sneaky workaround that has the desired effect:
- Place a small object, like a can, in the direction you want the unit to face and give it a variable name (eg. can).
- Go into Special States for the can, enable "Simple Object" and disable "Show Model" and "Enable Damage".
- 0 = [this, "INIT=", "_proxyThis doWatch can"] execVM "Jebus.sqf";
Obviously this is a pain if you have tons of units but it works.
I also recall there being an Arma 2 script that made a unit scan a specified sector, say 45 to 135 degrees, I wonder if that still works in A3?
-
People complained that multi-vehicle groups were a nightmare with JEBUS (collisions, running over infantry, etc.), so I made vehicles respawn at their editor positions only.
So, yes, currently RESPAWNMARKERS only works for infantry.
But, you're right, I should revisit this problem and find a way to spread out vehicle respawns so they can use RESPAWNMARKERS.....
-
Do you have the following line in your init.sqf?
call compile preprocessFileLineNumbers "JebusInit.sqf";Do you have JebusInit.sqf in your mission folder?
Those are the most likely causes for this error.
Hope this helps.....
-
On 6/23/2017 at 0:58 PM, anfo said:G'day Dread
I'm probably asking a bit too much here, but I have a CQB scenario which I would like to use Jebus to respawn live targets within. The area is just shoot house walls on a flat ground, however when the units respawn they "sometimes" spawn away from their wanted locations (outside facility). They are not grouped so formations are not affecting them, but they are spawning with disableai "move".
Is there anything that can be done to spawn exactly where they're required? Again, probably a big ask I know. As they say, don't ask, don't get! ;)
What you could do is something like:
0 = [this, "INIT=", "_proxyThis setPos [1000,2000,10], _proxyThis disableAI 'PATH' "] execVM "Jebus.sqf";where [1000,2000,10] is copied over from the x, y and z coordinates in the editor.
Also, use disableAI 'PATH' rather than 'MOVE' because:
https://community.bistudio.com/wiki/disableAI
-
3
-
-
A possible issue is that _proxyThis only refers to the leader of the group, so to run it on all members of a group you need to do something like this:
0 = [this, "Lives", 3, "INIT=", "{[_x] execVM 'Units\Equipment\RandomGearNatoRifleman.sqf'} forEach units (group _proxyThis)", "GAIA_NOFOLLOW=", "1_1"] execVM "Jebus.sqf";In fact, if you look at the demo mission, I have a similar script running on a group patrolling the radio tower West of Kamino.
It seems to work ok, although I've never actually verified that the woodland texture can be seen by others in MP.....
-
Post your JEBUS init and how the retexture script is normally called and maybe I can help you out.
-
On 6/6/2017 at 9:59 PM, sarogahtyp said:Hey @dreadpirate ,
i am currently working on the same thingt on a very similar project (look at sig). I had an error with it but I found a solution to save, delete and restore objects with there editor names. Basicly it works like shown in the following pseudo functions:
fnc_get_editor_var = { params ["_object"]; (vehicleVarName _object) }; fnc_delete_obj = { params ["_object"]; _object setVehicleVarName ""; deleteVehicle _object; }; fnc_spawn_obj = { params ["_object", "_name"]; if(_name isEqualTo "") exitWith{}; missionNamespace setVariable [ _name, _object, true]; [_object, _name] remoteExec ["setVehicleVarName", 0, _object]; };
I hope this helps to get it working for ur project. Just ask if u ve questions with it.
Thanks @sarogahtyp, I had a quick look at your script and it looks way more professional than my humble effort.
I suppose mine started as a very simple respawning script that has had more features tacked on over time, whereas yours has a smooth overall design and structure.
-
1
-
-
Hi @anfo
The issue is that JEBUS doesn't save editor variable names. I vaguely remember trying to add this feature and having problems with it. Maybe it's time to attack the problem with fresh eyes.
In the meantime, you can change the code in your waypoint to the following:
{deleteVehicle (vehicle _x); deleteVehicle _x} forEach thisList;.....which will delete all vehicles and all units in the group when it hits the waypoint.
One wrinkle I discovered when testing this is that you need to place at least one other waypoint between the spawn position and the delete position, or sometimes the group gets deleted instantly at the spawn position.
Yes, only sometimes.....
-
Notice the objects in the background disappearing and reappearing.
I've observed this happening with other CUP buildings, but this lighthouse is the worst offender.
Is this happening for anyone else? Is there a graphics setting I need to change?
Or should I go ahead and create a ticket?
-
10 hours ago, anfo said:Hi Dread
Couple of easy questions I hope
Q1.
I'd like to try UPS some more in upcoming missions but I'm slightly confused. Can you please explain the difference between what is on post 1 of your thread:
0 = [this, "PAUSE=, 100, "INIT=", "[_proxyThis, 'agia] execVM 'UPS.sqf'"] execVM "Jebus.sqf";and this code in your example Stratis mission:
0 = [this,"INIT=","[_proxyThis,'11'] execVM 'scripts\upsmon.sqf'"] execVM "Jebus.sqf";Is there a simple distinction between script UPS.sqf and UPSMON.sqf that makes it easier to know which one is best for my needs?
UPSMON is based on UPS, but has additional features and tweaks, so try both and see which you prefer.
10 hours ago, anfo said:Q2.
From your example mission:
0 = [this, "DELAY=", 10, "GAIA_NOFOLLOW=", "9", "RESPAWNMARKERS=", ["m1", "m2"]] execVM "Jebus.sqf";Are the m1, m2 markers supposed to be hidden by the script? The reason I ask is that they stay visible in preview.
The script doesn't hide the markers. Use the empty markers for an actual mission. Markers -> System -> Empty
-
1 hour ago, gatordev said:Finally had time to sit down and add this to a mission. Thank you very much for keeping this updated. I use this with UPS and seems to be working well except I can't figure out how to get the AI patrol to patrol in Safe mode. They keep wanting to run around in their patrol area.
I tried setting the group to Safe and I also added on single waypoint with Safe set, but still having the issue. Any ideas?
The issue seems to be UPS being too "sensitive". I've had civilians and even supposedly-invisible Zeus units trip them out of Safe mode.
If you observe from a long distance, they do walk as expected.
-
v1.39 (2017/3/10)
- Skill levels are saved
- Various tweaks and fixes
Download
I think I've resolved the "units being crushed by their own vehicle" issue, but test it out and let me know.
2 hours ago, MitchyG117 said:Great script Im loving it. Only thing I want to bring up is that the PAUSE feature isnt working properly for me, I may be typing the code wrong, but I dont want units to respawn if enemies are within 150m, and when I type "0 = [This, "PAUSE=", 150,"] it does nothing, they still spawn. And I dont want to use the UPS script as shown in the examples so i cant use that example
I tested out PAUSE while updating the script and it's working on my end.
0 = [this, "PAUSE=", 150] execVM "Jebus.sqf";
-
7 hours ago, owmyeye said:I've noticed that groups are present when the game starts, but quickly de-spawn and re-spawn back in place. In the process of this, I know they keep waypoints and etc, but do they keep the attributes set such as Skill?
I started having a play test of the scenario I've spent heaps of time making, but I keep getting cut to ribbons from long range fire. It's return of the aimbot, the same age old ARMA 3 issue. However I'm running Bcombat and normally with the unit Skill level set to the lowest level it makes the game playable.
Is this Skill setting wiped by Jebus?
Also another thing to do with despawning units on start. I don't know if it has anything to do with using RHS, but when I have a number of units start in a vehicle, when they all respawn half of them get killed mid way through the process. It's like they spawn under the vehicle or something. I've seen it happen for GAZ cars and for T-90 tanks.
You're right, JEBUS doesn't save skill levels. You can set them via "INIT=" for now, but I'll include this in the next version.
Hmmm, I thought I had solved the problem of units being crushed by their vehicle at spawn. It is supposed to freeze the vehicle until all the crew and passengers are inside. You can look for the line in the script where it says waitUntil (sorry, I'm not at my A3 computer right now, so I can't give the exact code) and add a sleep 2 after it.
I'll have a look at these issues when I get a chance, hopefully tonight.
-
1
-
-
1 hour ago, owmyeye said:I want to respawn a group exclusively in a position not where they are placed in the editor.
This is because I want the re-spawned group to travel to the location as though they are actually reinforcements, not just magically appear on the spot.
From the description of the config I see "RESPAWNMARKERS=" allows you to pick an array of markers, but it sounds like every marker placed will share an equal chance along with the editor placed position.
Is this correct? Is there any way to exclusively respawn at a marker location?
You could place the group in the editor where you want the reinforcements to come from and send them to their patrol location with waypoints or a patrol script (GAIA, UPS, UPSMON, etc.).
You could sync the group to a trigger if you only want the reinforcements to come when a certain condition is met (EAST NOT PRESENT for example.....).
-
13 minutes ago, ayoung said:Hi Dread. Thanks for the update. I really like the way you have the vehicles spawn now. Only thing I saw was that in your demo mission upsmon takes awhile to start its patrol. Like a few minutes. Is this how its suppose to be?
GAIA can take 20 - 30 seconds to kick in, but UPSMON seemed to start straight away for me.....
Not sure what could be causing that, the script is called within seconds of the units spawning in.....
-
3 minutes ago, orllak32 said:Hi!
I am new to ARMA 3 and this forum ,and I need some help!
I have properly installed the police mod,but I don't know how to launch it?
Could someone please help me to launch the mod?
Thanks in advance!
Best regards!
-
1
-
-
21 hours ago, Imperator[TFD] said:Super keen!!
Had a mission with 24 human players last night in our unit and it utilised your JEBUS script and the guys had a total blast so thanks. Makes missions so much more interesting.
If you're ever keen to join in gimmie a shout.
I'm not really an ACE guy, I'm sure I'd just slow you down while learning the ropes. Let me know if the new version helps with performance.
Do you need reducing that works with vehicles? Because that was giving me a real headache, collisions and what not, which is why I released it as it was.....
2 hours ago, WurschtBanane said:Hi, its me again.
Im spawning a plane via a trigger with your script. That works so far.
But then i have been trying to synchronize it to a trigger location module in order to make the trigger be "on top" of it all the time. I also want to give it a name so that i can have a trigger that checks if the plane is alive or not.
But the module does not get synched and i get weird error messages saying that ; is missing.
I also have no idea how to give it a variable name, as the editor one gets deleted when it respawns.
0 = [this, "LIVES=", [1,1], "FLYING", "INIT=", "T = [vehicle _proxyThis] synchronizeObjectsAdd [task4loc]"] execVM "scripts\Jebus.sqf";
If your plane only has one life, why do you even need JEBUS?
You can hide and disable simulation on the plane in the editor. Look under Objects: Special States.
Then you can activate it via trigger. Just put:
b1 enableSimulationGlobal true; b1 hideObject false;
in the "On Activation" field.
That way, you can set up everything in the editor without even needing JEBUS.
-
1
-
ALiVE - Advanced Light Infantry Virtual Environment 1.0 (GA)
in ARMA 3 - ADDONS & MODS: COMPLETE
Posted
So I was playing around with the IED system and I made a few notes:
Also, if I don't sync the IED module to the Asymmetric Commander, there will be IEDs on the map at mission start, but once I've cleared them all, the insurgents will not plant new ones. Is that right?
Anyway, I'm really enjoying exploring everything ALIVE has to offer. Amazing system.....