phm
-
Posts
102 -
Joined
-
Last visited
Content Type
Profiles
Forums
Articles
Posts posted by phm
-
-
1 minute ago, He-Man said:
THanks @Grahame, that's it, I think. Will double check it tomorrow.
Ok, thanks. Shouldn't this also be in epochconfig.hpp?
And in the meantime, where should I edit this?
<mission_file>/compile/traders/EPOCH_npc_TraderAdd.sqf ?
-
15 hours ago, He-Man said:
Hmm, just tested it and for me it is working fine:
starterTraderItems[] = { // Starter Items for fresh spawned trader first array is classnames second is quantity. {"ItemSodaBurst","meatballs_epoch","VehicleRepair","KitPlotPole","Hatchet","MeleeSledge","200Rnd_556x45_Box_F"}, {5,5,5,2,2,2,400} };
https://www.dropbox.com/s/rdqdk9p2fcmmn9s/20180329023201_1.jpg?dl=0
Still not working for me (see attached jpeg). The trader should have 10 clips.
starterTraderItems[] = { // Starter Items for fresh spawned trader first array is classnames second is quantity. {"150Rnd_556x45_Drum_Mag_F"},{1500} }; NPCSlotsLimit = 30; // Max number of traders static or dynamic. Warning! Higher the number lower performance. forceStaticTraders = "true"; // disables traders moving from work to home TraderGodMode = "false"; // If true, Trader can not be killed by Players storedVehicleLimit = 15; // Vehicles more than x stored in ALL Traders will automatically be deleted on Restart. StaticTraderItemPurge[] = {99999,1}; // {ItemCount,ReducePercent} - If a static trader have more than x different items, on restart the items will be reduced by y percent DynamicTraderRespawnCount = 99999; // If a dynamic Trader have more than x different Items, he will respawn on another Spot (with start Items) TraderItemCountPerItem[] = {99999,99998}; // If the Trader has more than x pieces of an Item, it will be reduced to y pieces (on Restart) TraderItemsDeleteInstant[] = { // List of Items, that will be deleted from Trader instant after sell // "ItemVehDoc1", // "ItemVehDoc2", // "ItemVehDoc3", // "ItemVehDoc4" }; TraderItemsDeleteRestart[] = { // List of Items, that will be deleted from Trader on Restart // "ItemLockbox", // "ItemSafe", // "ItemGoldBar10oz" };
-
12 hours ago, He-Man said:
Yep, all mags in traders are only calculated by rounds now.
So if you want 2 Mags of 20rnd_... you have to set the value to 40.
Thanks for this! With this in mind, I tested more. It seems the max that I can get to go into a belt (e.g, mk200) is 100 rounds. What am I doing wrong?
-
After a bit of testing with new databases, it's seems that numeric values in epochconfig.hpp/ starterTraderItems[] are being interpreted as number of rounds in a clip rather than number of clips.
Is there some way to specify both, or is the starterTraderItems[] value being put in the wrong place (#rounds vs. # of clips)?
Thanks!
-
37 minutes ago, Sneer said:
I don't think so, they just missed updating those files.
Those files should be automatically created when the package is generated. I looked at this because I got a version mismatch error when I tried the build 1077 server.
-
Am I missing something?
steam@host ~/Downloads/temp $> ls -l total 14408 -rw-r--r-- 1 steam steam 14753093 Dec 4 10:13 EpochModTeam-Epoch-1.0.0.1077-0-g2b4ec06.tar.gz steam@host ~/Downloads/temp $> tar xf EpochModTeam-Epoch-1.0.0.1077-0-g2b4ec06.tar.gz steam@host ~/Downloads/temp $> ls -l total 14412 -rw-r--r-- 1 steam steam 14753093 Dec 4 10:13 EpochModTeam-Epoch-1.0.0.1077-0-g2b4ec06.tar.gz drwxrwxr-x 5 steam steam 4096 Nov 5 05:57 EpochModTeam-Epoch-2b4ec06 steam@host ~/Downloads/temp $> cd EpochModTeam-Epoch-2b4ec06/ steam@host ~/Downloads/temp/EpochModTeam-Epoch-2b4ec06 $> cat version.txt ; echo 0.5.0.0 steam@host ~/Downloads/temp/EpochModTeam-Epoch-2b4ec06 $> cat build.txt 826 -
On 11/14/2017 at 9:12 AM, vbawol said:
Build a garden and access the inventory then place the seeds into the garden plot and wait some time, it takes about 1 hour 20 minutes to fully grow.
Please forgive my denseness here, I'm just not getting it. Do you double click on a seed pack in your inventory? (nothing there but "repack" for me), or do you just drop the seeds on the ground when you're standing in the garden plot (didn't work for me either)?
Thanks in advance!
-
+1000!!!
CfgPricing overhaul, updates to the admin menu(!!!), new crafting that I haven't even looked at yet. I was skeptical that this release warranted a 0.5 -> 1.0 version number lift, but there's a LOT of stuff in 1.0!
This is the new juice that Epoch really needed!
- Axle, Helion4 and DirtySanchez
-
3
-
12 hours ago, vbawol said:
Also, I will touch this quickly. @phm The only build that did have a "Steam ID backdoor" was an early leaked version that was intended only for use by the closed group of server admins we had testing at the time. They all knew about it. Just as you mentioned the "controversy" you refer to was manufactured just to get attention to drive sales. I.E. https://en.wikipedia.org/wiki/Streisand_effect
Thanks for this. What about infistar's allegation that AH code in Epoch was derived from his work? Is that why the admin menu has never been updated?
I really appreciate you putting a little time into clarifying where things stand today. Like I said, I'm a fan, and I've even contributed. I totally understand that you want to move on and things need to be amicable so that we don't have a situation like "Face" and A3EAI where some users got a little too demanding of his time and attention and he just walked away and pulled his code off the 'net.
With all the sincerity I can muster, I want to say THANK YOU VERY, VERY MUCH for all the work and time you've put in to Epoch!!!!!!!!!!!!!!!!!!!!
-
I still play Epoch. I don't think it's dead, but it's not what it used to be in 2015 or so. There's always been this "mystery" about the admin menu and apparently the consensus is to purchase the infistar admin menu rather than improve the one included with Epoch. I don't really understand that, but I am aware of the controversy of Steam ID back doors in earlier versions (it's not still there, right?) of the antihack. I'm not aware that the Epoch team ever formally addressed that controversy. Perhaps not updating the admin menu (thereby motivating people to purchase the infistar software) is some form of contrition.
For me, it's not the speed of progress toward a 1.0 release. I would like to see a better inventory system. If you've ever moved inventory between uniforms, vests, or packs, you know how painful it is. I think someone said they destroyed their right mouse button playing Epoch. I believe it.
I noticed that in the last few releases, most of the changes/fixes are coming from the community, not the devs. That, to me, is the biggest indicator that the devs are either distracted or have moved on to something else (or some combination of both). And that is a harbinger of the demise of Epoch. I sincerely hope I'm wrong about that.
Something that isn't usually discussed in this context is the popularity of non-Epoch AI in Epoch servers. I still haven't seen anything better than A3EAI as far as static patrols in towns/cities. The popularity of these AI packages (I've used others, none have static patrols like A3EAI) is an indication that Epoch is still incomplete.
When browsing the Arma 3 server lists, it's obvious that Epoch is becoming an outlier. If most server admins are disabling all the Epoch antagonists (except for cloaks, but hardly anyone wants to play at night it seems), that should send a message. In their apparent zeal to not cater to people wanting a "babycore" gameplay experience (I learned that word from this very forum), the devs have made a game that is not interesting (maybe even annoying) to most people wanting to play on an Arma 3 server.
So while I might count myself among those who still enjoy playing Epoch, I will concede that I have also disabled most of the antagonists. Because the inventory system is so slow, I just got tired of being killed by a sapper or a drone patrol when moving inventory to a new, bigger vest or backpack. I know some people like the idea of "anti-camping". And a vanilla Epoch server instance should more than satisfy those "babycore haters". But Epoch can satisfy everyone with a little more granularity of antagonist configurability. Cloaks should be able to be configured to appear in the daylight (yes, I know currently they replace the "standard" sapper at night) or at whatever hours the server admin chooses. If I want a drone to appear every hour, or two hours (instead of 10 minutes), that should be possible. I would love sappers again if they only appeared like once every 4 hours or so. That would make them rare and something to look forward to. But every ten minutes? It's too much.
Haters gonna hate, campers gonna camp, and server admins will cater to what they believe "most people" want. Now, let me get back to stealing some guns from this base I just found...
-
On 8/2/2017 at 1:59 PM, Drokz said:
The current changelog for the new epoch version can be found here:
https://github.com/EpochModTeam/Epoch/blob/experimental/changelog.md
It shows the current finished files but theres still WIP on other stuff.
Malden files needs to be done by yourself in 0.5 but next update will include them of course.
Add the malden.h
https://github.com/EpochModTeam/Epoch/tree/experimental/Sources/epoch_server_settings/configs/mapsAdd this to the config:
https://github.com/EpochModTeam/Epoch/blob/experimental/Sources/epoch_server_settings/config.cpp#L276Next Malden.hpp:
https://github.com/EpochModTeam/Epoch/tree/experimental/Sources/epoch_config/Configs/CfgEpochClientNext Config:
https://github.com/EpochModTeam/Epoch/blob/experimental/Sources/epoch_config/Configs/CfgEpochClient.hpp#L110And mission.sqm
Thanks for this. "malden.h" (the current one in github) looks a bit light compared to others. Perhaps this is what is meant by "initial support".
Can anyone give me a tip on how to get XYZ coordinates for placement of objects? I'm trying to create some persistent camp fires. It seems the craftable ones do not persist.
Thanks in advance.
-
Just curious if we'll see a Malden map in the next Epoch release. Any forecasts on when that (next release) might be?
Thanks
-
Perhaps I wasn't completely clear in what I'm asking. The "epoch.Tanoa.pbo" file is the mission file for Tanoa, which is only available to those who have purchased the APEX DLC. IMHO, it's appropriate for that mission file to have the complete set of APEX items. I'm not proposing that the APEX items be added to any other mission file.
-
1 hour ago, Grahame said:
I'd have to check later. I do my own customised pricing and loot tables
Understood. I looked and they weren't there. I'm hoping to get the base code improved so that everyone, not just those skilled enough to do their own mods, can enjoy the DLCs.
I've dabbled in custom modifications and when the base code is updated, it takes a significant amount of work to port those mods. I've seen a marked decline in the number of A3 Epoch servers out there on the internet. I would like to see those numbers restored to (or even exceed) 2015 levels.
Thanks
-
10 hours ago, Grahame said:
Females (BLUFOR) can wear U_B_T_FullGhillie_tna_F and males (OPFOR) U_O_T_FullGhillie_tna_F but not vice versa in standard ARMA3/Epoch
So I was just trying to put on the wrong one? Come to think of it, I was trying to put on the "NATO" suit. I will try again with the other. But we agree they're currently not in cfgpricing or loot tables?
-
It seems the two APEX ghillie suits:
U_B_T_FullGhillie_tna_F
U_O_T_FullGhillie_tna_F
...are currently absent from cfgpricing and loot tables. The Altis ghillie suits stick out like a sore thumb in Tanoa.
Even after I forced one of these suits into the game, I could not put it on for some reason.
-
-
FYI, it looks like build environment for 040 build 672 is the same environment as the previous build. i.e., still not compatible with CentOS 7.
arma3server is, however:
steam@host:~/arma3$ ldd -v arma3server linux-gate.so.1 => (0xf7736000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7710000) librt.so.1 => /lib32/librt.so.1 (0xf7707000) libdl.so.2 => /lib32/libdl.so.2 (0xf7702000) libsteam_api.so => /home/steam/arma3/./libsteam_api.so (0xf76d9000) libPhysX3_x86.so => /home/steam/arma3/./libPhysX3_x86.so (0xf7415000) libPhysX3Common_x86.so => /home/steam/arma3/./libPhysX3Common_x86.so (0xf72a5000) libPhysX3Cooking_x86.so => /home/steam/arma3/./libPhysX3Cooking_x86.so (0xf7276000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf70ff000) libm.so.6 => /lib32/libm.so.6 (0xf70aa000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf708d000) libc.so.6 => /lib32/libc.so.6 (0xf6ed8000) /lib/ld-linux.so.2 (0x5662b000) Version information: ./arma3server: librt.so.1 (GLIBC_2.2) => /lib32/librt.so.1 libdl.so.2 (GLIBC_2.0) => /lib32/libdl.so.2 libdl.so.2 (GLIBC_2.1) => /lib32/libdl.so.2 libm.so.6 (GLIBC_2.0) => /lib32/libm.so.6 libm.so.6 (GLIBC_2.1) => /lib32/libm.so.6 libpthread.so.0 (GLIBC_2.2) => /lib32/libpthread.so.0 libpthread.so.0 (GLIBC_2.3.3) => /lib32/libpthread.so.0 libpthread.so.0 (GLIBC_2.1.1) => /lib32/libpthread.so.0 libpthread.so.0 (GLIBC_2.3.2) => /lib32/libpthread.so.0 libpthread.so.0 (GLIBC_2.1) => /lib32/libpthread.so.0 libpthread.so.0 (GLIBC_2.0) => /lib32/libpthread.so.0 libgcc_s.so.1 (GCC_3.0) => /usr/lib32/libgcc_s.so.1 libgcc_s.so.1 (GLIBC_2.0) => /usr/lib32/libgcc_s.so.1 libstdc++.so.6 (CXXABI_1.3.1) => /usr/lib32/libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.9) => /usr/lib32/libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.11) => /usr/lib32/libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.15) => /usr/lib32/libstdc++.so.6 libstdc++.so.6 (CXXABI_1.3) => /usr/lib32/libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib32/libstdc++.so.6 libc.so.6 (GLIBC_2.3.2) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.1.2) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.2) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.1.3) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.1) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.3) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.7) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.0) => /lib32/libc.so.6 /lib32/libpthread.so.0: ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2 libc.so.6 (GLIBC_2.3.2) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.1.3) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.1) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.0) => /lib32/libc.so.6 libc.so.6 (GLIBC_2.2) => /lib32/libc.so.6 libc.so.6 (GLIBC_PRIVATE) => /lib32/libc.so.6
-
On 12/10/2016 at 7:33 AM, vbawol said:
Hello phm,
The best place for bugs like this are the github as things on the forum tend to get lost in all the clutter.
https://github.com/EpochModTeam/EpochServer/issues
This is due to me compiling the epochserver.so for updates/fixes on a newer Debian 8.6 box that has this more updated GLIBC version. I will see about recompiling with GLIBC 3.4.14 as you mentioned in the other thread.Would it be worthwhile to see what linux build environment Bohemia uses? That way, you know you'll always be in sync with the core code.
Thanks!
-
Please look here for details.
Important note: the "arma3server" (166) executable still runs just fine under CentOS 7.
-
More detail:
Epoch 0.3.9:
./epochserver.so:
libgcc_s.so.1 (GCC_3.0) => /lib/libgcc_s.so.1
libstdc++.so.6 (GLIBCXX_3.4.14) => /lib/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.13) => /lib/libstdc++.so.6
libstdc++.so.6 (CXXABI_1.3) => /lib/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.11) => /lib/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.5) => /lib/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4) => /lib/libstdc++.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
Epoch 0.4.0:./epochserver.so:
libgcc_s.so.1 (GCC_3.0) => /usr/lib32/libgcc_s.so.1
libstdc++.so.6 (GLIBCXX_3.4.14) => /usr/lib32/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.13) => /usr/lib32/libstdc++.so.6
libstdc++.so.6 (CXXABI_1.3) => /usr/lib32/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.11) => /usr/lib32/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.5) => /usr/lib32/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.20) => /usr/lib32/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib32/libstdc++.so.6
libc.so.6 (GLIBC_2.1) => /lib32/libc.so.6
libc.so.6 (GLIBC_2.1.3) => /lib32/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib32/libc.so.6So the required version of glibc was increased from 3.4.14 to 3.4.20 in Epoch 0.4.0
-
All on one line:
adminMenu_Owner[] = {{"xxxxxxxxxxxxxxxxx","DanTheMan"}}; -
FYI, the 040 Epoch server for Linux is no longer compatible with CentOS 7. This is a real bummer:
steam@host ~/arma3/@epochhive $> pwd /home/steam/arma3/@epochhive steam@host ~/arma3/@epochhive $> ldd epochserver.so ./epochserver.so: /lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./epochserver.so) linux-gate.so.1 => (0xf77fa000) libstdc++.so.6 => /lib/libstdc++.so.6 (0xf75b6000) libm.so.6 => /lib/libm.so.6 (0xf7574000) libc.so.6 => /lib/libc.so.6 (0xf73b7000) /lib/ld-linux.so.2 (0x5660c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf739c000)
I don't understand why this decision was made. The arma3server binary is still compatible. Don't the epoch developers want this to run on the widest array of linux server OSes?
-
Short and sweet:
https://github.com/EpochModTeam/Epoch/blob/release/Server_Install_Pack/sc/users/sc/sc.arma3profile
thirdPersonView = 1; // 3rd person view (0 = enabled, 1 = disabled) cameraShake = 1; // Camera shake (0 = enabled, 1 = disabled)Obviously the comments are wrong. Have a look here for the updated reference from BI. It only took about an hour to figure out this was a typo.
1.1.0 Trader ammo inventories config vs. reality
in Bug Reports
Posted
After changing values in both of those files (just changing the one in the mission file had no affect), it's working as expected.
Thanks @He-Man and @Grahame for your help! Looking forward to fix(es) in the next release.