emuthreat

Optimistically, I think you will be quite well-practiced once flowers are added to the game. Thanks for the help. I'll try to rustle-up some condiments; nobody likes a dry wiener...

There are no flowers to collect in Dayz. Nice try. And thanks for starting off the responses in the right direction. :P My bad for trying to use this time to organize a legitimate testing attempt.... Waiting for the day that F4 and F7 will both work at the same time, @lrishjake AKA:(L)rishjake

Yup, that's what I meant. I cant imagine a 1.0 release without official, BI hosted, public servers. I haven't been promised,and do not want to project that there is anything promised of that nature; but I don't see how the game can release as a non-alpha title without BI having close control over what happens on their official servers. I regard the current server provision arrangements as placeholder, with an understanding that the developers will eventually host their own vanilla servers for the 1.0 release. This is only my impression of the things that I have read and heard. And really, it doesn't really matter, because my plans only go as far a the next patch at any given moment until 1.0.

Don't worry too much, the new engine improvements will pave the way for the new crafting systems, and there will finally be an appropriate medium in which to have the "Survivalist Scrum." I was a bit put-off too, until I realized that the combat systems are already basically fleshed-out, while the survivalist mechanics are still waiting on the new engine functionality. I should really start multiquoting more often, lol. ^^^

I'm afraid you will have to learn to mod and code your own AI, as BI has specifically stated, many times, that uninfected AI are absolutely not on their to-do list.

We've been over this ad nauseum. BI will have to ensure "official public serves" or new players who buy the game will have nowhere to start; and cheap American bastards like myself will have no "Manifest Destiny" to realize. It has been conveyed to me that there *will* be official public servers for 1.0 release; and less specifically, I got the impression that BI *might* be directly overseeing these servers to ensure their viability for persistent basebuilding activity. I shared all of this with you directly when my pertinent question was answered. GWIZ Thanks @SMoss.

I check every day, thinking that as soon as it is up, .60 will be ready. I know it is a massive amount of information to carry over, but I kinda feel like it should have been done by now; I get the impression that it is sitting there waiting for .60 to drop, so people won't be tempted to report .59 bugs. (As I might still be doing if it were currently up...)

Worked all day to get set-up. Forgot to drink water until reaching the airfield. Back to the coast with you. Slow and steady wins the race. As it should be. If you want to get "set-up" drop me a line, I got too many camps, on too labor-intensive cleanup mechanics, and I need to make use of some shit before the server eats it all up. Just respwan, and join this server: 173.199.94.27:2302 << = THE HELPY HELPERS: FOR MERCY OR MAYHEM >> I'll be on shortly.

This one belongs in the graveyard, actually. It has no value. lol Where's the video, dawg?

We have been assured over the last couple months that the server hosting rules, guidelines, enforcement, and agreements with SPs will be given some attention. We can only hope that it is sufficient. While I'm back on here again. Might I reiterate that 8-day cleanup timers on storage items is a terrible idea, which makes persistent base building playstyles inviable. Not envyable, INVIABLE. If I wanted to play on three different private servers, and keep a camp close to a military base and a camp near each coast, it would require ~9 hours of running around just to avoid losing my progress every week. There has to be a balance that allows a lone-wolf player to establish and maintain a couple bases, while still having time to actually play the game.

There was a specific class of item that I noticed causing problems in .59; but it had gone stable by the time we discovered it; the resources were better suited for their intended use, and we didn't want to wreck the server we were playing on at the time. I already know what exactly I want to do, and the rough number of items needed to do it. The whole point of this exercise is to test natural, intended, game mechanics on EXP before it goes stable, that have a real chance of causing unwanted server issues under normal circumstances. I'll give you a hint: The items in question started out in .59 as not being persistent, were then given persistence, and recently, the persistence was reduced--possibly to the same level as backpacks. They are items that any large, highly-mobile group would be wise to stockpile throughout the map; easily accessible in case of emergencies. Hence my original behavior of warehousing large quantities of them. And no, I don't want any "help" from people in the form of duping.

Awww, come on. When in Rome...

For the time being, I am very interested in any persistence-related hijinks that could potentially crash a server. Better now than after the game is 1.0. If anybody else shares this interest, I am trying to get an experimental wrecking crew together to try and ruin some .60 experimental servers in short order. Players with vehicle acquisition, driving, and efficient loot collection skills to the front of the line, though escort and overwatch players are also needed to avoid the time wasted by the influx of EXP KOSers. You MUST be able to play for periods of around six hours straight in order to accumulate the necessary resources before a hotfix takes away the progress. We will have to move fast and hoover-up as many barrels and vehicles as possible, then start collecting and warehousing a certain class of persistent items, while establishing a steady supply of tents to keep the items safely stored until the necessary amount have been collected. Once we have amassed an unreasonable number of target items, teams will position themselves at the different warehouses, and begin simultaneously emptying the contents of the tents onto the ground. If we do well, we will see widespread client crashes; if we do great, the server will have to be taken down and reset. Anyone wishing to participate in my attempt to break experimental should contact me through PM, and we'll get a shared conversation going to hash-out the details.

I'll bite; was it stolen from a barrel or tent?

It is still confusing. One thing that I would like to test, but loathe to invest the time required, would be whether there is a hard maximum for barrels on any given server; wherein any subsequent barrel imported from another server would de-spawn the oldest existing barrel on that server. i really hope this is not the case; because oh the trolling you will see. Go to the lowest populated server on a private hive, find as many barrel spawns as you can, hide them away for safekeeping in a secluded area of the map--making sure to check on the all every 8 days, repeat on the other servers on the hive, once enough barrels have been collected from the collated servers on that private hive, start dumping them all onto the same server, watch and laugh as dozens of established players start to whine about their camp having disappeared despite their having interacted with them as diligently as could be done. Just a small concern regarding the balance of hardy persistence vs decreasing performance.

@pilgrim*, @sausagekingofchicago You are both better than this. At least do the civilized thing and keep it on the PM side of the forums...

If you need medical assistance and are on public hive, please contact me with your approximate location, and I can bring charcoal and antibiotics. Are you sure that you got sick from canned food? Did you drink dirty water? People tell you that drinking pond water is fine, but it is not. No exposure-based resistance to infection, just a RNG based on your health status. I forgot to quote this. @Diemux

You can now post screenshots directly from the Steam online library. You just have to click on the picture you want until it opens in its own browser tab, C&P the URL, and paste it into the "insert other media" box.

This is about the best solution that I have been able to imagine, but it would have to be implemented so that the observing player's client does the reduction in detail on the observed player. We wouldn't want to have players watching their own textures get crappy, and use it like a spidey-sense that they were being watched. There are, of course, problems with this idea too. Firstly, each player would have to be equipped with another *expensive* sensor, one much like the zombie AI have, that assesses the content of the visual cone. This cone would have to be as long as the render distance, and extend a few degrees beyond the player's FOV, to provide time for the program to decide if and how to hide an observed player. It would have to be decided if zombies and animals in cover will have to be adjusted as well for the viewer; and this is where resource cost becomes an issue again. And that is just the "what" phase. There will be a second line of resource expense to determine "how" each observable situation of players, in every possible combination of clothing and character skins, should be adjusted to appear for an observer. If you have a player sitting at dusk, on a hill just at the treeline, observed from two different players that are separated by 150 degrees, would the player rendering be consistent for both observers? How would this work? Should the opacity of the observed player simply be scaled down, based on the ambient vegetation and light conditions. Would a single beam of sunlight shining down through the canopy be enough to blaze off a players shoulder, negating their use of cover in a shrub? If this weren't an enormously difficult problem, #commonsense dictates that it would have been resolved by now.

I was definitely not serious about that rendering jab. Pilgrim gave me a long spiel about how the 3 different textures based on observer distance were *not* rendering distance; even though it decides what to render, based on the distance it is from the player. There is a reason that foliage cannot be rendered out past a certain distance in a high-detailed texture. And that reason is resource cost. I tried to hyperbolically illustrate that point by using infinity as an unrealistic milestone to work back from. As the distance in which things are rendered at high detail increases, so do the resource costs. Lets just understand resource cost to be a function of the distance at which grass is rendered in high enough detail to provide adequate cover on flat ground. The resource availability considerations will make anything beyond a certain distance impractical to render in a high-detail texture. There is a point, much closer to zero than infinity, at which the law of diminishing returns will take effect. I assume the game is already there. So the idea of "increasing the rendering distance of high-detail grassland textures" is really not a solution. Even doing so for a distance of 500 meters is prohibitively expensive, or I assume that the devs would have done so already.

I'll chalk it up to the language barrier. Sometimes I use idioms and hyperbole. I thought the flippant nature of the last line would speak for itself. I didn't go out of my way to use a somewhat esoteric and unnecessary symbol for no reason. At least if the grass was set to render at greater than infinity, the program would just say no, instead of crashing from trying to do something equally as futile; like rendering millions of blades of grass beyond our physical capability to distinguish them. Sometimes I wonder about you, Pilgrim...

Beans to Pilgrim for beating a dead horse, but using a damn-fancy stick to do it. My two cents: ∞ ≤ grass render distance. Problem solved. :P

Won't change for .60, or won't change for 1.0? It's a big difference.

I am only now realizing how much Enfusion .60 is going to have. It seems as if this is the actual "Engine Swap" phase of development. I was a bit dismayed and confused, having only a couple weeks ago first heard about the reloading animations as a .60 blocker, after weeks of having missed the projected .60 release date. But the voice of reason in my mind tells me that this is the first major new engine meshing attempt; and I suspect that they may have discovered a few things tied to basal functions that absolutely have to be incorporated on the first iteration in order for the engine to be compatible with future content or functionality additions. It would be great to hear a bit more about what makes those reloading animations so critical to the release of .60, if any of the development team happen by this thread. I can't hold it against them, though. Working on almost anything (from houses, to vehicles and appliances, and just about any other relatively complex system) has the same kind of risks involved in knowing what has to be done, but only discovering how certain things must be done, after the work has already begun. A bit more information on exactly what the new engine is supposed to do would be nice. I am really hoping for a good set of PatchNotes for .60.

Sounds Phishy...