I've simply duplicated the "Ground" mover, and given it a different name ("Bob"). My unit can move perfectly fine with the "Ground" mover, but when I assign the "Bob" mover to the unit, with both the height map and pathing mode definitely both set to "Ground", the unit can no longer move.
Am I overlooking something? Is there anything else I need to change?
I've been looking for references on how to use sliders, all I can find is threads in which people discuss how they aren't yet implemented. Mind filling me in?
I'm wondering of there is some sort of triggers (or group of triggers) that will allow me to move a unit from the cargo of one unit to the cargo of another, even if the two are separated by much distance. So you would not be able to use the load/unload command.
I've since discovered that this only applies to units with hosted attachment models. In this case, when in fog of war, the attachment disappears, and the host model is the one that changes back to its original model scale unwantedly. If I take the attachment off, voila, the host works like it should.
So what about the attachment causes the host to change like that? This is the part that confuses me. Does anyone know?
I have a unit in my game, with an actor that is linked to a standard model. The "size" attribute of the actor is modified such that it appears to be half of the model's original size.
However, when I observe the unit in game, and it is visible (ie within sight range of one of my units), all is good. But when my units move out of sight range and the unit is hidden under fog of war (for of war visibility set to "snapshot" on both actor and unit), the model reverts to its original size.
I am not understanding the process behind this. How do I prevent it from happening? I have gone through all "fog of war" settings I could find on the unit/actor/model, but nothing seems to fix the problem. Help is much appreciated.
So after playing around for a bit, I've discovered that if you move the unit in the editor to where it shows up in the game, it stays in the same spot once the game is reloaded, indicating that shardfenix is correct.
However, I can't seem to find a setting anywhere? Does anyone know where I can find this?
I'm having trouble with custom footprints on my units, in that it causes them to be displaced by about 0.5 of a unit from what it is in the editor to what it actually is in the game. See these pitctures:
Interestingly, if you take the footprint off the unit, it's in the correct position in the game. Does anyone know what's causing this?
After multiple months of ignoring this problem, I've returned to it. The issue is definitely with the footprint, as when I remove the footprints that I make from a unit, the problem goes away.The custom pathing still works alright, so from what I can tell, it must be something to do with the placement check/apply settings, but after hours of playing around, there is apparently nothing to be found.
I would also like to know how to do this, as I am trying to create a custom function that takes a behavior as a parameter, but I currently don't think I can do this.
Thanks. I'm not too up on my pathing knowledge... the viking seems to "know" where the closest land is, Ie if you tell a viking to morph to assault mode when its close to a cliff, but still over water, it will move over to the land, and then morph where it can. Is this all pathing?
Is there some kind of validator that the viking uses when morphing from flyer mode to assault mode, so that it doesn't morph over water, (etc.)? I can't seem to find anything that suggests that it knows when it can morph or not (no validators to be found)
Apply a hidden buff via the trigger. Set actor events such that the buff on will create the one actor and destroy the other. On buff off, set the first to be destroyed and the second one created.
This will involve creating alot of actors and actor events, but it would probably be the same amount of work via triggers.
Voila, an elegant solution with no apparent side effects.
0
Hello!
I've simply duplicated the "Ground" mover, and given it a different name ("Bob"). My unit can move perfectly fine with the "Ground" mover, but when I assign the "Bob" mover to the unit, with both the height map and pathing mode definitely both set to "Ground", the unit can no longer move.
Am I overlooking something? Is there anything else I need to change?
Thanks
0
Well, I'm back, with the same questions. Does anyone have any answers?
Thanks
0
@ShadowDestroyer: Go
How does one specify between deep fog and near fog? I can only find one parameter: fog of war visibility.
0
@zeldarules28: Go
I've been looking for references on how to use sliders, all I can find is threads in which people discuss how they aren't yet implemented. Mind filling me in?
0.957798589432304
Hello,
I'm wondering of there is some sort of triggers (or group of triggers) that will allow me to move a unit from the cargo of one unit to the cargo of another, even if the two are separated by much distance. So you would not be able to use the load/unload command.
Thanks
0
@KrayzBlu: Go
I've since discovered that this only applies to units with hosted attachment models. In this case, when in fog of war, the attachment disappears, and the host model is the one that changes back to its original model scale unwantedly. If I take the attachment off, voila, the host works like it should.
So what about the attachment causes the host to change like that? This is the part that confuses me. Does anyone know?
Thanks
0
Hey,
I have a unit in my game, with an actor that is linked to a standard model. The "size" attribute of the actor is modified such that it appears to be half of the model's original size.
However, when I observe the unit in game, and it is visible (ie within sight range of one of my units), all is good. But when my units move out of sight range and the unit is hidden under fog of war (for of war visibility set to "snapshot" on both actor and unit), the model reverts to its original size.
I am not understanding the process behind this. How do I prevent it from happening? I have gone through all "fog of war" settings I could find on the unit/actor/model, but nothing seems to fix the problem. Help is much appreciated.
KrayzBlu
0
@KrayzBlu: Go
So after playing around for a bit, I've discovered that if you move the unit in the editor to where it shows up in the game, it stays in the same spot once the game is reloaded, indicating that shardfenix is correct.
However, I can't seem to find a setting anywhere? Does anyone know where I can find this?
Thanks.
0
@shardfenix: Go
Good idea, I'll look into that
Thanks
0
Hi All,
I'm having trouble with custom footprints on my units, in that it causes them to be displaced by about 0.5 of a unit from what it is in the editor to what it actually is in the game. See these pitctures:
Interestingly, if you take the footprint off the unit, it's in the correct position in the game. Does anyone know what's causing this?
Map File: Map File
Thanks
0
After multiple months of ignoring this problem, I've returned to it. The issue is definitely with the footprint, as when I remove the footprints that I make from a unit, the problem goes away.The custom pathing still works alright, so from what I can tell, it must be something to do with the placement check/apply settings, but after hours of playing around, there is apparently nothing to be found.
Has no one else run into this?
0
I would also like to know how to do this, as I am trying to create a custom function that takes a behavior as a parameter, but I currently don't think I can do this.
0
@BorgDragon: Go
Thanks. I'm not too up on my pathing knowledge... the viking seems to "know" where the closest land is, Ie if you tell a viking to morph to assault mode when its close to a cliff, but still over water, it will move over to the land, and then morph where it can. Is this all pathing?
0
Hey All,
Is there some kind of validator that the viking uses when morphing from flyer mode to assault mode, so that it doesn't morph over water, (etc.)? I can't seem to find anything that suggests that it knows when it can morph or not (no validators to be found)
Thanks
0
After a sudden epiphany, I figured it out.
Apply a hidden buff via the trigger. Set actor events such that the buff on will create the one actor and destroy the other. On buff off, set the first to be destroyed and the second one created.
This will involve creating alot of actors and actor events, but it would probably be the same amount of work via triggers.
Voila, an elegant solution with no apparent side effects.