Piccolo
Well-known member
Piccolo updated Chronocrash Modders Tools with a new update entry:
Changelog 0.6.20
Read the rest of this update entry...
Changelog 0.6.20
Read the rest of this update entry...
ChronoCrash Modders Tools 0.7.7.2
- Thread starter Piccolo
- Start date
O Ilusionista
Captain 80K
So far, no bug found 
Yeah i meant to write that dropv i always used after attackbox not before it even if they apply to the same frame , or maybe it never really mattered like the manual implies it did ?
Code:
dropv {height} {speedx} {speedz}
This command controls opponent's flight path during his/her FALL animation.
{height} controls falling speed in y axis. It works the same with {height} in 'jumpframe'.
{speedx} controls falling speed in x axis. It works the same with {speedx} in 'jumpframe'. Bear in mind, that this setting is relative to this entity's facing direction not opponent's.
{speedz} controls falling speed in z axis. It works the same with {speedz} in 'jumpframe'.
Use this command with knockdown attackbox of course. However it must be declared AFTER that attackbox.
Though, this also works with non knockdown attackbox if it manages to knock down other entity. Usually happens against enemies with 'knockdowncount -1' or at least jumping or falling entities.
It doesn't. The legacy manual tends to make a lot of assumptions and does a bit of hand holding to avoid potential confusion. Admirable, but tends to have the opposite effect in the long run.
DC
O Ilusionista
Captain 80K
Buddy, I am using the latest version and I realized when you draw a new bbox (legacy), the default valeu the tool add for Z is 50, which is too much:
Could it to not add any value on the Z, like it was before?
Because 50 means 50 pixel back and 50 pixel front, which turns to be 100px and its too big.
Could it to not add any value on the Z, like it was before?
Because 50 means 50 pixel back and 50 pixel front, which turns to be 100px and its too big.
Piccolo
Well-known member
I don't understand, nothing has changed, it doesn't add z value. Maybe it's a special situation but even when I test on my end, it doesn't add z value
@Piccolo Same here, tested the version 6.20 to confirm but had no Z value added.
Buddy, does it happen using the green "+" icon or when using the "set visual prop" button?
O Ilusionista
Captain 80K
Clicking in "set visual prop" and choosing bbox.
Also, the option "disable box border" is always turn back on when you the tool and open it again
O Ilusionista
Captain 80K
Piccolo
Well-known member
I see. You can see that the value was already 50 on the left, before you drew the box.
It seems that for some reason CMT is taking this as default Z value when not set. I don't think it's new though, probably here since a long time.
You probably set the z value to 50 one time in an animation and then it reused it wrongly.
I'll make it so that it doesn't reuse the previously set value for newly created boxes.
O Ilusionista
Captain 80K
Maybe, but it never had added 50 as value before the last update.
Piccolo
Well-known member
Probably because you rarely set bbox z value manually. I just checked it's a very old bug. It has nothing to do with the value 50 or something, it just takes whatever value is there when the value of the new focused bbox is unset or is 0.
Basically it's a bug related to how bbox work. When you don't set z values it's not equal to 0, so when no value is set it was ignored so as to not replace it 0, and because it was ignored it can take the value of previous bbox. Need to adjust some things to avoid that.
O Ilusionista
Captain 80K
Yes I know - I forgot the default value (I think its 20 or something close to that, would need to search in the source code).
Piccolo
Well-known member
I think it something related to grabdistance or something.
But basically this is why there's a bug with this field. For any other field its straightforward, no value can be considered as 0, but not in this case.
O Ilusionista
Captain 80K
Yes, it is one of (many) things tied to grabdistance. Once you lower the value of the grabdistance, if effects all the boxes.
You can see it action on my Avengers game if you go to replay mode with Wolverine - its hard to touch the branch arrow with him.
That is a good question. @DCurrent @Kratus any clue?
@Piccolo , @O Ilusionista
Yes, it is technically possible,albiet undefined behavior. Nothing in the engine prevents negative Z values. In theory it would just end up reversing the Z depth calculation, but I never tested.
Edit: Actually it would be no different than negative X or Y, and might even be useful in certain edge cases. Best to not use negative as a flag.
DC
Yes, it is technically possible,
Edit: Actually it would be no different than negative X or Y, and might even be useful in certain edge cases. Best to not use negative as a flag.
DC
Last edited:
Piccolo
Well-known member
Ok so probably not a big deal if I prevent the user from setting negative value and use -1 as the "not set" value.
I must use an explicit number value for the not set value (can't use null) because those fields are present in the right form with the spinners. Those spinners are connected to the internal model so that they can read/write from/to it, and they only work with numbers.
I must use an explicit number value for the not set value (can't use null) because those fields are present in the right form with the spinners. Those spinners are connected to the internal model so that they can read/write from/to it, and they only work with numbers.
