General Discussion (dev branch)

[I give up 152]

-malloc=tbb3malloc_bi

is extremely outdated version of allocator ...

please use up to date one

-malloc=tbb4malloc_bi

Actually, ttb4 behaviour is similar to system (windows allocator) malloc. Loads memory in bulks which may seem nice at start, but with time degrades performance, affecting also negatively cpu and gpu performance.

In my end tbb3 is the one that performs better in matters of stability.

But this is not  simple and plain subject, since our hardware configuration is a crucial factor, probably for some others tbb4 wil perform, better.

[Dwarden 1125]

I find that claim hardly true considering several dozens major bugs unfixed in TBB3 vs TBB4 even just in allocator areas

technically all allocators but TBB4 should be removed from the distribution as badly obsolete and outdated (not even on latest codebranch builds)

TBBv3 was made for A2 not A3 and even then replaced with TBB4

in fact TBB3 is so obsolete you can't even find it easily for download anymore

if you think there is bug in TBB4 then I suggest you contact Intel https://software.intel.com/en-us/forums/intel-threading-building-blocks

so they fix it for everyone

also you can try talk to Torndeco as after Fred41 he is probably the best person in community to discuss allocator related problems

[I give up 152]

I am using the tbb3 that comes with game, inside DLL folder.

Like I have said, in my end is the one that gives better resuts in matters of stability Less RAM usage, better refresh/flush timings, but that's me and mine hardware configuration.

[x3kj 1247]

i think TOW wouldn't care about sthora, since they're beam riding, if i remember correctly. ;)

TOW is wire guided. Missile has IR-light in it's back so the guiding system can tell it's position. If shtora blinds the launcher, the launcher can no longer tell where the missile is at -> garbage controll commands are issued -> missile hits the dirt.

[R3vo 2654]

Todays update introduce a script error in Eden when opening the attribute window of a unit or mission.

 

I have not rpt file, unfortunately, but I guess the screenshot should work just as good.

 

 

 

Btw: Good job on the interface scaling, was much needed. However, would there be a possibility to introduce a new setting for interface size which only affects Eden? Right now I am playing on Normal size and 1920x1080. The size works alright everywhere except for the Eden interface. It feels too large.

[Fiddi 68]

Btw: Good job on the interface scaling, was much needed. However, would there be a possibility to introduce a new setting for interface size which only affects Eden? Right now I am playing on Normal size and 1920x1080. The size works alright everywhere except for the Eden interface. It feels too large.

 

Yes, I agree. Currently with the "small" interface, the Eden sidebars take up ~50% of the screen, it was fine before, so maybe scale it differently?

 

Also, seems that the Taru pods still aren't in Eden, I can't find them anywhere.

[h - 169]

Yup, gotta agree, using interface size "small" equals massive Eden..

[R3vo 2654]

Any chance the get/setUnitLoadout will make it into 1.58, or is it still too early?

[chortles 263]

Any chance the get/setUnitLoadout will make it into 1.58, or is it still too early?

Based on a prior SITREP v1.58 is in data lock other than weapon switching, so I doubt it.

[bad benson 1733]

is that basically the same as bis_fnc_saveInventory and *_loadInventory?

[Freghar 73]

is that basically the same as bis_fnc_saveInventory and *_loadInventory?

Yes, except it actually works now (for weapon attachments). :) Even on stable, just undocumented.

I have a feeling that it "modifies" just differences, not remove all + add saved as the other solutions - based on my observations of inventory item ordering. This could be an issue for mods that rely on a specific item order (ie. ACRE2 and multiple radios), but otherwise seems fine.

[R3vo 2654]

is that basically the same as bis_fnc_saveInventory and *_loadInventory?

 

Not really. Yes it saves the complete loadout to a variable, however, not directly into a namespace. Additionally there are some other options missing.

 

However, if one combines setVariable + getUnitloadout, one can use it as the bis fnc saveInventory function.

missionNamespace setVariable ["inv",getUnitLoadout s2]  //0.0146 ms

[s2, [missionNamespace, "inv"]] call BIS_fnc_saveInventory //30.9091 ms

Pretty fast...

 

 

Even on stable, just undocumented.

 

 

So it is on stable already?

[vincen 18]

Hi.

 

In 1.58 there is a bug - lock system can't be turned off on turrets =((

Doesn't work at all:

allowTabLock=0; //CfgVehicles
canLock=0; //CfgWeapons

[dr. hladik 231]

 

Hi.

 

In 1.58 there is a bug - lock system can't be turned off on turrets =((

Doesn't work at all:

allowTabLock=0; //CfgVehicles
canLock=0; //CfgWeapons

 

Yes, there are some changes, new features and new bugs.

Please read https://forums.bistudio.com/topic/189734-targeting-improvements/.

 

allowTabLock  - will not disable locking, only Find_next_target functionality (should still work)

canLock - now it just describes if weapon can be locked (guided missile), however if vehicle has some scanner (ir, nv, laser), then vehicle is able to mark that target.

 

So, if you want to disable any marking, you need to remove scanners.

And if you need to remove marking only for some turret positions - you need to wait a day, or two, as we have not yet introduced possibility of this combination...  :unsure:

[da12thMonkey 1943]

Reading the logistics section of yesterday's SITREP #152 regarding the improved weapon animations sources. Therein it says:

It should even be fully backward compatible!

But testing recently, I noticed the old Zeroing2 source doesn't seem to have carried over - the GL red-dot on the MX, Katiba, TRG etc. has stopped rotating (OP_eyeN memory points cycle through the various angles when zeroed, it's just the animating parts on the weapon).
 
Obviously that could be fixed by updating models to use Zeroing.1, but it would be nice if the old anim source continued to work like reloadMagazine2 apparently does without replacing with reloadMagazine.1.

I'm assuming there should be no conflict, having sources called Zeroing2 for legacy second muzzles and the new Zeroing.2 for a 3rd muzzle since the reloadMagazine equivalents work.

 

btw, I miss the feedback tracker for this sort of thing :D

[R3vo 2654]

Eden Editor

• Added: A new trigger attribute forcing the trigger to be simulated only on the server

 

 

How exactly does that work? Does that mean the trigger can only be activated by an object which is local to the server, or does it mean that the code will only be executed on the server?

[Dwarden 1125]

newly in today's DEV branch :

•Added: Support for muting the VON channels in the server.cfg

•Tweaked: The VON and chat channels are now separated

disableChannels[]={channelID, channelID, ...}; //old method

disableChannels[]={{channelID,chat<bool>,voice<bool>},{channelID,chat<bool>,voice<bool>},...}; //new method

the server.cfg setting will work for server with mission w/o any channels defined in disableChannels[]={}; within description.ext

mission which use https://community.bistudio.com/wiki/Description.ext#disableChannelswill override the server.cfg setting

and scripting command enableChannel will be changed (unfortunately this change is not backward compatible)

[killzone_kid 1333]

To add to Dwarden's post

Old channelEnabled (deprecated)

channelEnabled 3; //true

New channelEnabled

channelEnabled 3; //[true, true]

[vincen 18]

And if you need to remove marking only for some turret positions - you need to wait a day, or two, as we have not yet introduced possibility of this combination...  :unsure:

 

Remove concretely marks - easy =).The main problem for me now is how to disable name of vehicle when locking. May be it's posible to add function in cfgDifficulties? 

[danny96 80]

I have multiple problems in current DEV version:

1) Can't Drag&Drop from Left-side menu in editor anymore! Was that feature intentionally deleted for some reason?

2) Eden interace is so big now - editing space is smaller now.. why?

3) Also when using Eden Enhanced all edited units get their parts damage set to 1 so everyone edited just dies.

[R3vo 2654]

2) Eden interace is so big now - editing space is smaller now.. why?

 

The interface now scales with the interface size set in the display options

 

3) Also when using Eden Enhanced all edited units get their parts damage set to 1 so everyone edited just dies.

 

There's a bug in a function which sets the values to 0 for all attributes which use the slider control. However, keep in mind that I cannot guarantee that 3den Enhanced works on dev branch

[gippo 38]

Great stuff with VON! 

Will these channel enable/disable changes be in 1.58?

[Freghar 73]

Not really. Yes it saves the complete loadout to a variable, however, not directly into a namespace. Additionally there are some other options missing.

Which basically means it's the same. :) (See original post.)

 

However, if one combines setVariable + getUnitloadout, one can use it as the bis fnc saveInventory function.

missionNamespace setVariable ["inv",getUnitLoadout s2]  //0.0146 ms

[s2, [missionNamespace, "inv"]] call BIS_fnc_saveInventory //30.9091 ms

Pretty fast...

Strictly speaking it's not the same, BIS_fnc_*Inventory doesn't store the loadout as the variable itself, it uses a hardcoded "bis_fnc_saveInventory_data" variable, which (IIRC) is an array of [name, loadout, name, loadout, ...] where "name" is the loadout name given to the function. This confused me a lot when I was checking for isNil on the "name" and it always matched. :)

The new approach via scripting commands is infinitely better. With the new (today) option of taking a class name, it's nearing feature parity with the BIS functions.

 

So it is on stable already?

In some limited form, yes, it seems to be working well for me. I saw it first here - https://forums.bistudio.com/topic/151099-scripting-discussion-dev-branch/page-43#entry2990022, though note the comments below it.

[Fiddi 68]

Today's devbranch update introduced this error with the RCO scope:

23:22:09 Warning Message: Cannot load texture a3\weapons_f\acc\data\scope_inside_sharp_ca.paa.
23:22:09 Warning Message: Cannot load texture a3\weapons_f\acc\data\collimdot_dot_red_ca.paa.
23:22:09 Warning Message: Cannot load texture a3\weapons_f\acc\data\scope_inside_blur_ca.paa.

And made the scope glass black and white, unable to be viewed through.

[pettka 694]

Today's devbranch update introduced this error with the RCO scope:

23:22:09 Warning Message: Cannot load texture a3\weapons_f\acc\data\scope_inside_sharp_ca.paa.
23:22:09 Warning Message: Cannot load texture a3\weapons_f\acc\data\collimdot_dot_red_ca.paa.
23:22:09 Warning Message: Cannot load texture a3\weapons_f\acc\data\scope_inside_blur_ca.paa.

And made the scope glass black and white, unable to be viewed through.

A good catch, thanks a lot for Intel, sir. It should be fixed by today's Dev-Branch update :icon_twisted: