Chronocrash Modders Tools

ChronoCrash Modders Tools 0.7.8

No permission to download
@DCurrent Also, if not explicitly disabled each collision box defined on a previous frame should be considered still active on the next frames right ?

So if I want to draw body box for frame 7, even if there is a body collision defined on this frame, I still need to check all the previous frames to check if there is some other body collision box still active ?

Yes. It's the same as a single. All collisions are active and retain properties until redefined or disabled in subsequent frames. I'm 99% sure that's true for the index as well, just don't want to tell you that and be wrong.

If it helps, under the hood, it's reading the text file line by line, and creating a temporary single linked list. There's an index variable in the reading function that is set by the collision.index command. Of course it defaults as 0. Then each node has an index member. When populating the linked list, it compares existing nodes' index members to see if they match reading function's index variable, and then creates/updates nodes accordingly.

Then there's a deep copy to a "production" single linked list on the animation (remember OpenBOR doesn't have a frame structure for optimization purposes). This copy is used in game play. So it looks like this:

animation->attack[frame] = Head Node Pointer

attack->index = {index from creator }
attack->next = {next pointer if available}

Same for body boxes.

DC
 
Yes. It's the same as a single. All collisions are active and retain properties until redefined or disabled in subsequent frames. I'm 99% sure that's true for the index as well, just don't want to tell you that and be wrong.

If it helps, under the hood, it's reading the text file line by line, and creating a temporary single linked list. There's an index variable in the reading function that is set by the collision.index command. Of course it defaults as 0. Then each node has an index member. When populating the linked list, it compares existing nodes' index members to see if they match reading function's index variable, and then creates/updates nodes accordingly.

Then there's a deep copy to a "production" single linked list on the animation (remember OpenBOR doesn't have a frame structure for optimization purposes). This copy is used in game play. So it looks like this:

animation->attack[frame] = Head Node Pointer

attack->index = {index from creator }
attack->next = {next pointer if available}

Same for body boxes.

DC

Ok so the good news is that I finished rewriting the current CMT code to support multiple collisions. Currently, everything works exactly as before for the user, it's just that under the hood all collisions are now collision "0" (of potential many) instead of the single collision.

But after doing that I'm even more confused about the collision index reset or not, because I realized collision index is shared for bbox and abox. I guess it means there is no implicit/automatic reset, only explicit/manual reset, because otherwise things would get pretty messy in some scenarios.
 
Yeah, collision index is indeed shared - sort of. As noted above, in actual gameplay, the index doesn't mean much of anything, because the structure is a linked list the engine iterates through in order of creation. It's just a way for you the creator to control how many collisions exist on a frame and which one you are affecting downstream in the text. It's not too hard to wrap around manually, but I can see why it might be difficult to deal with in an editor.

DC
 
Here's a first alpha for the new version that will support multiple collisions.

DOWNLOAD HERE

Probably a lot of issues because it didn't cook for long, but so far it seems to work surprisingly well.

I didn't upload it with the site upload system because I don't want regular users to think this is a normal release. Do not use this release on sensitive files as a lot of code was changed in animation editor to accommodate to multiple collisions. There is a high risk that it can mess with things, and that's precisely why I posted it, for others to try and test, see what might be broken now, and report to me so that I can fix it.

Other remarkable notes :

- To set "collision.index" within the GUI, you have to change the new spinbox on top of the body/attack collision properties form (right side of the UI).
- The visual property editor (drawing boxes with mouse) will match the corresponding collision index set in the GUI (see previous point)
- When the size of a collision box is empty (height = 0, width = 0), the collision description will automatically be compressed to "none" within the anim text
- I don't know the extent of the compatibility between legacy style commands and collision.index in the engine, but in CMT you probably can mix the two without issue @DCurrent

What I know is missing but not really critical :
- match specific collision in UI when clicking on a line in animation text (same as it work for frame level currently, but on the collision sublevel)
 
I don't know the extent of the compatibility between legacy style commands and collision.index in the engine, but in CMT you probably can mix the two without issue
Question: do you plan to keep support for the legacy style in CMT too?
I cannot help testing this alpha version because I don't use the new style of attack, but I hope someone will help you with tests :)
 
Question: do you plan to keep support for the legacy style in CMT too?
I cannot help testing this alpha version because I don't use the new style of attack, but I hope someone will help you with tests :)
Yes unless there is some major incompatibility between the two.

And you can still test it. Again I don't know if the engine supports legacy command mixed with the usage of collision.index, but CMT does. And my guess is that the engine does as well, because same as CMT I think the engine convert both styles of commands to the same things in the end. They are not really separated, just two ways to access/alter the same data.

Also you can still help test it even if you don't plan to use all this new stuff. Precisely because it needs to be tested that CMT can still work the same as before, even with all these new changes under the hood. If no one test it in alpha it will end up in the main trunk anyway, like the other changes before. This particular one involved a lot of changes to basic animation code all over the place, so I figured it was wiser to postpone the "normal" release a bit.
 
Last edited:
Again I don't know if the engine supports legacy command mixed with the usage of collision.index, but CMT does. And my guess is that the engine does as well, because same as CMT I think the engine convert both styles of commands to the same things in the end.

It does. There's a set of backward compatibility routines that read the old style and run appropriate new functions to set up collision. I still don't recommend the old style and won't offer any updates or fixes to it.

DC
 
Question: do you plan to keep support for the legacy style in CMT too?
I cannot help testing this alpha version because I don't use the new style of attack, but I hope someone will help you with tests :)
I don't like the new style of attack either because it's taking too much space although it's easier read and understand.
Please keep the old style or have an on/off option, thank you
 
I don't like the new style of attack either because it's taking too much space although it's easier read and understand.
Please keep the old style or have an on/off option, thank you
I will, but as I said months ago I'm also working on ways to compact the new style when not editing it, so that it is only de-compacted when you are actively editing it. Best of both worlds
 
I think we are derailing the topic and even overreacting a bit.
I just asked if the tool will still support the legacy code and that is it.

---
back to the topic,
@Piccolo it's possible to use both versions on the same computer or both will store the same configuration on the same place?
For those alpha builds, I think it would be better if the tool stores it's configuration in some other folder, so we can have both at the same time, to compare the results.
 
@Piccolo it's possible to use both versions on the same computer or both will store the same configuration on the same place?
For those alpha builds, I think it would be better if the tool stores it's configuration in some other folder, so we can have both at the same time, to compare the results.

Good idea, right now they share the same settings, it's just like a regular update, only with ground breaking changes and not posted with the others.

But in the next alpha I will upload (relatively soon as I finally figured out how to properly handle the visual collapsing in text) I'll make it use separate config files
 
NEW ALPHA BUILD (0.6.1)


What's new :
- Initial support for collapsible/expandable property group in animation text (see post above for visual preview of what it is)
- With this feature you basically have best of both world with new style of commands (you get legacy commands benefits and new style commands benefits)
- In an animation, when a property group (attack, bbox) is not focused it is collapsed as one single line (very similar to legacy command style).
- And when you focus on this collapsed line, it is expanded so you can see and edit all the properties. That way, animation texts are not taking more space with new style of commands compared to legacy style.
- The collapsed line will reflect the box current values in a way similar to legacy style, making transition to new style easier.

- Add a quick switch feature in main editor, allowing you to select one of the recently edited file. Useful if you have a lot of files opened in left panel.

- Changed some default settings (fonts, colors, and size of some elements)

- NOTE : Alpha builds of CMT now use a separate config file (but cache and sessions are still shared/available)
 
Back
Top Bottom