ChronoCrash Modders Tools 0.7.8

[O Ilusionista]

Buddy, I think I got a strange behaviour on how CMT preview the drawmethod flipx (an amazing feature, btw). I had an issue like this on Vega, but now I managed to replicate it.

Take a look at this video - when you preview the animation in CMT, it works fine (after you changed the offset to match the change made by drawmethod flipx). But once you see it in game, it gets misaligned

as you can see, the image isn't symmetrical:


if you need, I can send you an updated version of the game where this issue happens.

edit: when I disabled the new offset, the animation works fine. So maybe CMT is displaying it wrong?

extra point: right now we need to use drawmethod flipx 0 to cancel the preview, but would be possible to add "nodrawmethod" as an option too? Its a shortcut to disable any active drawmethod.

 

[Piccolo]

Buddy, I think I got a strange behaviour on how CMT preview the drawmethod flipx (an amazing feature, btw). I had an issue like this on Vega, but now I managed to replicate it.

Take a look at this video - when you preview the animation in CMT, it works fine (after you changed the offset to match the change made by drawmethod flipx). But once you see it in game, it gets misaligned

as you can see, the image isn't symmetrical:
View attachment 6308

if you need, I can send you an updated version of the game where this issue happens.

edit: when I disabled the new offset, the animation works fine. So maybe CMT is displaying it wrong?

extra point: right now we need to use drawmethod flipx 0 to cancel the preview, but would be possible to add "nodrawmethod" as an option too? Its a shortcut to disable any active drawmethod.

So how does the engine flip the sprite ? Using 0, using center of sprite, or using x offset ?

 

[O Ilusionista]

@DCurrent can confirmt this but as far as I know, OpenBOR trim the sprites on the fly.
This is why the engine uses the x offset and trim the image and use this value to flip.
IOW, it uses the X offset.

I just can't remember it this works for scale too (this is why I always put the axis in the center of an sprite when I need to scale x and y)

 

[Piccolo]

@DCurrent can confirmt this but as far as I know, OpenBOR trim the sprites on the fly.
This is why the engine uses the x offset and trim the image and use this value to flip.
IOW, it uses the X offset.

I just can't remember it this works for scale too (this is why I always put the axis in the center of an sprite when I need to scale x and y)

Then yes I'll need an example to work and adjust

 

[O Ilusionista]

Just make it to use the xoffset, like you did on scalex (it works like in game, I just tested it):

The image I use here is not symmetrical too, but works as it should

 

[Piccolo]

Just make it to use the xoffset, like you did on scalex (it works like in game, I just tested it):

The image I use here is not symmetrical too, but works as it should
View attachment 6309

Well it does use xOffset. But I guess maybe the engine needs the offset to be flipped too ?

 

[O Ilusionista]

But I guess maybe the engine needs the offset to be flipped too ?

I dunno about this. The issue here is that the engine used a trimmed image to apply the drawmethod, but CMT uses a non-trimmed one. So the values won't match.

Also, as you can see in the video above, the bbox position changes based on the sprite scale, but this doesn't happens in-game (all the boxes are independent of the image scale)

 

[Piccolo]

I dunno about this. The issue here is that the engine used a trimmed image to apply the drawmethod, but CMT uses a non-trimmed one. So the values won't match.

I don't think that's it, or else there would be issues with offsets of non flipped sprites too

 

[O Ilusionista]

I don't think that's it, or else there would be issues with offsets of non flipped sprites too

But you do have issues with non flipped assets too - if you change the offset to match the flipped image, you need to copy the original offset to the non flipped images or they will get misaligned (you can see this on the first video)

Here, take a look how I had to copy the original offset to fix it:

EDIT: a better image to show what I mean


While in game, I can just use drawmethod flip without caring abourt the offset.

 

[Piccolo]

But you do have issues with non flipped assets too - if you change the offset to match the flipped image, you need to copy the original offset to the non flipped images or they will get misaligned (you can see this on the first video)

Here, take a look how I had to copy the original offset to fix it:

EDIT: a better image to show what I mean
View attachment 6311

While in game, I can just use drawmethod flip without caring abourt the offset.

You do use flipx here

 

[O Ilusionista]

You do use flipx here

yeah, its exactly what I am pointing the error
IOW, the tool display SCALE right, but not FLIP
Got it?

 

[Piccolo]

yeah, its exactly what I am pointing the error
IOW, the tool display SCALE right, but not FLIP
Got it?

Ok anyway I'll need to know how the engine computes "flipx". In CMT I simply invert the sprite on the x axis. That's it. And that's what the manual implies should happen.

But if there is a difference between CMT and in engine, then the engine does more that flipping the image when you use flipx. Maybe it alters offset, maybe it alters entity direction, I don't know.

Maybe the engine doesn't really use a "draw method" at all but flips the entity entirely ? I don't know, but until I do I can't fix this.

 

[Die_In_Fire]

Probably this is just me trying to get into the program, but, when drawing an attackbox, it changes the cursor from the arrow to the hand, so when I try to “move the attackbox” with the mouse left button, it moves all the sprite. However I noted the right button isn’t used. It’s possible that you make the right button to allow to re-arrange the attackbox?

Maybe the option is there and I just cannot find it yet.

While visualizing, I want the animation to play only once, not to loop.

 

[Piccolo]

Piccolo updated Chronocrash Modders Tools with a new update entry:

Changelog 0.5.11

- "flipx" now not only flip sprite, but also xOffset (@O Ilusionista after doing some tests, I think that's what the engine does, not sure but you can check)

- Added an option to preview "sound" in "Anim" tab. You need to toggle it (it's next to export gif feature) @O Ilusionista

- Export gif : name of exported gif now defaults to "entityName_animationName.gif" @bWWd

Read the rest of this update entry...

 

[Piccolo]

when I try to “move the attackbox” with the mouse left button, it moves all the sprite. However I noted the right button isn’t used. It’s possible that you make the right button to allow to re-arrange the attackbox?

If you want to adjust the box either redraw it or use your mouse wheel on the values on the right. That's already two ways to adjust boxes, don't think a third is needed.

 

[O Ilusionista]

Added an option to preview "sound" in "Anim" tab. You need to toggle it (it's next to export gif feature) @O Ilusionista

I've tested it and its great! I will test the drawmethod part.

Really thanks for all your effort buddy

 

[DCurrent]

@Piccolo & @O Ilusionista

On offsets, I'll need to dive into the code to really explain properly, right now I'm on a tablet at a family gathering and can't do that. I can give you the basics though.

OpenBOR does not store the sprite as you see them. The sprite is trimmed as it loads, and that's what goes into memory. As part of this, anything reliant on sprite dimension (body box, attack box, offset, etc.) are all adjusted to match and recorded. Pretty much every value you THINK you're putting in is sanitized and reworked by the engine into something else. It's a blessing (makes it easy to use) and a curse (confusing to code around).

I don't recall exactly what those formulas are, but I'll try to get them for you after the Christmas holiday.

DC

 

[O Ilusionista]

Hey buddy.
After the release which included the "preview sounds", we get an warning when typing "sound" and only stoping popping up after you start to type the sound effect path, take a look:

Traceback (most recent call last):
File "gui\entity\__init__.py", line 575, in notifyChange
File "gui\entity\__init__.py", line 906, in processLines
File "ntpath.py", line 143, in join
File "genericpath.py", line 152, in _check_arg_types
TypeError: join() argument must be str, bytes, or os.PathLike object, not 'NoneType'

 

[ABK]

Oh wow, the bugs i fixed few days ago suddenly came back out of nowhere and i see that the text files reverted to some old ass versions from few days ago, because i remember fixing specifc lines of code which magically reappeared despite me fixing them....
If this is because of sessions code or something of that nature, i want to disable this premanently ,this is not ready to be used .
And i have no clue now how muych other stuff was brought back without my permisison, how something like this can happen?
Is it autosave code? What is it ? I dont want it to ever happen again, so id rather do my own autosave and not let the software to store entire text files and bring them back, this should not happen.
I know its vague as hell but, yeah i have no idea wha happun... and i dont want it to happen again pretty much.
Im just glad it was a visual change and this is why i noticed it and checked if it changed some scripts, but i wonder how much it changed where it wont show up visually....

 

[O Ilusionista]

If this is because of sessions code or something of that nature, i want to disable this premanently ,this is not ready to be used .

When you run the tool, you will see a checkbox at the left, asking if it should ask for a session load.
I've disabled it and never had any issue anymore.