The Unit Compare Order Count validator has fields that ask for specific ability and index. I think this means that it can only check for that specific ability, not all commands in general; correct?
I suspected it was unit order queue, unit order, unit state, unit kenetic, but none of them is it. This is like a needle in a haystack. Does anyone know?
I am using unit order count and unit compare speed to fill this need; but does an actual idle validator exist?
Pardon me, if my suggestions are very basic; but its usually the simple stuff that slips our minds. So, have you looked into:
1. if the texture file name matches exactly with the texture name used by the model.
2. test using a swap by id 'using the same' texture name you need.
3. overwrite the original texture by re-importing the new texture 'while using the same texture name'
4. verify the file path to the textures is correct default
5. check for any typos in the texture name and slot fields during the texture id swaps and tests
beyond that, the only way i know to link a texture is to either overwrite the original texture name by importing, or export and modify the texture name in a modelling program.
Thanks, i will look into those upgrades, but at first glance, they seem to only change a few fields relating to damage, speed, armor and etc (basic fields).
I have not yet seen anything related to radii levels. I will investigate further.
I have an assumption that the Weapon Level field directly affects splash radii.
As in; if the the weapon (ie: Psionic Shockwave) has 3 levels of splash radii scans, then the splash radius index 1 and 2 are not used (only index 0 is used) 'if the weapon level is level 1. - or am i wrong, and that all 3 splash scans are always in-effect.
Is this correct? If not correct, then please explain what the Weapon Level field does and what it affects.
Also, does anyone have a link to more advanced data editing tutorials dealing with abilities, behaviors and validators? - any of them.
Any advanced tuts or starting points would be appreciated. I have searched and found only basic beginner tutorials that are no longer helpful to me.
Indeed, leash settings. It seems if the unit object leash settings are set to -1, then it uses the max leash allowed by GameData. My current thoughts are to use leash of 50, and reduce incrementally based on lag level.
And yes again, lag will be terrible if you go max. No, I don't have an alternative to this solution, except to not use leash and instead, rely on behavior, scan, issue order with validators to avoid un-necessary scans.
Soooo, if anyone has an alternative solution to manipulate general unit actions, please chime in.
I am trying to get my unit to acquire targets at a farther distance than default. As in, when they are attack moving, they will engage enemies en-route.
I assume they are acquiring enemy targets based-off a distance setting. As I searched for answers, I thought this distance was controlled by the weapon's - minimum scan range field.
I have set the weapon Minimum Scan Range to several test numbers, 3, 10, 20, 30, 50, 500 (max). The unit responds to the weapons Minimum Scan Range 3, 5, 10, 20 as expected; but it seems limited to a range of roughly 24.
The unit will not engage enemies at a distance farther than 24, even if i set the weapon's minimum scan range to 500 (max). notes: weapon scan filter visibility flags - allowed, unit use line of sight - disabled.
Does anyone have a solution, information, tutorial or starting point to look for a solution?
Solved, wow, i always miss the the most simplistic reasons. So I used that as a premise to start my problem solving process over and found the problem.
To allow certain units through, you need to look at the collision flags field in unit object. Footprint pathing only allows pathing. They must be used together to do what you want. Don't change the mover for the unit unless you have to or unless it makes more sense to do so per your specific goals; it will cause relational problems with other units and pathing.
Also, there is a radius field in unit objects. One of the radius fields is related to structural collisions.
Sometimes the most obvious things eludes us eh? I have been using issueOrder - attack unit, with move commands instead of issueOrder attack point. thanks.
I've done this via footprints. Make a custom footprint for the structure that can allow pathing through it. Or, change the mover for the unit that is trying to pass through. ie: change the mover from ground to colossus or burrow.
They must be used in tandem with collision flags located in the unit object.
These are only two ways off the top of my head, several more exists. For instance, do you really need an actual building, or can you use a doodad without a footprint at all.
0
So, how do you do it?
Edit: oops, this is probably in the wrong forum. apologies
0
I have been rummaging through the wiki, data, data structures looking for documentation on filters.
Specifically I want to know if the 'stasis' filter applies to units that have been grav lifted by the phoenix.
If stasis is not it, then what does stasis refer to and what flag is used to check/validate if a unit has been grav lifted?
0
@StealthToast: Go
That is it! This is what I have been looking for, leaving it blank is the answer.
This also means, the other validators may behave in the same way, if I leave fields blank, it may default to 'all'.
Thank you so much.
0
@Ikoter: Go
close editor, log into bnet, open editor, check to see if that fixes it.
0
@StealthToast: Go
The Unit Compare Order Count validator has fields that ask for specific ability and index. I think this means that it can only check for that specific ability, not all commands in general; correct?
0
I need a validator to validate my unit is idle.
I suspected it was unit order queue, unit order, unit state, unit kenetic, but none of them is it. This is like a needle in a haystack. Does anyone know?
I am using unit order count and unit compare speed to fill this need; but does an actual idle validator exist?
0
@R0binicus: Go
Pardon me, if my suggestions are very basic; but its usually the simple stuff that slips our minds. So, have you looked into:
1. if the texture file name matches exactly with the texture name used by the model.
2. test using a swap by id 'using the same' texture name you need.
3. overwrite the original texture by re-importing the new texture 'while using the same texture name'
4. verify the file path to the textures is correct default
5. check for any typos in the texture name and slot fields during the texture id swaps and tests
beyond that, the only way i know to link a texture is to either overwrite the original texture name by importing, or export and modify the texture name in a modelling program.
0
@Terhonator: Go
Thanks, i will look into those upgrades, but at first glance, they seem to only change a few fields relating to damage, speed, armor and etc (basic fields).
I have not yet seen anything related to radii levels. I will investigate further.
0
I have an assumption that the Weapon Level field directly affects splash radii.
As in; if the the weapon (ie: Psionic Shockwave) has 3 levels of splash radii scans, then the splash radius index 1 and 2 are not used (only index 0 is used) 'if the weapon level is level 1. - or am i wrong, and that all 3 splash scans are always in-effect.
Is this correct? If not correct, then please explain what the Weapon Level field does and what it affects.
Also, does anyone have a link to more advanced data editing tutorials dealing with abilities, behaviors and validators? - any of them.
Any advanced tuts or starting points would be appreciated. I have searched and found only basic beginner tutorials that are no longer helpful to me.
0
@FunkyUserName: Go
Indeed, leash settings. It seems if the unit object leash settings are set to -1, then it uses the max leash allowed by GameData. My current thoughts are to use leash of 50, and reduce incrementally based on lag level.
And yes again, lag will be terrible if you go max. No, I don't have an alternative to this solution, except to not use leash and instead, rely on behavior, scan, issue order with validators to avoid un-necessary scans.
Soooo, if anyone has an alternative solution to manipulate general unit actions, please chime in.
0
I am trying to get my unit to acquire targets at a farther distance than default. As in, when they are attack moving, they will engage enemies en-route.
I assume they are acquiring enemy targets based-off a distance setting. As I searched for answers, I thought this distance was controlled by the weapon's - minimum scan range field.
I have set the weapon Minimum Scan Range to several test numbers, 3, 10, 20, 30, 50, 500 (max). The unit responds to the weapons Minimum Scan Range 3, 5, 10, 20 as expected; but it seems limited to a range of roughly 24.
The unit will not engage enemies at a distance farther than 24, even if i set the weapon's minimum scan range to 500 (max). notes: weapon scan filter visibility flags - allowed, unit use line of sight - disabled.
Does anyone have a solution, information, tutorial or starting point to look for a solution?
Solved, wow, i always miss the the most simplistic reasons. So I used that as a premise to start my problem solving process over and found the problem.
0
@Ari2010: Go
To allow certain units through, you need to look at the collision flags field in unit object. Footprint pathing only allows pathing. They must be used together to do what you want. Don't change the mover for the unit unless you have to or unless it makes more sense to do so per your specific goals; it will cause relational problems with other units and pathing.
Also, there is a radius field in unit objects. One of the radius fields is related to structural collisions.
0
@MaskedImposter: Go
Sometimes the most obvious things eludes us eh? I have been using issueOrder - attack unit, with move commands instead of issueOrder attack point. thanks.
0
To anyone who knows:
1. How do I get units to respond to attacks while en-route to a location from an IssueOrder - Move Effect.
2. How do I reference the target of a previous search effect, to check to see if that target is still alive.
I am messing with markers to find the target unit of a previous search effect, but i think i need a tutorial or something.
0
@Ari2010: Go
I've done this via footprints. Make a custom footprint for the structure that can allow pathing through it. Or, change the mover for the unit that is trying to pass through. ie: change the mover from ground to colossus or burrow.
They must be used in tandem with collision flags located in the unit object.
These are only two ways off the top of my head, several more exists. For instance, do you really need an actual building, or can you use a doodad without a footprint at all.