Chronocrash Modders Tools

ChronoCrash Modders Tools 0.7.8

No permission to download
Overview Updates (133) Reviews (9) History Discussion
direction left and direction leftright. They're the opposites of both right and both/rightleft respectively. I use leftright too. It would be great to see it for developing progress.

Here's how direction is set from its given values.
direction {dir}

  • Determines which direction the screen scrolls in.
  • {dir} can be right, left, both/rightleft, up, down, in, out, inout, outin, or leftright. Defaults to right if not declared.
    • up and down scroll background up and down respectively and automatically. You cannot scroll left or right in these stages. You must use groups to control enemy spawning. Wait doesn't work well here so that means you have to watch the time here. Put time item or simply set time to 0. Panels, neons and screens are not scrolled.
    • left and right must be scrolled manually, like normal.
    • both or rightleft is pretty neat. It's like direction right but it allows you to freely scroll left or right. When you reach a wait, you won't be able to move back past the previous wait until all spawned enemies prior to wait are killed.
    • leftright is similar direction both but it's like direction left instead.
    • in and out is new scrolling system in which player scrolls in or out respectively. In means up in z axis while out means down. Just like left and right, it must be scrolled manually.
    • inout and outin is similar to direction both but they are like direction in and out respectively.
  • Screen, neon, water, etc don't work well in direction in, out, inout and outin.
Click to expand...
I think I did try up and down directions. They're only used for scrolling the background with its respectively given direction of level.

OK. I just tested in and out directions. It's like what the manual says. But I just discovered using in starts from the bottom of the level if the panel size is high while out starts from the top, only if a level has different zmin and zmax limit. As in z 100 1500, for instance. You can also use outin or inout like both and leftright.

Direction - in:
bor - 0081.png

Direction - out:
bor - 0080.png
 
maxman said:
It would be great to see it for developing progress.
Click to expand...
Just as I mentioned to Dante, until I add it explicitly you can easily preview these levels by just make them "left". Unless I'm mistaken "left" and "leftright" are supposed to be exactly the same in the context of CMT, they only vary when you play as a game character in the engine.
 
maxman said:
OK. I just tested in and out directions. It's like what the manual says. But I just discovered using in starts from the bottom of the level if the panel size is high while out starts from the top, only if a level has different zmin and zmax limit. As in z 100 1500, for instance. You can also use outin or inout like both and leftright.
Click to expand...
Man, I have a OUTIN stage at my MMPR game and I can clearly say that was my WORSTE experience with OpenBOR ever.
Its a effing pain in the ass to work with it.
 
@Piccolo I got a bug on the latest version: I can't see the binded entity anymore - the entity name is in red and it doesn't read all of its animation
1740852578364.png

Plus, if I try to change the palette, I get this error:

Traceback (most recent call last):
File "gui\entity\frameproperties.py", line 143, in entityPaletteChanged
File "gui\entity\frameproperties.py", line 274, in changeEntityPalette
AttributeError: 'NoneType' object has no attribute 'palettes'
 
O Ilusionista said:
@Piccolo I got a bug on the latest version: I can't see the binded entity anymore - the entity name is in red and it doesn't read all of its animation
View attachment 10227
Click to expand...
I just figured it out. Go to the left side of the file selector panel and click on the reload button above it. That will let you open the entity model for slams. Not only that, but also it will restore the dark green color there.

showent2.png

P.S.: Unless there's a bug that you can't use CMT anymore, let's wait for him to fix it.

EDIT: Just realized he already fixed it for 7.7, so it's all good.
 
Last edited:
@Piccolo Using version 0.7.7, there is a stage of mine which stopped loading. I can see it on the text editor, but once I jump to LEVEL tab, I get this error
Traceback (most recent call last):
File "gui\main\__init__.py", line 628, in <lambda>
File "gui\main\__init__.py", line 488, in setView
File "gui\level\__init__.py", line 285, in loadLines
File "gui\level\__init__.py", line 1653, in loadLines
AttributeError: 'WallControlWidget' object has no attribute 'level'
Click to expand...

Testing the same stage on 0.6.3, it loads normally
1741038248221.png

I will pm you the stage, in case you want to take a look
PS: its something with DIRECTION BOTH. Once I remove this line, the stage loads.
 
O Ilusionista said:
@Piccolo Using version 0.7.7, there is a stage of mine which stopped loading. I can see it on the text editor, but once I jump to LEVEL tab, I get this error


Testing the same stage on 0.6.3, it loads normally
View attachment 10266

I will pm you the stage, in case you want to take a look
PS: its something with DIRECTION BOTH. Once I remove this line, the stage loads.
Click to expand...
oh god yeah I just checked because it didn't make sense, and as it happens I made a huge typo in the last revision fix (the one for direciton leftright). It's an easy fix though
 
@Piccolo
Today I managed to reproduce an error in how the tool shows the inverted sprites with "drawmethod flipy" and the respective BBOX.

This is how it is shown in the tool - note that the sprite is intertwined and the bbox covers it (which is the same bbox as idle)
1748701869364.png

However, inside the engine, the bbox appears in its original place - as far as I know, drawmethod only influences how the sprites are drawn, with no effect on collision boxes
pdc - 0194.png

Do you think it would be possible to fix this?
 
O Ilusionista said:
as far as I know, drawmethod only influences how the sprites are drawn, with no effect on collision boxes
Click to expand...

That is correct. Drawmethod has no in game effect at all. It is graphical only. I am looking at (but it's just a thought) of maybe a parallel setting to scale collision boxes, but it's not a thing at the moment.

DC
 
I keep getting this error message when in cmt when going into level


Traceback (most recent call last):

File "gui\main\__init__.py", line 628, in <lambda>

File "gui\main\__init__.py", line 488, in setView

File "gui\level\__init__.py", line 285, in loadLines

File "gui\level\__init__.py", line 1751, in loadLines

KeyError: 'xMin'

Screenshot 2025-05-31 182951.png
 
blacspriation said:
I keep getting this error message when in cmt when going into level


Traceback (most recent call last):

File "gui\main\__init__.py", line 628, in <lambda>

File "gui\main\__init__.py", line 488, in setView

File "gui\level\__init__.py", line 285, in loadLines

File "gui\level\__init__.py", line 1751, in loadLines

KeyError: 'xMin'

View attachment 10784
Click to expand...

From the location it's probably related to this kind of line in levels.txt :

Code: 
z {zmin} {zmax} {BGheight}

Maybe you have an incomplete line "z" line ?
 
I pasted this into my walk animation and it wiped entire txt file, and no backup....
some error popped up in editor but after i clicked ok, it wiped everything inside txt...
This should never ever ever ever happened.

I did recover it from backups but still... its scary.
Is it → ?

@script
if(frame == 0){
int r = (abs(rand()) % 3) * 5 + 5; // 0→5, 1→10, 2→15
changeentityproperty(getlocalvar("self"), "animpos", r);
}
@end_script
 
bWWd said:
I pasted this into my walk animation and it wiped entire txt file, and no backup....
some error popped up in editor but after i clicked ok, it wiped everything inside txt...
This should never ever ever ever happened.

I did recover it from backups but still... its scary.
Is it → ?

@script
if(frame == 0){
int r = (abs(rand()) % 3) * 5 + 5; // 0→5, 1→10, 2→15
changeentityproperty(getlocalvar("self"), "animpos", r);
}
@end_script
Click to expand...
Does not trigger anything for me.

+ there is a backup system in CMT that stores every last revisions, and CMT never ever automatically save changes in a file that is open, the save has to be done by user.

So two possibilities :

- Possibility 1 (more likely) : if the error occurred when you tried to save the file (Ctrl + S, save button, ...), then yeah it might be related to the file encoding. My guess would be that the file you opened had a pre-established encoding that was not compatible with the "→" character, and thus when trying to write this character it crashed in the middle of the writing process. I would need this file to check this on my side. In the meantime I will add a gross workaround to prevent this issue from affecting the original file, but I need the specific error that is triggered to properly fix this.

- Possibility 2 (less likely) : if you didn't try to save your file after the error, and if your file was still wiped on your disk, then it might as well be an issue on your OS / disk / filesystem. Would explain why you got an error in the first place : CMT probably couldn't read/write the opened file anymore.
 
Piccolo updated Chronocrash Modders Tools with a new update entry:

Changelog 0.7.8

Previous versions of CMT tried to preserve files character encoding for files that were created outside of CMT. This could cause save/overwriting issue when trying to save characters that were not supported by the file original encoding scheme. Because this error occurred during the writing process, in the worst case it could cause the content of the file to be wiped (but if you didn't disabled CMT backup systems then there would still be two backups made before trying to actually overwrite...
Click to expand...

Read the rest of this update entry...
 
  • Like
Reactions: NED
You must log in or register to reply here.
Back
Top Bottom