RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
Locked doors have no ownership recorded as the characterID field is used for the door lock code.
If you install a mod like my A Plot for Life (see my sig for the link) or one of the other mods that allow you to keep ownership after character death then you should be able to work around that.
As Epoch 1.0.5.2 should (pull request awaiting merge) be having A Plot for Life included (can be turned on or off) and APfL stores the ownership details of the player regardless of whether it is turned on or not, it should be pretty easy to link owned items back to their owner.
-
Thanks for you work on this. Gonna try it out tomorrow. I think i did find a typo should you so wish to correct it
in player_unlockVault note the extra semicolin.
_characterID = _obj getVariable["CharacterID","0"];
_ownerID = _obj getVariable["ownerPUID","0"];;
Thanks for letting me know. I shall amend and re-upload the file tonight.
-
Ok, seems like the take ownership is working.
Have also functionised the ownership and friendlies check (provide owner object to check for , provide object whos ownership you want to check and it returns is owner true/false, is friendly true/false).
Also works with or without A Plot for Life installed. Will be adding it to the pull request to get A Plot for Life in to Epoch 1.0.5.2. Just need to finalise some cross ownership testing. I may also offer it as an addon for plot poles in 1.0.5.1.
Lockables and tents cannot have their ownership changed by default although this can be overwritten if desired.
-
Just an update. I am currently working on the "Take Ownership of items" option for the plot pole which will grant the pole owner the right to own all buildables on their plot.
I will possibly include an exclusions variable so safes are ignored, for example.
My new "Show / remove" plot boundary is working although not with the original plot markers. I have been testing with road cones ;) , which are ok but fall over if on a hill :) . The lights seem to work of a fashion. I have each cone with a flashing light attached but suspect I have hit an issue with the number of light sources that can be displayed at any one time which is a shame. A partial ring of flashing road cones looks quite nice. A full ring would be great, although probably not do much good for the server performance :P ...
I can change it to coloured balls easily (without light sources). If anyone has any other object suggestions then let me know (fire barrels would be cool but the light source restriction would probably play a part again and they would give an advantage as they could be used for other purposes without having to buy them).
-
SBP & APfL have the player_build.sqf in common.
If you add Plot Management then just about all the building related files need to be updated as Plot Management check the plot pole on ownership checks rather than friendlies.
-
_tmpbuilt setVariable ["CharacterID",dayz_characterID,true];_tmpbuilt setVariable ["CharacterID",_combination,true];PVDZE_obj_Publish = [_combination,_tmpbuilt,[_dir,_location],_classname];PVDZE_obj_Publish = [dayz_characterID,_tmpbuilt,[_dir,_location],_classname];
---------------------------------
I followed the instructions to the letter and everything looks ok. I need some help please :)
When searching, try changing _tmpbuilt to _object in those 4 lines.
-
Well the file with the error listed is mpmissions\__CUR_MP.Tavi\Custom\Elevator\elevator_init.sqf
If there is an error in that file then it usually stops anything else processing after the error which is likely to cause issues.
I would suggest sorting that one out first.
Have you defined the s_player_elevator_next variable in the variables.sqf file so it is global ?.
-
Sorry man, don't use Infinistar so canot really help you there.
Hopefully someone else who does can help you with its configuration.
-
Cool. Np.
Little update...
I have spent a bit of time working on the plot boundary markers and have created the ability to turn on and off the plot markers from the plot pole. The downside is that this seems not to be possible for the current plot sticks as nearestObjects cannot see them (suspect something to do with the config files for them).
To this end I have changed the objects to road cones which works quite well although they are collision aware so can be hit / knocked out of place / fall over etc. Another option would be coloured balls like those used in Snap Build Pro (thanks Raymix for sharing the code). In theory anything can be used and I have even thought about using barrels. Having a number of fire barrels lit around the plot site at night would probably look pretty good but we need to be mindfull of the impact to the engine and possible free advantage some items may give players.
What I will probably do is setup the plot marker as a variable along with some recommended class names for them. Obviously some objects will be just silly but it is up to the server owners to decide what they would like to use. I will also add in a variable for frequency to enable people to have larger gaps between markers.
When created, the plot markers have ppMarker put in their inventory and on removal, all items matching the markers defined object class are checked to see if they have ppMarker in their inventory before removal. THis should stop removal of any items of the same class on the plot that are not part of the plot marker ring.
------
Update: Have found a few example of lightpoint scriots which may enable me to make flashing lights on to of the road cones (for example). I may even do a funky disco light show just for fun and set a variable so server owners can choose to turn it on or not, maybe for admin events, or even give the option to admins so they can turn it on from any plot pole.
Will finalise the code, get it up on GitHub and package a release. The code should be pretty simple to implement.
Oh and for those asking why I am bothering with this....
1. Technical exercise and to see what can be done with lights.
2. As a warm up for a 'Take ownership' option on the plot pole for plot owners. A number of the methods used for this will be used for that function as well.
-
custom compiles redirecting fn_selfactions.sqf to a mission side copy. The mission side copy of fn_selfactions then redirects the remove.sqf to a mission side version.
-
I have not edited the file it says there is an error with, not sure why it's giving me this? Could anyone help please?
This is what my report file says for all the vehicles on my server:
5:15:06 "Deleting object JetSkiYanahui_Case_Yellow with invalid ID at pos [14700.8,9810.27,176.458]" 5:15:06 "Deleting object SUV_Red with invalid ID at pos [9875.82,10318.6,0.029007]" 5:15:06 "Deleting object SUV_Red with invalid ID at pos [9875.82,10318.6,0.0523376]" 5:15:07 "Deleting object PBX with invalid ID at pos [13636.8,7795.63,64.106]" 5:15:07 "Deleting object Mi17_DZE with invalid ID at pos [4870.91,4752.14,0.53125]" 5:15:18 Error in expression <teWest && !(locked _object)) then { if (_objectID == "0" && _uid == "0") then { > 5:15:18 Error position: <_objectID == "0" && _uid == "0") then { > 5:15:18 Error Undefined variable in expression: _objectid 5:15:18 File z\addons\dayz_server\compile\server_updateObject.sqf, line 29 5:15:18 Error in expression <ntory; }; case "damage": { if ( (time - _lastUpdate) > 5) then { call _object_da> 5:15:18 Error position: <_lastUpdate) > 5) then { call _object_da> 5:15:18 Error Undefined variable in expression: _lastupdate 5:15:18 File z\addons\dayz_server\compile\server_updateObject.sqf, line 174 5:15:18 Error in expression <iable ["ObjectUID","0"]; if ((typeName _objectID != "string") || (typeName _uid> 5:15:18 Error position: <_objectID != "string") || (typeName _uid> 5:15:18 Error Undefined variable in expression: _objectid 5:15:18 File z\addons\dayz_server\compile\server_updateObject.sqf, line 21Check out your server_monitor.sqf. Sounds like it is not sending object details to the server_updateObject.sqf function.
Everything is working ok for me only problem i do have is with the mod to turn on plot pole markers.
They work fine only the option does not get removed from the scroll menu even when your not near the plot pole
Funnily enough I have been looking at this today. Trying to find a way to turn them off on demand as well as on. Still a WIP but for the menu item not disappearing.
Open fn_damageactions.sqf
Find
} else { //EngineeringChange to
} else { //Engineering player removeAction s_player_plot_boundary; s_player_plot_boundary = -1;Give that a try. Not tested but may well fix the problem.
-
See, I knew I was skipping something, I completely forgot that special variables are passed. Cheers bud.
:) . If you take a look back in the thread, you will see it took me a bit to work that one out as well.
From the Wiki on addaction
- Parameters array passed to the script upon activation in _this variable is: [target, caller, ID, arguments]
- target (_this select 0): Object - the object which the action is assigned to
- caller (_this select 1): Object - the unit that activated the action
- ID (_this select 2): Number - ID of the activated action (same as ID returned by addAction)
- arguments (_this select 3): Anything - arguments given to the script if you are using the extended syntax
-
Yeah the instructions are geared solely towards plot for life just now. I did already say he'll need to add in alternates to some of the instruction stages like I had on my page for people not running plot for life.
The function of the mod (allowing players to build with friends even after death) is actually a founding principle of creating it, at least it was for me. So it's pretty much the intended behaviour and anything less wouldn't be worth having haha. It is mentioned in the first line of the OP that players with "ALWAYS" have access to build even after death, until they are removed.
The up side to this though, is that the plot owner (or somebody they've added) has to manually add the person, it doesn't happen automatically when they befriend them. They have to consciously go to the pole and select to add that player and it will then display that persons name on the list of people who have build rights. So it's easier to keep track of who can build on your plot than just basing it from the friendly system where you can easily lose track of who you have and haven't befriended.
Back when I worked on base building 1.3, having the option to create a base around one pole with multiple people 'owning' it was a key principle and that's what I originally set out to do with this too. I know myself and my friends who play on our server all build together, and we've got a few other players who come on together and all like to build together and it gets annoying if you can't build because the person who placed the pole is offline. It's probably not suitable for all servers I'd guess though, but at the end of the day a player shouldn't give somebody else access to build on their plot unless they trust them.
Sure, just with the statement on the first page saying A Plot for Life is not required, it seems a little confusing. I did see the comment on your original thread which is why I was a little surprised.
The concept is good. Just suggesting making the downsides or functionality a little clearer. Some may not realise that "always" also means after death (i know, i know but it may not occur to some).
Sure people should not add them unless they trust them but then people are people and don't always do what would seem to be the most logical thing. The off shoot is that the admins will probably have to deal with any griefing so it is probably worth letting them know before they install it that this feature of Epoch vanilla has also been changed.
A suggestion to help mitigate the open build policy for PlotPals...
How about setting a couple more variables.
PlotCanBuild (Covers the whole plot for everyone).
PlotPalCanBuild (Covers individual builders enabling individual builders rights to build to be turned on or off).
Would be easy to store them in the inventory field
[PlotCanBuild],[[steamID], [buildername], [Canbuild]]
Amend the gui with two more buttons, one for changing the PlotPals build rights and one to change the whole plots build rights for all (only changeable by the plot pole owner and admins). Would add much greater control and granularity to build rights on the plot and should be pretty easy to implement.
-
Hi Guys,
Where are you setting "ownerPUID" ?. I only see getvariable for it, no setvariable. I assign this variable in my A Plot for Life mod but if this mod is independant of it (i.e. from the first page "If you dont use plotForLife mod and you add yourself to the plot, you will alwyas be able to build even after you die.") where are you setting it on object load and what are you setting it with (CharacterID / SteamID) ?.
A couple of points you may also want to make people aware of (fore warned is fore armed and all that)...
If this mod is installed then player will be able to build on the plot if they are a PlotPal after their death. Some server owners don't particularly want this (hence my mod not being everywhere and the reason VBAwol asked me to optionise it for the inclusion in to the Epoch base code).
Probably also worth making Server owners aware of the potential downsides of allowing PlotPals unrestricted build rights on their plot when they are not there. I suspect the requirement to look at the plot owner before you can build on the plot was put in there to stop people befriending the plot owner then griefing their plot whilst the owner was away. Taking that restriction out may open the doors to this sort of behavior again. Considering the amount of work server admins may have to do trying to get peoples bases un-griefed it would probably be worth letting them know the risk. Judicious management of who to add will of course help to mitigate this a lot though.
Nice mod. Plot builder maintenance from the plot pole makes more sense than the tag friendly system.
-
Just got the email from BI, just lightened my bank account.
Yep you can only buy for Steam accounts you can login to.
-
That, right there, is fucking genius.
Only "downside", if you could call it that, is that it would require changing ALL the calls throughout the Epoch code though. With that said, if it has a significant performance increase, it'd be worth it.
I volunteer Maca to test it out and report back to us :D
Test it out for mission based compiles and leave the main compiles with the original sugestion of "if not then compile each item". If that works fine then just move them over a bit at a time. Just deal with the custom compiles and main compiles first then scan through for other compiles in scattered files at a later time.
Framework for mod makers
Move core compiles on to it
Look at anything else
Makes it a bit more manageable (and easier to debug should something go wrong).
-
I see one or two small pulls got merged yesterday so stuff is still being added.
Personally I think they need to set a cutoff point ofr items to be included in 1.0.5.2 or there is never going to be a pool of calm for testing pre release before the storm of bugs post release ;) .
-
AI-to-AI hostility:
This was option that I really did not want to remove because it was my only answer/compromise to people who wanted friendly AI. This option was only viable when the only AI system you used on your server was DZAI. However, the scripting command that DZAI uses for AI-to-AI hostility affects the entire server. So every AI spawned by the server would become hostile to each other, and this would be a massive problem for people with AI missions installed.
AI-to-Zombie hostility:
AI-to-Zombie hostility requires use of the client-side addon as the warning above the setting states, otherwise you'll never see AI shooting zombies. The reason is that the player's client needs to do the work that makes the AI recognize zombies. Older versions of DZAI did everything on the server but that was extremely unreliable.
AI Vehicle chasing:
This is completely impossible to my knowledge. 99% of AI behavior in DZAI is controlled by the default Arma 2 AI, and the default behavior dictates that vehicle AI passengers disembark whenever they spot enemies to engage. No other DayZ AI system supports passenger units to my knowledge so that's why you don't see the same thing happen in other addons. If you don't want AI to exit their vehicles when they spot an enemy, consider using only armed vehicles with no passenger (cargo) units.
AI pathing:
You can adjust the patrol paths yourself if you just move the spawn area markers for the static spawns. The folder you would be looking for is in world_spawn_configs/spawn_areas.
Dynamic AI spawn system
Mostly a response to fr1nk: Do you have any specific dislikes about the current system or preferences about the old system? The old system was actually a lot less random as the spawns tended to concentrate towards the center of the map and never reached the coastal areas. For Chernarus servers, you would have Stary constantly under assault by dynamic AI, which was doubly problematic if the server was also running Epoch.
Because the dynamic spawn locations were predetermined, a very lucky person could manage to travel in between all the spawn areas and never be ambushed by dynamic AI. On the other hand, a very unlucky person could run smack into every dynamic spawn as they traveled from Point A to Point B. A person who just sat around AFK all day on an open field could probably never encounter any dynamic AI. Sometimes, the dynamic spawn areas would be bunched up together in clusters, leaving a huge portion of the map without any dynamic AI spawns. From my point of view, this old system was extremely not random.
I designed the new dynamic spawn system to deal with these issues of non-randomness. Instead of users walking themselves into an area to trigger a dynamic AI spawn, DZAI would choose a handful of players that haven't recently been targets, then create a dynamic AI spawn area around the player. Players who've recently been targets would have less chance of being targeted, while players who haven't been targeted in a while (or ever) would "accumulate" a % chance to be targeted. This was the equalizer that would ensure all players would encounter dynamic AI.
To the OP (original poster):
The AI in that video is most definitely DZAI.
And DZAI does have true roaming AI - air and land vehicle AI that never despawns. Only infantry AI are despawned when nobody is around. DZAI's philosophy is that "if a tree falls in a forest and nobody's around to hear it, it doesn't make a sound".
Thanks for the detailed reply.
I should really define what I mean by previous version. THe first version I tried was the one where the random spawn points were amended so they were not generated overlapping each other.
AI-to-AI hostility:. IIRC this was a configable option in the settings for DZAI. Did it not completely turn off ?.
AI-to-Zombie hostility: Understood and makes sense (thanks ekroemer as well for your reply). Spawn both locally / Spawn both server side / Spawn one cleint and one server and try to manage the traffic / no interaction. Any thoughts of a headless client compatible version (I appreciate there is no real standatd HC mod as of yet).
AI Vehicle chasing: Shame. If someone was able to get it to work I can imagine some great Benny Hill moments :) .
AI pathing: Sure although it is more the selection from multiple static spawn point to add more of the illusion of randomness. For the NE Airfield, for example, maybe one to the West (seems to be one there currently), one to the South and one to the North in the forest by the hero trader and then randomise which one spawns. This seemed to be the way in the older version but the current (previous if there was just a new release) they seem to come only from the West. I will have a look at reconfiguring them when I get a chance.
Thanks again for taking the time.
-
save as an sqf file and use this with fn_selfactions if you have custom ones:
_object = createVehicle ['SignM_FARP_Winchester_EP1', [0,0,0], [], 0, 'CAN_COLLIDE']; //billboard _object setVehicleInit 'this setObjectTexture [0,''custom\evictionSign.paa''];'; //PAA image _object attachTo [player, [0,2,0]]; //attach 2m in front of you sleep 5; //5 seconds to reposition _object detach; //detach
It will not persist trough restart, altho I don't see how it would work anyway. Even if you saved it to database, texture would dissapear.
How about...
Save to the DB, save the object texture file name in the inventory of the item, on server load, read the texture file and re apply before placing in the world ?.
-
Cans can also be smelted in to tin I believe. Sorta like the process to boil water.
Whisky bottle -> tin bar is the easiest though.
Saying that, I can understand why you would want to to change it.
-
There are some threads around about reskinning some of the billboard signs. Have a search around and that may work for you.
-
With that plot for life, will we be able to convert everything built by players to the new ID so everything they built can be maintained them?
The sql to do that on a one by one basis is already available on my thread. Doing more than that is tricky as any characterID over 2 digits could be a door lock code and over 3 digits could be a safe code.
The other alternative would be to put in a one time function that can be turned on or off and will align all buildables in the plot pole radious to the plot pole owners ownership. That would be pretty simple but it depends if that is what people want.
-
Yep it is there buy a bit deeper in here.
-
Plot Pole dissappearing after restart
in Scripting
Posted
As this post was from July 2014 I suspect it was refering to the change from GameSpy and BIS ARMA II UIDs to SteamIDs.
The issue was that the SteamIDs were too long to fit in the characterID field of objects in the DB and the Hiveext.dll also inforced this max length so resizing the DB field would not fix the issue.
A Plot for Life has been working fine with SteamIDs from version 2+ (a complete rewrite which was released just over a week after the issue came to light).