RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
Pull request in for A Plot for Life v2.3. Finished testing walls -> walls + doors -> locked doors and back again tonight.
-
Nice work. Looks good.
One small request. How about some comments to help people new to scripting to tell them what is going on where. Comments from others helped a lot when I started ;) .
-
Is it possible to remove the restriction that stops you pushing safes and lockboxes underground? The safes and lockboxes on my server sit almost a full foot off the ground and that's as low as they'll go.
Strange, mine are on the ground or in the ground. The only time they are flying is when I build them on a floor and the floor vanishes (more often than I would like) :) .
Does it not let you move the safe in to the ground or after building does it bounce up or something else.
This mod only deals with ownerships and not placement. Do you have any other mods installed like vector or precise building ?.
-
add "read" (without the "") at the end of the file then run it manually. It should pause at the end so you can see any error messages. Press any key to close it.
That should give you a better idea of what is going wrong.
COuld be a permissions issue fo the account you are using or a number of other things.
-
Yes, DZAI has removed the FreeForAll mode, afaik because of unwanted interactions with other mission systems, e.g. Helipatrols shooting all AI at DZMS missions :-)
Shooting Z's: yes, they don't shoot all of them, but I don't know if that would be ideal, either, using them to protect you, so you can snipe them better ;-)
I don't think there is a 10 group limit, Using the admin tool I can see my 3 heli and 8 vehicle patrols just fine and the groups statically spawning in my vicinity, too. Did you increase the respective heli/car pools? You cannot have more than 1 each if you don't change the default (e.g. ["UH1Y", 1]) of vehicles to choose from.
Vehicle patrols won't chase you in the car once you've succesfully disengaged, in other words: they won't search for you in more as the usual radius used for infantry. But at least in the new version the patrol will re-embark and continue on their way instead of standing just outside the car indefinitely like it was in former versions (where you could fly low over the car, they'd disembark and you needn't concern yourself with them, anymore; same with close driveby).
Shame as the bandit AI on bandit AI interaction prevented ganging up of bandit AI. I found myself in Elektro in the firestation tower and got attacked by bandit AI. Whilst trying to make my way down and trying to carefully get angles on them, 3 more groups arrived and just camped outside the firestation (around 12 AI in all ) until one got me with a headshot. Bandit vs Bandit stopped that and it was an option to turn on and off if needed so it could have been turned off for others with the mentioned ai systems installed.
I would expect zombies to react to them as they would to players and for the AI to shoot the zombies in a XX mtr range. Them running past zombies without any reaction is not great for immersion.
I will check the vehicle pool but from the logs I kept seeing 9 heli patrols, 1 land patrol, 0 (or 1) group. I have both land and heli patrols set to 10. I have now lowered them so there are a max of 10 between them and it seems to be working.
Unfortunately I seem to be disengaging by driving right past them on a road as they do not follow if in land vehicles. I had a heli shooting me all the way down a road. I stopped under a tree, got out with the aim of shooting it down and it vanished. Time between it shooting me last and getting out of the vehicle was 10 seconds max.
The bandits also seem to spawn at the same places at the hight static spawn locations so, for example, If I sit in the control tower with a long range sniper and look west past the hangers of the NE airfield I can usually snipe the AI each time they spawn, usually without them even getting close enough to find me and I am not that good at sniping. THey used to come up the hill to the side of the airfield as well but I have not seen them do that now.
Don't get me wrong, I do like DZAI but just prefered the setup of the older version. If felt more random and real although land patrols didn't chase in the vehicle then either.
Those AI in a little bird with gunz are pretty deadly though. They destroyed the roof of the red barn where I was hiding in Starey one time.
-
I would agree that having the if statements before the compile in the Epoch pbo version of the compiles will simplify a lot and cut down on the need to copy the compiles.sqg mission side with everything in it.
Not so sure on the looped compiles definition from arrays idea. Would probably like to test the practicality (setup , maintenance etc) first.
Personally I would also like to see the blocks of code moved to seperate (or a single functions) sqf file and only called from compiles.sqf. That would make changes easier as the pbo compiles.sqf would not need to be changed in order to change those code blocks.
-
I have been using DZAI for a while and quite liked it. The heli and vehicle patrols were fairly fun and making the bandits hostile to the zombies and each other was great as bandits would shoot at other bandits rather than just keep adding to the ranks of bandits already pinning me down and would shoot at and be chased by zombies which is much better than the zombies just ignoring them and their shots.
I recently upgraded and the switch to make bandits hostile to each other seems to have dissapeared. There also seemed to be a 10 unit limit (heli / vehicle / ai groups combined). Strangely, even though hostile to zombies was on they also tended to ignore zombies for the most part and zombies only chased them after they fired. vehicle patrols (land vehicles) also seem not to give chase in vehicles which is a shame.
Hopefully the new version will fix these items or I may have to look elsewhere.
-
Put the key in your backpack, sell the vehicle, put the key back in your toolbelt (or does it take the key from the backpack as well) ?.
Failing that, have a look at the previous release and the current one with the change you highlighted and see what code was changed. That would be a starting point and you may be able to reverse it.
-
Thanks bud, yeah it's 1440p 6GB file, usually takes a while for youtube to process it, I had to push it asap because it was time to head to work, lol
Haha, that's why my mobile overruns its data usage ;) .
Git is like an octopus... seems pretty simple but the more you start looking at it the more you notice all the different arms and suckers. I am using source tree at the moment which seams reasonible. I stopped using GitHub desktop client a while ago.
I am personally quite interested in the player login chain and FSM files, how they are processed and where they fit in. I have a hankering to amend the zombies fsm as that zig zag running is just annoying :) .
-
Nice info on the order of load. Good to see you are using quality mods for the guide also ;) .
Man you are passionate on the variables and custom compiles.sqf files :D .
I do have a different view with bringing over the custom compiles or variables though if done correctly.
The guide mentions mod makers requiring a copy of the compiles / variables etc which are then amended and an extra line is added to load these amended files as well as the original files in the PBOs. 100% agree this is a bit silly for all the reasons you mention. I was unaware that people were suggesting this but then I use very few mods :) .
ie.
changing
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\variables.sqf";
to
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\variables.sqf"; call compile preprocessFileLineNumbers "customfiles\variables.sqf";
If any files are brought over from the base Epoch PBOs then the lines originally referencing those files in the PBOs should be changed to repoint them to the custom versions. This avoids duplication of code being run at the sacrifice of a larger mission file size.
ie.
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\variables.sqf";
to
call compile preprocessFileLineNumbers "customfiles\variables.sqf";
I like pulling the files over as I know those have been amended, exactly what is being run and that each function / code block is only being defined once. I also find it easier to explain to new server owners how to do this especially as there are numerous guides already out there.
The idea of creating a custom compiles / variables or anything else with only the changes and additions has the advantage of a smaller mission size but anything already defined in the original PBO file that is changed is being defined twice (with the newer version taking precedence). Not a big deal but not overly efficient.
It is just down to the choice between defining the code once but having a larger mission file against a smaller mission file but possibly defining the same functions more than once on server / client startup.
All told though, either of the last two ways work and are reasonably efficient.
TBH for common mod files like variables.txt and compiles.sqf I tend to put them in a custom/init folder to make them seem more mod neutral. A lot of confusion with people wanting to put our mods on the same server was that they would create a custom compiles and link it in to the init.sqf and then chain the SBP compiles off the end (overriding the APfL overrides). If the files from the init pbo folder were placed in a mod neutral init custom folder it may have been clearer although there is no standardisation between mods ;) .
Just one other thing on the variables and init.sqf and variables. I usually explain the variable.txt as defining the base variable values and variables in init.sqf (or elsewhere) as overriding that initial definition, usually to turn features on or off.
Anyway, great video. Thanks for making it and it is always good to learn some new stuff.
-
It is defined as _tent in the original Epoch code as I would guess it was copied originally from the tent_pitch.sqf and added too. Seems no one ever changed it but it does make it a bit counter intuitive for those writing instructions :)
-
Have not heard of that before. Possibly a class file issue or a Public Variable Publish issue.
Check out vault_pitch.sqf
Compare your version with the one up on my Git (link in the first post).
-
Interesting and fairly radical idea. I do like options popping up that I can access with the mouse rather than another key epecially when in combat but could be worth a look.
Probably better taking it to another thread though ;) .
-
There's a lot of repost that are still pending to be merged. After they are added, more testing will be required.
https://github.com/vbawol/DayZ-Epoch/network
@Rimblock - I'll give it a shot once it's merged, but I'm telling you right away - people who work on scripts usually tend to do things "the right way", hence it is hard to find problems. These things are better tested on a field... people are good at breaking them, at least they always find a way, usually with non-traditional methods, lol. P4L same as SBP got a lot of version bumps recently using mission file versions only.
So as long as you feel comfy with your script, it should be fine (plus it's toggleable, right?). I mean .. worst case scenario PBO/mission files (pot/kettle)... quick fixes can be applied to patch up a single file or two if the bug is game breaking, unless configs are used (which they aren't). Best example was 1.0.5 relase with broken config for chainsaws, but you are not using those kind of configs. Any other config file (SBP) can also be fixed within mission file... so there's that :)
I am glad modular build was accepted, this way doing minor fixes mission side will be a breeze, if required.
Yeah, saw there was still quite a list of items to be pulled in.
APfL can be turned on or off but it still affects things either way. The option variable just denotes whether to put the steamID of the owner or the characterID of the owner in the new objects ownerUID variable and what to compare it against for any checks. This means, after it is installed that it will work turned on or off for any items build after the install without any sql or other trickery. Items built before the install will work with it turned off but not with it turned on without some realignment sql or I may build a function.
The test server was made available for people to try it on without needing to do anymore than install the small pbo to their client but it seems less popular than I had hoped. Oh well will do some basic testing on door up/downgrades and the tag refiendly system and that should be fairly good for a simple set of testing.
Yep, the modular building system should make patching a bit easier, for player_build at least. Maybe we should tackle fn_selfactions as that also seems to have grown in to quite a monster ;) .
-
Ah ok. I don't see that link here: https://github.com/vbawol/DayZ-Epoch
Unfortunately as no one seems to be doing any beta testing I am hesitant to push A Plot for Life in to that release, especially with all the other building changes that have been pushed in.
-
Can see how that may be a bit problematic ;) .
Give it a go and let me know if you have any issues.
-
By all accounts it should work fine with both mods. There is nothing to stop it.
I believe they even posted a set of files with A Plot for Life changes included.
The server not starting is most likely due to a typo in server_monitor.sqf.
You could put in diag_log lines at various places and see which one it gets to before the server fails to continue loading.
-
Probably would have been easier to PM me or put a message in my thread for A Plot for Life as I don't always see these seperate threads.
What version of A Plot for Life are you using (v2.2.6 is the latest) ?.
The code you have posted is using th characterID which is not what APfL now uses for buildable ownership. The objects owner is now held in a new object variable called ownerPUID. This can then be compared with the players UID obtained from the command
playerPUID = player getplayerUID;
Then just compare the two.
This should still work with the code you already have if the person building is the owner of the plot pole and is using the same character that built the plot pole (ie they did not die after building the pole but before trying to build the new elevator).
The check for the friendlies is a different matter as the friendlies identifier with APfL installed is their SteamID and this will never be sucessful if compared with a plot poles characterID field (as it is too small to contain the SteamIDs). If you compare the tagfriendlys to the objects ownerPUID it should work though if the owner and the firendly tagged friendly after APfL v2+ was installed.
You should be able to just use lines 22 and the block from line 122 -> 182 from the player_build.sqf on my git for this.
If you should only be able to build near a plot pole then you can put in an exitwith (or change the ne already there) for _IsNearPlot = 0; and then remove lines 144 -> 151 and line 179 as you have already accounted for that check.
-
-
It is probably working fine. The housekeeping side is looking to clear out files that are older than "housekeepafter" and none yet exist so it reports no files found. Just make sure there are files being created and that they have sql commands inside (ther will be the sql to completely recreated the DB Instance you have requested backup of).
-
Looks like you have the precise building mod installed. That is how the worldspace variables are stored with that mod and mine both installed.
Check your server_monitor.sqf for any typos as that is the sort of thing which will stop the server starting correctly.
-
oh look a server running with signatures on 0 :D
_kiell = nearestObjects [player, [], 15000]; { _x setDamage 1; }forEach _kiell;:ph34r: :ph34r: :ph34r: :ph34r: :ph34r:
Sure can but it is a test server for testing functionality not persistence. The objects being destroyed is very meh... Only people here will have the password (not great security but stops opportune server browsers). If it becomes an issue then I will remove it.
No one is connecting and no one is indicating that they are interested in doing any testing so I guess the bugs will come out after 1.0.5.2 release like they did after v2 PfL was released as no one seemed to do any beta testing on that either when the beta was released.
-
To help people who want to test I am making a test server available.
Details in the first post.
-
I do have an undefined variable in the fn_selfactions but its related to a vehicle animation, unfortunately no other errors report themselves in the client or server rpt.
The building modifications (PP4L, SBP, Vector and Precise) all seem to be working as intended with no errors. Will revert the safe changes back to your latest and see if they pop an error.
The problem with undefined variables is that they may have been defined somewhere above but a missing ";" or some other problem has caused that part of the code to not run correctly. This means a variable has not be defined but some other knockon may also be happening. I have also seen some issues not reported in the RPT files (from the server_monitor.sqf IIRC). I would track down where the variable should be defined in that file and try to work out why it is not working (unless it is an error as there is nowhere the variable has been defined which also sometimes happens).
I like Notepad++ as if I highlight a word in the file it highlights all the other instances of that word in the same file.
Hey Rimblock,
I tried looking but 28 pages is a lot so I will just ask. Some of my players are reporting that they cannot lock their safes after opening them. They are also reporting that their safes are wiped the next day. Any ideas?
Check you have amended the player_lockvault.sqf and compare it to the one on my Git (https://github.com/RimBlock/Epoch/blob/master/A%20Plot%20for%20Life/V2.2/MPMission%20Files/Custom/PlotForLifev2/player_lockVault.sqf). Looks like the instructions for amending the files may have also missed this one.
Safe wipes are being reported in various threads on the Epoch forums and the Epoch Git has an issue raised for it here. I have not seen it myself however.
[RELEASE] Shared Plot Poles
in A2: Epoch Mods (1.0.5.1)
Posted
Nice. I was thinking of doing the same sort of thing at a later date. Glad someone else has done it first :) .
Just a heads up that the build system will be changing quite a bit for Epoch 1.0.5.2 when it comes out so you may want to take a look at the Epoch Git. A Plot for life should be included (although turned off by default).