Chronocrash Modders Tools

ChronoCrash Modders Tools 0.7.8

No permission to download
I'm uploading a fix, but just realized isn't there the reverse issue with attack box in CMT legacy mode ?

I mean when you draw an attackbox in CMT legacy mode, it will write a "0" value in z (depth) param of attack line. Doesn't that mean the depth is set to 0 ? Or does the engine doesn't allow 0 and automatically convert it to the default depth for the entity ?

I would find it strange considering there is also the optional second z parameter, in which case having 0 in one of the z field can make sense.
 
I'm uploading a fix, but just realized isn't there the reverse issue with attack box in CMT legacy mode ?

I mean when you draw an attackbox in CMT legacy mode, it will write a "0" value in z (depth) param of attack line. Doesn't that mean the depth is set to 0 ? Or does the engine doesn't allow 0 and automatically convert it to the default depth for the entity ?

I would find it strange considering there is also the optional second z parameter, in which case having 0 in one of the z field can make sense.

Attack boxes use grabdistance, and it's a weird calculation, but IIRC when everything is all default you get 15 in each direction. Body boxes IIRC just use 0.
 
mean when you draw an attackbox in CMT legacy mode, it will write a "0" value in z (depth) param of attack line
I agree with DC in this case, zero is the best option. IMO considering that the collisions are most times managed using Z depth in attack boxes, I think we could use zero as default for the two parameters of bbox Z depth.
Usually we only change it in exceptions like when the enemy/obstacle bbox must be larger than the player's attack boxes, in case of big bosses or large obstacles.
 
I agree with DC in this case, zero is the best option. IMO considering that the collisions are most times managed using Z depth in attack boxes, I think we could use zero as default for the two parameters of bbox Z depth.
Usually we only change it in exceptions like when the enemy/obstacle bbox must be larger than the player's attack boxes, in case of big bosses or large obstacles.

There is one minor issue with 0, and potentially one major issue too.

Minor issue : most of the times bbox depth is implicit (not written), so there should be a way to differentiate explicit 0 and implicit 0 (so that we support both)

Potential major issue : it needs to be confirmed that having a "0" value doesn't actually set it to 0 in the engine. In the two cases or one case (single z1, and z1 & z2).
 
Minor issue : most of the times bbox depth is implicit (not written), so there should be a way to differentiate explicit 0 and implicit 0 (so that we support both)

Potential major issue : it needs to be confirmed that having a "0" value doesn't actually set it to 0 in the engine. In the two cases or one case (single z1, and z1 & z2).
Good points, I will take a look in the source to understand better. So far the -100000 is working fine in the last update.
 
There is one minor issue with 0, and potentially one major issue too.

Minor issue : most of the times bbox depth is implicit (not written), so there should be a way to differentiate explicit 0 and implicit 0 (so that we support both)

Potential major issue : it needs to be confirmed that having a "0" value doesn't actually set it to 0 in the engine. In the two cases or one case (single z1, and z1 & z2).
I'll check to make certain, but I'm 99.99% sure that bbox default is 0, and by extension allows 0.

It is only attack that has a default setup and overrides having all 0 z values.

If everything related to depth (grabdistance, z parameters, etc.) is left to default you get attack depth of 15 in both directions and body depth 0. So, attacks end up having an effective reach of 15 up and 15 down.

There’s usually no need to change bbox depth, but edge cases always exist, so it's there as an option.

DC
 
I tried adding platform and moving it to the character for the first time.

Code:
Traceback (most recent call last):
  File "gui\entity\__init__.py", line 2759, in mouseReleaseEvent
  File "gui\entity\__init__.py", line 208, in getPlatform
AttributeError: 'Anim' object has no attribute 'currentFrame'
 
I tried adding platform and moving it to the character for the first time.

Code:
Traceback (most recent call last):
  File "gui\entity\__init__.py", line 2759, in mouseReleaseEvent
  File "gui\entity\__init__.py", line 208, in getPlatform
AttributeError: 'Anim' object has no attribute 'currentFrame'
Your CMT version seems to be out of date, is it ?
 
Piccolo, You thought about writing auto bbox function? So it would check for first non transparency pixels on the current image and will create upper left and bottom right corners for bbox coords ?
Usually bottom right last pixel represents transparency color, so after acquiring this it could look for pixels from upper left corner and bottom right corner that are not transparency to create bbox automatically.
I think having this as a button would be really really nice.

-----------

Ok i created it , please do borrow the code so it works in chronotools
You can test it out by saving this into bat file.

Code:
0<0# : ^
'''
@echo off
set script=%~f0
python -x "%script%" %*
exit /b 0
'''
import tkinter as tk
from tkinter import filedialog
from PIL import Image, ImageTk, ImageDraw
def get_transparency_color(image_path):
    image = Image.open(image_path)
    transparency_color = image.getpixel((image.width - 1, image.height - 1))
    return transparency_color
def find_non_transparent_bbox(image_path, transparency_color):
    image = Image.open(image_path)
    image_data = image.load()
    width, height = image.size
    left, top, right, bottom = width, height, 0, 0
    for y in range(height):
        for x in range(width):
            if image_data[x, y] != transparency_color:
                left = min(left, x)
                top = min(top, y)
                right = max(right, x)
                bottom = max(bottom, y)
    if left == width and top == height and right == 0 and bottom == 0:
        return None
    return left, top, right, bottom
def convert_bbox_to_bbox_format(bbox):
    left, top, right, bottom = bbox
    width = right - left + 1
    height = bottom - top + 1
    return left, top, width, height
def draw_bbox(image, bbox):
    image_draw = ImageDraw.Draw(image)
    left, top, right, bottom = bbox
    image_draw.rectangle([left, top, right, bottom], outline=(0, 0, 255), width=2, fill=None)
    return image
def upload_image():
    file_path = filedialog.askopenfilename()
    if file_path:
        transparency_color = get_transparency_color(file_path)
        image = Image.open(file_path)
        if image.mode != "RGBA":
            image = image.convert("RGBA")
        bbox = find_non_transparent_bbox(file_path, transparency_color)
        if bbox:
            bbox_format = convert_bbox_to_bbox_format(bbox)
            bbox_command = f"bbox {bbox_format[0]} {bbox_format[1]} {bbox_format[2]} {bbox_format[3]}"
            bbox_entry.delete(0, tk.END)
            bbox_entry.insert(0, bbox_command)
            max_size = (400, 400)
            image.thumbnail(max_size, Image.NEAREST)
            image_with_bbox = draw_bbox(image.copy(), bbox)
            photo = ImageTk.PhotoImage(image_with_bbox)
            canvas.image = photo
            canvas.create_image(0, 0, anchor=tk.NW, image=photo)
        else:
            bbox_entry.delete(0, tk.END)  
            bbox_entry.insert(0, "No non-transparent pixels found.")
root = tk.Tk()
root.title("BBOX Creator")
upload_button = tk.Button(root, text="Upload Image", command=upload_image)
upload_button.pack()
bbox_entry = tk.Entry(root, width=50)
bbox_entry.pack()
canvas = tk.Canvas(root, width=400, height=400)
canvas.pack()
root.mainloop()
 

Attachments

  • bbox.png
    bbox.png
    13.9 KB · Views: 3
Last edited:
Usually bottom right last pixel represents transparency color, so after acquiring this it could look for pixels from upper left corner and bottom right corner that are not transparency to create bbox automatically.
To be honest with you, I don't think its a good idea.
First, it would cover unnecessary areas (pretty much how it was done on your attachment - see the empty area above the bird head).
Second, this COULD be more useful in cases where you need more than one box or when the boxes are not persistent (like in mugen). For OpenBOR, I don't see much use.

And to be even more honest, I hope this never gets added. We had this in Fighter Factory, as a tool to create boxes more quickly for simple things, like projectiles... and people started using it here for EVERYTHING.

If this tool were added, it would encourage people to be lazy and flood OpenBOR games with terrible collision boxes - just like what happened in Mugen.

It's just a square. A person can't be that lazy.

I remember cases where people covered ALL THE PIXELS of a character's image with a clsn box, which is one of the stupidest things anyone can do.
 
Its a starting point, theres no way id use it to auto create bboxes like this for whole char.
Also if people lack skills you cant blame the tool. This is kinda like lets block inputting 0 cause some rookie set bbox 0 0 0 0 and it caused a problem... cmon, you cant think like this.
The bird example is unusual , if id do it by hand i would just cover his body without wings at all but for some stuff that is squarish, this can work ok to start from.
In the end i do think that it would be rare where the result would be left as is from the code i pasted, so for me its just alternative way to obtain starting point.
So yeah, it could be a bloat. Im keeping it tho.

Yeah writing this for mugen and multiple bboxes should be doable but i dont mugen since a long time.
 
Last edited:
Also if people lack skills you cant blame the tool.
Can we have a talk? ;)

I've seen this happen dozens of times, whether in Mugen or OpenBOR. We've had users here who did this all the time, even after we explained several times how it worked, giving examples... in the end, the person left behind criticizing (and still does this to this day) both the engine, moderation and administration.

It's basically a law of nature.
 
I get your point about it.Lazy makers overusing it.
OK so.. hjow about using this to create platform command ? That should work for it .
 
I haven't read all the back and forth in detail (on the road), but I actually like @bWWd's idea.

No, I wouldn’t use it for most things, but it would save a lot of time on lots of ancillary stuff. That bird for instance. It's probably just some some flying enemy that works perfectly well with a body box over its whole wing area.

It would be great for projectiles, platforms, boxes, really anything that you don't have to be super precise and has a uniform shape.

DC
 
I suppose you can even display a warning if the object contained in bbox has large empty area from one of the sides.
Yeah i tested on barrels and its ok, ideally id add optionable downsize percentage x and y, so it would shrink the bbox by the % values when it creates it
 
Every time I change the value -100000 to 0 from either Z FG or Z BG, I get this.

Code:
Traceback (most recent call last):
  File "gui\entity\frameproperties.py", line 1028, in valueChanged
  File "gui\entity\frameproperties.py", line 933, in updateData
IndexError: list index out of range

I'm using the current version which is 0.6.21.
 
Every time I change the value -100000 to 0 from either Z FG or Z BG, I get this.

Code:
Traceback (most recent call last):
  File "gui\entity\frameproperties.py", line 1028, in valueChanged
  File "gui\entity\frameproperties.py", line 933, in updateData
IndexError: list index out of range

I'm using the current version which is 0.6.21.
There's probably something else that triggers this, I can't reproduce this. And from the previous reports, others didn't have this issue either. So it must happens in more specific situations than just setting z values to 0.

The error location suggests that it's an issue with loading the whole frame, which is strange :unsure:
 
Back
Top Bottom