Try to upload the mission here (or a simpler mission), that is helpful for developers to test out ;)

That could be possible, I will check it out tonight. Thanks!

Yeah, it's working now :)

Thanks, I will check this out tonight then. japa, this issue can be set as resolved then I think, if it works fine for SaMatra, must be something wrong with my set-up.
If I notice any other issue with this I will make a new issue (as I have been having some issues myself with items in uniforms/vest syncing to server, but that is a different problem)

SaMatra, are the containers variables cleared for you? They are not for me.

japa: will try this evening to get some images. Basicly, in the repro, there are two variables per clothing item (uniform & vest), oldUniform & uniformContainer, and oldVest & vestContainer. The oldUniform&oldVest variables are NULL when changed, but the container variables stay with the same data for me.

The oldUniform and oldVest variables do return NULL object, but the container variables are not, they are still filled with the same data as before changing uniform/vest.

I tried the repro out in DEV 29-4 124017, container variables in hint still not deleted.

I saw this in today's dev branch update: "Fixed: Shadows of H-barriers".
I'd say, go check out dev branch to see if the issue is fixed :)

this can be closed as resolved since #0015298 is fixed.

Just tried to reproduce this in a new mission, I couldn't. After some extensive I've found out that the problem lies at one of the custom uniforms that's in my mod. Sorry for any confusion caused, this can be closed.

This is why this issue is caused
#15298

The difference between the issue we had and you have, is that you're using weapon holders, and we are using simple createVehicle commands with model positions.

It seems the preset weapon holder positions are wrong then.

This problem is definetely fixed in DEV. We do not use weaponholders though, we use crates, so I couldn't tell you about that stuff.

Never mind, didn't read the arguments properly :)

Adding to this, I did some more testing with worldToScreen, and it seems quite inaccurate. It still gives back a position even though the object is not visible anymore on screen.
It seems like you need the screen to be at least [x] degrees away from the object before it gives back an empty position.

I'll create a new issue for this though.

• EDIT

Seems to be because of safezones. So this new command would still be useful to actually check if an object is in view or not.

I know it's possible, but it's not convenient at all to do it like that. A simple command likeobjectInFOV would be less code, and probably faster too.

If it is only able to be reproduced on BP... is it not a BP problem?

No problem, I hope this is easily fixable.

I have attached a new mission (JIPDamageTest.Stratis) which should make repro easier. The buildings should immediately look damaged.

I also added screenshots of before and after reconnect.

Additional notes on repro:

• Please use dedicated server, not in-game LAN server
• When you disconnect, make sure you disconnect completely, not lobby.
• I have just tested this on DEV branch of today, and this problem still occurs.

Any update on this? Could this be picked up while fixes are being placed for JIP-related behaviour on static objects anyways? (the issue where damage is multiplied if JIP players are on the server) I've tried in the dev-branch if this issue is fixed with these recent changes, but it doesn't seem like it.

Thanks!

@Killzone_Kid, my guess it's all static objects.

I have attached an example mission, and provided info again in the 'Steps To Reproduce" section.

Was a problem with mission instead.

You can, it's just that you can't place more than 144 GROUPS in one mission, so if you have lots of different AI groups you are going to run into this problem.

The problem is, this has been an issue I think since A1... But I agree that AI needs some fixing overall.

Either or:

• Have 150 players where each player is in a seperate group in a mission. It won't let you.
• Create 150 AI all in seperate groups. It won't work.

144 is the group limit per side.

My proposed solution would be type-specific arrays, similiar to C# for example.

Example:

myStringArray = array("String", ["1", "2", "3"]);
where first param is type, second the actual array. With this solution you would also need to be able to make custom types though, maybe in the config.

Other solution would be to use numbers to determine type instead of full string in the packets. I can't imagine this being any more painful to deal with engine-side... Probably actually easier than strings.

Cyborg, can you try this again in the devbranch? It should have been fixed, and it works for me.

I've tested it on today's DEV (124337). It's working good now (both on mission start and JIP, for both the uniform and uniform items), thanks for the fix japapatramtara!

Woo! Thanks japa :)
Will make sure to try it out when it gets there.

That sounds promising KK ;)

Cyborg, the part after your "OMG" is exactly why this ticket exists. As you said, addUniform only changes clothing locally, not globally.. as this ticket's name is (addUniform is not global)

Any update on this?

I thought this might get fixed with #18408, but this issue still occurs.

Example scenario:

• Player spawns in mission with certain uniform and items in uniform
• addUniform is used from client (player)
• On server, uniformItems still returns items that were in previous uniform, and not the items that are in the currently equipped uniform.

Some attention again to this issue would be nice.
I would suggest BI the following:

set-up a tool similiar to server package where no GUI is available. Might be a bit of work, but would make headless clients a solution more people could use.

This issue still seems to be there.. testscenario:

• Have a mission that doesn't end upon all players disconnecting
• Run mission on server
• Join client, execute command for example: "(whatevervehicle) setDamage 0.8;"
• Leave game
• Join back in
• See vehicle is not damaged anymore.

This also happens when you try to execute these commands on the server side and client joins, and can't see the damage. It seems to be some kind of desync issue with damage. I've only tried this with buildings btw.

I agree this would be very nice.

However, I do have my doubts it would be easy to implement. That it is not in there already, probably means that they do not have a way to get the call stack atm in the engine. But that is just my guess.

"Please keep the issue monitored to see when it is fixed."

10 months later... I shouldn't expect anything different though...
Maybe this is a good time to get it fixed, with Zeus "around the corner"?