Jump to content

Recommended Posts

 

Of course, Pvt. Acker was dismissed for disobeying orders, which eventually led to the death of a comrade.

 

 

 

 

Seriously, are we ever going to see a fix for this issue?

Share this post


Link to post
Share on other sites

 

They didn't. They changed the obscure keyword usage to better fit / be more consistent in naming for what it does.

 

It's not changing

if(local _x) then {...}

it's changing

local _dude = player;

which was the same as doing

private ["_dude"];
_dude = player; 

into

private _dude = player;

 

Yes, this is what I'm talking about. I use local to define private variables:

 

local _secondaryIndex = [((uiNamespace getVariable "InfantryEquip_PrimaryCat") lbText (lbCurSel (uiNamespace getVariable "InfantryEquip_PrimaryCat"))), 0, FS_DATA_EQUIPMENT_CATEGORIES] Call fnc_shr_getArrayIndex;

 

I find it quite frustrating that BIS does stuff like this. Have they not learned before that you CANNOT change the name of scripting commands without leaving the previous one there for compatability?

Share this post


Link to post
Share on other sites

Yes, this is what I'm talking about. I use local to define private variables:

local _secondaryIndex = [((uiNamespace getVariable "InfantryEquip_PrimaryCat") lbText (lbCurSel (uiNamespace getVariable "InfantryEquip_PrimaryCat"))), 0, FS_DATA_EQUIPMENT_CATEGORIES] Call fnc_shr_getArrayIndex;

I find it quite frustrating that BIS does stuff like this. Have they not learned before that you CANNOT change the name of scripting commands without leaving the previous one there for compatability?

 

No one even heard of the use of "local" as keyword until a few weeks ago, because this is when VBS wiki got updated with this information. Are you saying that in a few weeks you used this so much that no Ctrl+H will fix it? The reason why it was not duplicated but renamed was because use of local is very confusing, and personally I am rather happy that you are forced to change it now because for someone learning scripting seeing your script with use of "local" then seeing another script with use of "private" would be just another WTF moment. Making language more consistent is more important than your tears.

  • Like 3

Share this post


Link to post
Share on other sites

Yep. Thats what they did. local no longer works as keyword and crashes all scripts that use it in 1.54 dev

 

PabstMirror wrote a regex to replace all local keywords with private without changing the local commands. Usefull if you have a bigger project.

https://github.com/acemod/ACE3/issues/2755

 https://github.com/acemod/ACE3/commit/616bc9f8a0e4e09f387038aba70b3bd1cddd9f1119 days ago, you don't need regex for that

Share this post


Link to post
Share on other sites

Hi all

Can I confirm that the new blood effects are in the current Dev Branch? Is is an option somewhere that I've missed? Cheers

Share this post


Link to post
Share on other sites

Hi all

Can I confirm that the new blood effects are in the current Dev Branch? Is is an option somewhere that I've missed? Cheers

 

I can confirm that the new stamina system is live on dev, keep in mind that the stamina bar is only shown while you actually use stamina.

Share this post


Link to post
Share on other sites

19 days ago, you don't need regex for that

 

Thats almost 3 weeks of coding that need to be reworked (no problem with regex really, but it's an annoyance). BWMod alone has a PR with 69 files changed (100+ lines changed) and that's more of a content mod than scripting. Truth is that this is one reason why we won't release an update (with the UH Tiger) right now. Granted that we need to wait for 1.54 anyway, because of the changes to soldier hitpoints, vests and headgear.

No idea how many files / lines / PRs of ACE are affected now.

Share this post


Link to post
Share on other sites

Thats almost 3 weeks of coding that need to be reworked (no problem with regex really, but it's an annoyance). BWMod alone has a PR with 69 files changed (100+ lines changed) and that's more of a content mod than scripting. Truth is that this is one reason why we won't release an update (with the UH Tiger) right now. Granted that we need to wait for 1.54 anyway, because of the changes to soldier hitpoints, vests and headgear.

No idea how many files / lines / PRs of ACE are affected now.

 

And that's nothing. Jumping on a newly discovered, undocumented feature isn't exactly the brightest thing to do when stability is concerned. Being slightly inconvenienced now for the future convenience of clarity is a good tradeoff in my eyes.  ;)

 

It theoretically might as well have been removed without a word due to being unintended or whatever. It being renamed to something much better and fitting to prevent future misunderstandings, and for that matter receiving a "stamp of approval" is much more relevant than having to re-validate your or my last 3 weeks of code.  :D

  • Like 1

Share this post


Link to post
Share on other sites

And that's nothing. Jumping on a newly discovered, undocumented feature isn't exactly the brightest thing to do when stability is concerned. Being slightly inconvenienced now for the future convenience of clarity is a good tradeoff in my eyes.  ;)

 

It theoretically might as well have been removed without a word due to being unintended or whatever. It being renamed to something much better and fitting to prevent future misunderstandings, and for that matter receiving a "stamp of approval" is much more relevant than having to re-validate your or my last 3 weeks of code.  :D

 

It is also the fastest method to create and assign private variable!

Share this post


Link to post
Share on other sites

It is also the fastest method to create and assign private variable!

 

I guess that explains why everyone jumped on it right away.  ^_^

Share this post


Link to post
Share on other sites

And that's nothing. Jumping on a newly discovered, undocumented feature isn't exactly the brightest thing to do when stability is concerned. Being slightly inconvenienced now for the future convenience of clarity is a good tradeoff in my eyes.

 

Well it was documented on the wiki. I had discussions about the keyword local being easily confused with the command local aswell. The "idea" to use private as a keyword instead was discussed, but then we discovered that the keyword was already available and working in ArmA 2. We figured that the keyword is there to stay, because it already existed for at least two years.

 

Here is the thing: A command / keyword / whatever that existed for 2+ years was renamed without backwards compatibility. You can defend that if you want. I don't care really. And I'm glad that I'm not part of the decision making process when it comes to these things. I'm just giving my feedback with it.

Share this post


Link to post
Share on other sites

Well it was documented on the wiki. I had discussions about the keyword local being easily confused with the command local aswell. The "idea" to use private as a keyword instead was discussed, but then we discovered that the keyword was already available and working in ArmA 2. We figured that the keyword is there to stay, because it already existed for at least two years.

 

Here is the thing: A command / keyword / whatever that existed for 2+ years was renamed without backwards compatibility. You can defend that if you want. I don't care really. And I'm glad that I'm not part of the decision making process when it comes to these things. I'm just giving my feedback with it.

 

A feature that existed for 2+ years that no one knew existed. Yes, the renaming could have been done 19 days earlier, I can give you that, but this is minor inconvenience compared to the benefit of clarity it now brings. 

Consider this as a new command that has been added to the dev branch, tested and decision was made to rename it. This happened before and no one complained. But because in this particular case the keyword "existed" even no one used it, it doen't make it that much different from other renamings. 

  • Like 1

Share this post


Link to post
Share on other sites

I agree. private clearly is the superior keyword. On the long term this will only have benefits.

I hope we all can interact together with less sarcasm (last post on previous page) in future. Even if we don't agree with each others viewpoints.

Share this post


Link to post
Share on other sites

I can confirm that the new stamina system is live on dev, keep in mind that the stamina bar is only shown while you actually use stamina.

 

Thanks mate - spotted the stamina bar. Haven't noticed any new blood effects yet but will keep looking;-)

Share this post


Link to post
Share on other sites

Have they not learned before that you CANNOT change the name of scripting commands without leaving the previous one there for compatability?

When developing any sort of API, library or language, it can make good sense to leave in deprecated features in for compatibility; however, there are also times where you don't--especially if you REALLY want people to move away from something. You can end up in a sort of version hell sometimes, but sometimes you just have to cut the cord.

Share this post


Link to post
Share on other sites

I'm sure I won't be the first or last to express a little concern at the wholesale removal of the old fatigue system and its replacement with stamina. It breaks a lot of functionality with various scripts I've developed, and it's not a trivial matter to replace getfatigue/setfatigue with getstamina/setstamina because there is no direct correlation. Fatigue ranges from 0 (unfatigued) to 1 (exhausted). Stamina ranges from 0 (exhausted) to 58. However the maximum stamina value depends on how encumbered the unit is, and possibly other factors such as injury (damage). . A totally unarmed unit has a maximum stamina of 58, a heavily weighed down soldier might have max stamina of 22.

None of these relationships are documented, so workarounds are going to be kludges. 

 

If people are going to be able to replace the lost functionality then there needs to be some way of determining % stamina relative to the maximum allowed for a given encumbrance/injury etc. 

Share this post


Link to post
Share on other sites

I sometimes use local while I'm coding now for convenience, but always go back at the end and remove the locals and instead add to the private array. Not a big deal IMO. Better now than in a years time, and private is a better keyword than local, for the purpose.

Share this post


Link to post
Share on other sites

Found a bug in Dev Branch 1.53.132942.

 

Blufor Ammo Bearer class with "this enableStamina false" causes unit's ironsights to become misaligned with or without mods.

 

This does not occur if init is set to "this enableStamina true" or if Rifleman unit for example has "this enableStamina false".

 

Feedback ticket: http://feedback.arma3.com/view.php?id=26253   

Link to original post in Fatigue Feedback Thread: https://forums.bistudio.com/topic/158642-fatigue-feedback-dev-branch/?p=2926631

Imgur Album showing this in game:  http://imgur.com/a/hFTdO

Share this post


Link to post
Share on other sites

I'm sure I won't be the first or last to express a little concern at the wholesale removal of the old fatigue system and its replacement with stamina. It breaks a lot of functionality with various scripts I've developed, and it's not a trivial matter to replace getfatigue/setfatigue with getstamina/setstamina because there is no direct correlation. Fatigue ranges from 0 (unfatigued) to 1 (exhausted). Stamina ranges from 0 (exhausted) to 58. However the maximum stamina value depends on how encumbered the unit is, and possibly other factors such as injury (damage). . A totally unarmed unit has a maximum stamina of 58, a heavily weighed down soldier might have max stamina of 22.

None of these relationships are documented, so workarounds are going to be kludges. 

 

If people are going to be able to replace the lost functionality then there needs to be some way of determining % stamina relative to the maximum allowed for a given encumbrance/injury etc. 

Stamina actually ranges from 0 to 60.

 

Maximum stamina = (1 - load player) * 60   [in seconds]

Regeneration rate = maxStamina / 45   [more stamina seconds per second]

 

If the stamina hits zero, there's a 15 second cooldown before the sprint button is reactivated.

 

These values can be changed in CfgMovesFatigue.

 

There's no other factors, like damage for example.

  • Like 1

Share this post


Link to post
Share on other sites

Stamina actually ranges from 0 to 60.

 

Maximum stamina = (1 - load player) * 60   [in seconds]

Regeneration rate = maxStamina / 45   [more stamina seconds per second]

 

If the stamina hits zero, there's a 15 second cooldown before the sprint button is reactivated.

 

These values can be changed in CfgMovesFatigue.

 

There's no other factors, like damage for example.

Thanks very much. Ceeeb worked out the same in the fatigue dev thread, and I've successfully grafted the new values into my existing work.

Share this post


Link to post
Share on other sites

Wish BI would add limping animations for injuries, It be a long awaited feature, how hard can it be.  


 

Even this feature will be in dayzSA. BI please consider this ,you would make your long time fanbase  very happy.
 

Share this post


Link to post
Share on other sites

Can anybody confirm that the map sattelite textures look weird? Everything looks darked and blurry.

 

201510180000rc59ojd7uf.jpg

Share this post


Link to post
Share on other sites

Making language more consistent is more important than your tears.

 

Oh fuck off.

 

You and everybody else knows that outright changing scripting commands OR classnames alike is a terrible idea. You can deprecate a command all you want, but it should still be available.

Share this post


Link to post
Share on other sites

Can anybody confirm that the map sattelite textures look weird? Everything looks darked and blurry.

 

 

Ok, so I'm not seeing things then..

Haven't played in a while and all day today was thinking that something is off but couldn't really put my finger on it :P

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×