Dancing.Russian.Man

Version numbering systems may be arbitrary, but in game/software/anything development, 1.0 is generally considered the first "complete" version, out of testing phase, or however else you want to phrase it. Regardless, even if BI made an official statement about 1.0 not being the end of beta, most people are not going to see that and the fact that you've left Early Access and get announced by Steam as a full new release, you can't ever get that again. It's a lost opportunity for a big push no matter what is going on with development if players receive it poorly.

I've been having these concerns since they broke their "no date/deadline" stance, as well. This is not the end, but we're not going to have another "release" on Steam after Early Access is done. It's going to be difficult to grow a player base post-release if you don't have a strong number to begin with, because of how the game will be perceived by new players looking at the server browser. Releasing as 1.0 and leaving Early Access in a buggy state is always seen as a majorly negative point ("What was the point of Early Access then?"), as well. I've watched many games try it, and I can't think of one that has survived it and grow.

Moving it back then, but I don't think there's a way for me to explain my sincere intentions without it coming off as possibly condescending, so I will just say sorry and leave it at that. Hopefully someone else has more useful advice for you. :)

You posted in "Troubleshooting," so it seemed like there was a problem with your game that you wanted to solve. Your description still doesn't describe what the problem actually is. Can you not get in the car? Does it not turn on or respond to controls? When you say "Don't know how much longer we can keep this up" it sounds like this happens regularly and affects multiple people. In that case you should file a proper bug report on the Feedback Tracker -- that's how you make sure the devs have a record of it. But if this was meant to be just a "lol look at this," you should post that in the Gallery section instead in the future. I'm gonna move this over there since that's what this is starting to look like, but correct me if I'm wrong and I'll move this back.

Please describe the problem in further detail if you want to troubleshoot something. A video of a thrashing wheel on an otherwise normal appearing car isn't enough.

FYI, Phabricator (the feedback tracker) is not developed/designed by Bohemia Interactive, and neither is the forum framework we have here.

I should have put that in my post, sorry about that! https://discord.gg/4hwJUFT

There is no officially released documentation available yet, so you'll have to look into the game files yourself, ask others (We have a Discord server!) or search through this third-party website: http://lystic.net/dayzwiki/

From gameplay.h 75 class TotalDamageResult 76 { 77 proto native float GetDamage(string zoneName, string damageType); 78 }; It's very difficult for me to give you what you want because there is no complete official documentation yet, and what you can find in the header files are prototypes/interfaces/signatures (how to call them), not implementations (what it does exactly). The "damage model" is implemented in-engine, not through scripts. Edit: From PlayerBase.c in Scripts.pbo (Some code removed for brevity) override void EEHitBy(TotalDamageResult damageResult, int damageType, EntityAI source, int component, string dmgZone, string ammo, vector modelPos) { // ... if( damageResult != null && damageResult.GetDamage(dmgZone, "Shock") > 0) { m_LastShockHitTime = GetGame().GetTime(); } //new bleeding computation //--------------------------------------- if ( damageResult != null && GetBleedingManagerServer() ) { float dmg = damageResult.GetDamage(dmgZone, "Blood"); GetBleedingManagerServer().ProcessHit(dmg, component, dmgZone, ammo, modelPos); } #ifdef DEVELOPER if(DiagMenu.GetBool(DiagMenuIDs.DM_MELEE_DEBUG_ENABLE)) { Print("EEHitBy() | Charater " + GetDisplayName() + " hit by " + source.GetDisplayName() + " to " + dmgZone); } // ... #endif // ... } This bit of code (it's an event) clearly deals with what zone the player was hit and prints it out if debugging is enabled. But also, from DayZPlayerImplement.c // was player killed by headshot? if (dmgZone == "Brain") m_KilledByHeadshot = true; Last edit, from Object.c /** \brief Obtains a list of nammes of all object's damage zones @param list of names */ proto native void GetDamageZones(out TStringArray dmgZones); There, now you can go and call that on the player in your script and print out the different damage zones. ツ

Enscript is very heavily C-based language, to the point of using ".c" as the file extension for scripts. I know Java handles comparisons differently, but I assure you, this is how it works in C/C++/C#. In C++, if you wanted to compare the objects themselves, you would compare the memory address of those objects. In C#, if you wanted to compare the objects themselves, you would use System.Object.ReferenceEquals(object, object)

Organ hit zones are already being used, what's your proof that they're not, if you're going to make a claim to the contrary of a dev blog? Having separate hitboxes for vitals doesn't necessitate that those vitals be visible, or that they can be interacted with beyond "did the bullet collide with this collider?" It seems to me like you're not understanding how simply this can be implemented, and extrapolate that the organs actually exist physically in the body so that if you were to look inside of a body, you'd see them, and they have an effect on the player's health in some complex form. No, if you wanted to think about it simply, you could think of the vitals as another special area like "headshot." (How do you think headshots are differentiated from bodyshots to begin with?)

If you want to send a message to players whose name is exactly "Survivor" (case-sensitive) and nothing else, you would just.. if( player.GetIdentity().GetName() == "Survivor" ) I don't know if the Contains function is case-sensitive, but it would return true as long as they had "Survivor" as any part of their name.

Oh I see, they were talking about function pointers. In C# (and C++), these would be called delegates, but I'm not sure if Enscript supports them. My first guess is no, but I'll get back to you on that. Edit: Two things: There is a keyword "func" in Enscript. That alone doesn't give much information. BUT.. In "proto.h", the keyword is used to define parameters for callback functions. proto float TraceLineEx(vector start, vector end, vector mins, vector maxs, out _entity cent, out float plane[4], out int content, out int surfparm, int flags, func filtercallback); proto float TraceLineExEx(vector start, vector end, vector mins, vector maxs, out _entity cent, out float plane[4], out int content, out int surfparm, int flags, func filtercallback, int layerMask); So.. Without being able to test it further right now, it seems like you're able have function pointers ("delegates") as arguments. The way you would use the parameter is type in the name of the function without its parentheses.

Yes it is. For example, the first thing I did was modify the init file so that the default loadout given is in a separate file, then I fiddled with it a bit: EntityAI item = player.GetInventory().CreateInInventory("HuntingKnife"); SetRandomHealth(item); Which I changed to, and is literally the same as: SetRandomHealth( player.GetInventory().CreateInInventory("HuntingKnife") );

Is it possible to initialize objects inline? Where is the code that implements the class for each item? What I mean by "initialize objects inline" is something like how C# does it. But for this to be viable, I'd need to know the properties of each item beforehand.

I haven't found the time to dive into modding yet, but this is definitely going to be a big help, thank you! Couple suggestions though: Edit out unnecessary bits, like waiting for the game to boot. Plan what you're going to show throughout your tutorial beforehand, and record yourself doing it in smaller sections. There's lots of benefits for your audience from doing this: No "uhs" and "ahms" Less time spent on typos and "oh wait, damn it." (Showing small code mistakes like the weapon attachment part can be useful sometimes, though.) You won't be rambling or distracted by irrelevant things, like the contextual auto-suggest thing. Better structured tutorials, and it'll be easier for you to redo a part if you feel like you want to.

Sorry but I don't know.

There's no reason for why you should do anything. If you don't want mods, don't use mods. You can also turn off auto-update of course, if you're so stubborn and don't want updates.. You'll still need Steam to run your client and other players doing the same, or your server is going to feel lonely. How do you make this leap? DayZ isn't going to become free and BI isn't going to stop improving it. If you choose to isolate yourself, that's what you do. Plugging your ears and going "lalalalala" doesn't give your arguments any credit.

Still the same strawman argument. Nobody is asking for "final version with no further updates." You're being incredibly disingenuous.

No it doesn't, and that's not what people mean. You're picking apart a strawman and achieving nothing. You even kick it over right after you've created it by acknowledging that "finished" isn't the end. Edit: Gah, foiled again by the notification taking me to the last reply of a page.

Thanks @Bombarding for the ping. I'll pass the info on and hopefully the name change can be sorted out soon!

Originally, the DayZ mod for ARMA 2 only featured the Chernarus map (link, link). Other ARMA 2 maps were later made compatible with the DayZ mod by fans of the mod, such as Taviana and even original maps like Namalsk. Currently, I don't think the devs have announced any official maps, but they also haven't said that there won't be any. Long before the modding tools were available, the ARMA 2 DayZ Namalsk creator worked with the DayZ Standalone devs to see what it would take to add a new map to the Standalone. Nowadays I think the Namalsk creator is officially working on DayZ, but has confirmed that he will be releasing Namalsk as an unofficial map for DayZ. Many other fans have also claimed to be working on map mods. I think that just about sums it all up.

For what it's worth, we've kinda got an official DayZ Discord over here: https://discord.gg/kkprdc

First things first, because your whole post sounds like you're talking at me, I'm not a developer. I'm just another player like yourself, just also volunteering some of my time as a moderator. That said, I'm not really against the idea of putting a dot on the map with "you are here" on it. (Assuming you'd have to get the map first.) I'm just stating that it hasn't really been a thing officially, especially in the standalone. It's not like the game's a camping trip. Your character is either washed up or has been wandering around the shoreline, so I don't think everybody should be starting with a map and/or compass. The feeling of being lost should be a part of DayZ, at least in my opinion as that's one of the reasons why I personally enjoyed the mod. Being lost is a danger just like anything else, so you have to take that into account and prepare for it if you plan on exploring. If you don't want to get lost, follow the roads and signs. Memorizing the look of a town name is easy even if you don't know a single cyrillic letter.

These are both network issues, "No message received" means you're disconnected and the game will try to reconnect for 30 seconds before going back to the menu. This is something the community has been discussing since Early Access started, but PC never got it and it wasn't always in the original mod either. The map-reading skill requirement is definitely one staple DayZ has always had, and like in the mod days, modders will probably have to add it themselves. To quote the wiki (because it's more concise than what I was about to write): "The Central Loot Economy (often abbreviated "CLE") is DayZ's unique management system for loot spawning and clean-up. It is a complex system of tags, categories, zones, maximums, minimums, averages, and so on. The CLE dictates exactly how many of each item can be present on a single instance of the game at a time (one server), with important factors like randomization and rarity baked in. These values can be adjusted at any time, without requiring players or servers to install a game update."