I had asked you about reproducibility in current DEV which was released today, and your answer is about some state in the past.. well guy, I think we have a little misunderstanding here. And just by the way.. as I can see you prefer offence instead of a constructive debate. If I can offer you my two cents, this is not a good way how to ensure that people will react on your wishes and recommends in the future

best regards
japapatramtara

hope not.. are you still able to reproduce them?

this bug should be already fixed since DEV. 132618 ;-)

good to you ;-) btw. for the next time you want to post some log files to us, please remove command param -nologs before.. this little change could be really helpful than empty log :-)

Pershing:
please could you attach your report log(logging must be enabled) and we will take a look, but I guess that these reports are really connected to the allocator

interesting.. in fact there are more clues leading to the allocator. Please can you test it for longer period whether removing allocator has helped or hasn't?

do you have any additional info for this issue? Kind of action pattern like CTD occur when you fire from weapon or something.. Because without it, its really hard to help and everything we will do, will do as a blind fix :-(

DEV. 131649(will be distributed tomo)
I changed xxxContainer commands. Now their returns valid object or nullObject when failed. So you can use something like:
player forceAddUniform "U_B_FullGhillie_lsh";
waitUntil {!isNull uniformContainer player};

there is no other easy way how manage it

well If your repro is valid and if you run it under Dedicated server so its obvious that you will get nil. Just because command player should return null-object on dedi

look I'm trying to help, but its way difficult due to a lack of good clue. Repro doesn't say if your problem is related to MP or SP. Then you said something about server side.. well okay server side scripts can't use player(it always returns null-object), so we have a solution.. but now you're speaking about client code. Quite confusing, isn't? Please can you attach your log? Maybe it will help

btw:
let me give you an insider advice(just two cents): better repro we get --> bigger chance to add problem into our TODO list ;-)

Server side and unit is local? So you're speaking about direct hosting(no dedicated server)?

should be fixed since next TerrainBuilder update

DEV. 133047(will be distributed tomorrow - 23.10.2015)

I've just modified commands:

addWeaponItem
addPrimaryWeaponItem
addSecondaryWeaponItem
addHandgunItem

they will find proper muzzle for given magazine now. Or you can specify muzzleName through addWeaponItem like:

player addWeaponItem["arifle_MXC_Holo_pointer_F",["30Rnd_65x39_caseless_mag",15,"muzzleName"]]

hope this change will help ;-)

I can confirm a problem.. will be solved in a week

changes since DEV. 128618:

Added:
player addWeaponItem [weaponName,itemName(even magName)]
or
player addWeaponItem [weaponName,["magName",ammoCount,"muzzleName"]];

Also added:
removeSecondaryWeaponItem (same as removePrimaryWeaponItem)

changes:
addXXXWeaponItem/removeXXXWeaponItem now works also with magazines. Furthermore for AddXXXWeaponItems works additional syntax ["magName",ammoCount,"muzzleName"]

will be distributed tomorrow

should be fixed since DEV 131019

does this crash still occur?

and do you get frequently crashes even on a different MP maps or the problem is directly related to a King of the hill?

should be fixed since DEV. 128991

should be modified since DEV. 127012

sorry but I'm not able to reproduce this issue

should be fixed since DEV. 126973

please check it on Monday afternoon ;-)

Well the new DEV version with my patch has been already release, so can anyone check it again for me? :-)

DEV. 126875
two new scriptinng commands has been added - getPosWorld/setPosWorld

will be distributed within next DEV build

is this issue still active?

I have applied my patch with extended debug logs into DEV branch only, so please can you switch your A3 version into Development branch? And for more, can you try it on some 'official' maps like Escape from Altis, etc.?

jls1cm: any progress on this issue? We're still waiting for some new RPTs from the latest DEV distribution. Or it seems to be fine now?

by fullHD I mean that you probably play A3 in 1920x1080p screen resolution which can cause some performance penalty on slow computers. That's why I asked you to downgrade that resolution down let's say to 1280x720p. I'm only trying to be sure that your problems are not based on overheated hardware

And the next question: Did you try it on DEV version?

interesting.. well I've added into DEV. 126954 some additional logs which may help us to manage your problem, please try next DEV version(will be distributed tomorrow) and post some fresh RPTs okay?

And I know that you will hate me, but I have to ask you about your PC system stability in general. I see in logs, that you use FullHD resolution, can you try to downgrade it rapidly(I'm trying to eliminate HW overheat possibility)? Does your problem appear even in SP missions? Have you tried it within disabled Firewall?

sorry for bothering, but the fact is that we have currently no clues how to solve the situation.. unless you're Czech republic resident and will take a trip to our company with your whole PC in bag ;-)

should be fixed since DEV. 126086

MadDogX:

I though that pushBack command we successfully implemented and widely used by community. So please can you post additional information about a problem? Simple repro case would be the best

well pushBack command was successfully implemented and announced in http://dev.arma3.com/post/sitrep-00064 so we can close this task

DEV. 125892 - new command push_back introduced

should be fixed since DEV. 125466 and will be distributed tomorrow

This issue is not about TerrainBuilder, but Buldozer side. We already know what's wrong. Patch will be released soon

should be already fixed

should be fixed since DEV. 125058

fix should be already merged into DEV version

ouu yeah :-)

DEV. 126889
MoveInAny now returns true when moving were processed successfully(otherwise returns false)

patch will be distributed within next DEV release

just my 50cents: changes were made on data and code side. So Maybe you have a correct binary file, but still using an old version of Addons.

should be fixed in DEV. 124012(will be distributed tomorrow). So please give me a feedback whether my patch will really help

sorry, but I'm trying to understand you. Can you describe a concrete problem? Maybe with before/after image as attachment?

still not deleted or start returning <NULL-object>? Because variables oldUniform and oldVest are still present, but should lead to a NULL object

This problem should be already fixed since TB build ver 124233. Unfortunately that version hasn't been released yet, so please check it right after next iteration of A3 tools will be distributed

seems to work fine..

new version of TB which contains patch for this bug was already released last friday. Can anyone give me a feedback if it works now?

FIXED.
But cannot say when will be next release date. We have to solve(somehow) how to load binarized objects into TB.

it is a very good question, but definitely this is not the right place to ask, and I'm definitely NOT the right person who can answer :-) Imho MLOD objects is the only way how to work with TB, because of a fact that ODOL(binarized version) does not keep an important information about snap-points(for fences, etc..).

Thanks for an interesting idea. I have just listed them into my TODO list. For now I can only tell you a little workaround: You can RMB on working polyline and click on "Add Point here"

seems to be fixed now ;-)

can anyone give me a feedback If it works now?

FIXED

the next version of TB will be released with proj.dll(in a cases of errors we can also provide an older version proj_fw.dll). We didn't want to release TB with all extended dlls because of a two reasons: the first is about licensing stuff because many libraries cannot be simply released with the main package, and the second is about a get feedback from users which features of TB they really need and which can be silently removed ;-) TB is mainly gamemap editor so we're trying to separate it from many GIS features

will test it in the evening

Well what I can say, TB really know a way how to create roads from shapefile,however this feature is based on the proprietary module from VBS and unfortunately we cannot distribute it within main TB distribution. All this licence stuff is a longtime process, so be patience. I hope that we will be able to release that module too, but cannot promise it at the moment.

so I guess that everything goes fine now..

well migrating to a new GDAL would be quite difficult - for your information upgrade from 1.5 to 1.6 took more than a week in the past. About L3DT,.BT, etc. GDAL is one thing, but unless providing proper libraries in addition it won't be able to load those advanced formats. And problem with additional libraries is in a fact, that many of them are not distributed under a compatible licence(like GNU/GPL,..)

ok, so please could you write an email to me?

What I can say.. I've spent a lot of time to get the older package of tools(ver.58) in spite of a fact, that this is not an official BI tools distribution policy. Furthermore even of a fact, that We haven't got any other complain about Tools ver.60 and P3D models. And now, when all that things(asking managers, reverting Tool data server, preparing the package), so when all that thing is done(just for one community user, for you) you don't want it :-(

Well guy.. so now I can say only:

"Your task has been listed to our queue, please be patient and wait till we will find a time to take a look

sincerely
support guy"

sorry but that make no sense. your're saying that Tools ver.58 work fine for you(techrep #00005) but ver.60(#00006) don't? I agree that I have changed many things in TerrainBuilder P3D logic(both MLOD and ODOL) and I have no problem to give you TB from Tools ver.58, but I'm nearly sure that no major changes were done in ObjectBuilder and Binarize.

So can you specify your problems with these tools?

No longer binarises WRP? It's really strange because the version you have is same as the version which currently being used by our map designers. Yes it is possible that TB is no longer supporting older versions of P3D, but I can take a look whether we can change that situation.

so when I will give you an older version than April 10th you would be happy? ;-)

so you need an older version of TB, or the whole tools? Because I guess that old common tools package can be downloaded from the web without Steam. And about TB: you can write me a mail on '[email protected]' and will see what I can do for you ;-)

deanosbeano:
Just For My Information:
what does "keep that guy away from the original Bat files" mean? Who should be "that guy"?

and about your complains:
I've just attached a picture of Template properties window where you can see a row named P3D version. So please can you provide me a version of a affected(broken) object? And furthermore It would be great help when you attach the object to this task.

About view textured objects: this feature are no longer supported because of a huge changes in p3d format

We're currently working on support for binarized p3d's ver 59. Also we have to apologize for inconvenience. TB you have got into your hands is exactly the same product as TB that is being used by us for many years. The problem is in a fact, that we're working with non-binarized models and obviously these are not available for public usage. Well and we have completely forgot on this small difference :-)

thanks guys. You all have just discovered an interesting fact. New unique ID technology is designed for 4B scalar values(int), but whole A3 scripting mechanism is working with numbers represented as floating point based type. So precision is guaranteed for 22bits only(about 4mio). Well going to disable the whole uniqueID system and have to find out a better solution

k0rd: can you write a repro here? Even the simple one will be very helpful..

Can someone give me a feedback whether my patch has fixed the problem?

should be fixed in DEV. 116154 (will be distributed tomorrow)

FIXED since DEV. 116071

Hi, there were some heavy arguments why we have decided to modify ClearXXXGlobal commands to work on owner's machine only. But obviously we can't say: "Hi community guys.. sorry for inconvience, but you have to change all your scripts". So within a day I will revert this change and try to find a better solution

FIXED in DEV. 116041 will be distributed tomorrow.

Unfortunately task #0016979 is not a duplication but the stand alone task. This one was completely about SP but #0016979 is because of a network code

And can you reproduce this bug even in SP?

fixed in DEV 116103

got repro.. will be fixed next week

I made some changes in code a some months ago, so I guess that it should be already fixed even in Stable version.

FYI: KK has found a repro how to dupe items through "fast clicking", but his repro is quite difficult and for certain reasons I won't describe it here(you can ask him anyway)

I'd say that this issue should be already fixed. Can anyone confirm my guess?

Never mind... since DEV. 114900 radio slot will be re-scan right after assigning of itemRadio. Let's make A3 consistent

it seems to be OK now

Killzone_kid: you owe me two hours of my life ;-)A3 is processing EETake even for radio, but you can't get an information from sidechat, because action Take is being processed before simulation in which Soldier checks its slots(radio, nvg, ..). So I can modify code to call slot items scan right after proper action, but I don't know if it is really necessary

FIXED since DEV.114819 (will be distributed tomorrow)

should be fixed since DEV 125317 and will be distributed today(19.6.2014)

seems to work fine now...

sry I was off for the most of January due of a personal reasons. That's why I didn't react.

Anyway this issue should be fixed in DEV. 114805(will be distributed tomorrow).

I've just added some new commands, so take a look at:

isLightOn
isCollisionLightOn
setPilotLight
setCollisionLight

will be distributed since DEV. 127346(probably tomorrow)

oh.. well one is down, many are waiting ;-) ok going to close

already resolved for months

interesting.. dupe items through clicking at same time on two machines is one thing(which takes at least weeks to find out a proper solution), but this one is a stupid bug which has to be fixed asap. I promise, that I will take a look tomorrow and will bring a fresh news.

Yep your idea is not bad, but has two big bottlenecks. When we will make a stand alone slot for grenades, we have to do it for each muzzle of weapon "Throw"(7xSmoke,1xHG,4xchemlight,1xIR) which is a problem, and the second one: we do not allow to throw any throwable items(HG,smoke,..) when soldier has no uniform or vest to store those items in. We can speculate that he can have at least one throwable item stored in his pants, but.. you know ;-)

But I already made a solution. Unfortunately I can't provide it to a public yet. I do not know if this is a public information or isn't, but anything which won't be finished until this friday, won't be published in this year at all. The next Dev version(next after friday's one) will be some when in a january

well a lot of work have been made today.. to be continued ;-) but just for your information: _container = vestContainer player; --> "xxxContainer" command has been declared as a UNSAFE which means that it could leads to a strange behavior (just like it was described in your thread) because "naked" container entity has no information about soldier who is wearing that container. So problem with grenades is about a fact, that grenade has its own special rule which says that grenade magazine is loaded into Throw weapon but is still present in owner container like vest, etc.. so when you "hard" clear that container, game currently has no mechanism how to get that situation..

anyway.. I'm working on a proper solution how to use vest/uniformContainer and take no care about these thrash on a background

you guys are really killing me :-/

Thanks for really nice and descriptive repro!! I've made some changes in magz loading mechanism because of a Multiplayer code, so a bug were made :-( Going to fix it immediately

wow another day, another resolved task.. another beer for japapatramtara ;-)

so I guess we can close this issue as Resolved?

should be fixed since DEV. 124416 (will be distributed tomorrow)

well the thing goes just like KillzoneKid described. When player drop its backpack, so that backpack will be placed into the ground via groundWeaponHolder(Entity) which means that engine will lost an information about dropped backpack as a standalone world entity and whole simulation and render behavior will be assigned to a created weaponHolder. So if you think you see a backpack in front of you - you see nothing but the one of dummy proxies(from weaponHolder.p3d) replaced by a backpack shape model.

You will be still able to add/remove items into backpack through assigned variable, but you definitely won't be able to work with them as a standalone entity(moving, deleting, etc..)

this behavior has been implemented as a part of further design document(section: interaction with a content placed on a ground and/or crate). In fact, before "last update(your word code34)" the behavior went against design document(backpack was placed on a ground directly as an entity) so I have just fixed the bug :-)

code34: JFI - I really don't like the way you're speaking to another community members. Let me be quite personal.. well I'm not so well informed about community peoples but from my point of view: peoples like KillzoneKid, Samatra, etc. have already done many nice things, workarounds and bug reports so I'm hardly sure that KillzoneKid is not unskilled noob or troll. For the other hand, the only thing I know about you is you are not so polite to others ;-) Just my two cents

but gets back to a real problems: this is not a bug, but the design decision. Every engines have theirs limitations and this is one of them

Maybe I can add some kind of scripting command like [GetEntityOwner()] which returns owner weaponHolder so you will not have to use any workarounds

much more design issue than program bug

DEV. 12493
[FIXED] - addUniform doesn't check uniform allowance

DEV. 127033
two new scripting commands were introduced - addBackpackGlobal and removeBackpackGlobal

will be distributed tomorrow