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.