• All, I am currently in the process of migrating domain registrations. During this time there may be some intermittent outages or slowdowns. Please contact staff if you have any questions.
Chronocrash Modders Tools

ChronoCrash Modders Tools 0.6.17

No permission to download
@Piccolo something that happens sometimes - both in alpha and in stable:
If you change a file externally and jump back to CMT, none of the options on the pompt works:

Neither hitting ALT+F4 - I have to go to Task Manager and kill the process.
 
@Piccolo something that happens sometimes - both in alpha and in stable:
If you change a file externally and jump back to CMT, none of the options on the pompt works:

Neither hitting ALT+F4 - I have to go to Task Manager and kill the process.
You can disable this feature with option "Check external file updates". The core of this issue is on the OS side, which return a wrong "mtime", so not so much I can do. I can add a trick to prevent it from looping but I can't really fix the underlying issue.
 
Here you go, from my personal testings levels "left" are loading a lot better now, and the conversion back and forth (level to text) seems to be working good as well.
Once I load the stage and jump to Level Editor, I receive this error:

Traceback (most recent call last):
File "gui\main\__init__.py", line 491, in <lambda>
File "gui\main\__init__.py", line 353, in setView
File "gui\level\__init__.py", line 285, in loadLines
File "gui\level\__init__.py", line 1704, in loadLines
File "gui\level\__init__.py", line 1248, in loadFrontPanel
AttributeError: 'WallControlWidget' object has no attribute 'fullWidth'

I will pack the game for you
 
Once I load the stage and jump to Level Editor, I receive this error:



I will pack the game for you
You can disable (comment) xrepeat stuff to check. Or wait for the new fix. But it's basically unrelated to the work made on direction, it's xrepeat related.
 
I've sent you a debug version for testing.
But using the debug, I can see some useful info:

1st line - playerproperty X and playerproperty Z
2nd line - camerazoffset and cameraxoffset
3rd line - openborvariant xpos and ypos
4th line - openborvariant levelwidth and levelheigh

Case 1: AT 0
1- Player pos X is 1310, so its still counting from the left side, not from right (as the whole stage is 1440px wide)
2 - zoffset and xoffset are 0
3 - Xpos is 960, which happens to be levelwitdh-hResolution (IOW, 1440 - 480 = 960). So, again, it counts from left, no matter the direction
pdc - 0049.png

Case 2: WAIT AT 240
1 - player pos X is decreasing (886) as it moves left
2 - same
3 - Xpos is 719, which is strage - it should be 720 (960-240). Maybe its a rounding error from (openborvariant("xpos")% 10000)

pdc - 0050.png

CASE 3: WAIT AT 540

1 - player pos X is decreasing (457) as it moves left
2 - same
3 - Xpos is 419 (again, it should be 420), which is levelwidth-hresolution-at (1440-480-540= 420)

pdc - 0051.png

And, finally, CASE 4: WAIT AT 960

1 - player pos X is decreasing (61) as it moves left
2 - same
3 - Xpos is 0, as we reached the final position hresolution+at (480+960= 1440)
pdc - 0052.png

Hope that helps
 
I've sent you a debug version for testing.
But using the debug, I can see some useful info:



Case 1: AT 0
1- Player pos X is 1310, so its still counting from the left side, not from right (as the whole stage is 1440px wide)
2 - zoffset and xoffset are 0
3 - Xpos is 960, which happens to be levelwitdh-hResolution (IOW, 1440 - 480 = 960). So, again, it counts from left, no matter the direction
View attachment 7877

Case 2: WAIT AT 240
1 - player pos X is decreasing (886) as it moves left
2 - same
3 - Xpos is 719, which is strage - it should be 720 (960-240). Maybe its a rounding error from (openborvariant("xpos")% 10000)

View attachment 7878

CASE 3: WAIT AT 540

1 - player pos X is decreasing (457) as it moves left
2 - same
3 - Xpos is 419 (again, it should be 420), which is levelwidth-hresolution-at (1440-480-540= 420)

View attachment 7879

And, finally, CASE 4: WAIT AT 960

1 - player pos X is decreasing (61) as it moves left
2 - same
3 - Xpos is 0, as we reached the final position hresolution+at (480+960= 1440)
View attachment 7880

Hope that helps

I'm glad to know I was wrong, because logically, NOT flipping the positioning placements actually makes a lot more sense.

DC
 
I'm glad to know I was wrong, because logically, NOT flipping the positioning placements actually makes a lot more sense.
Yeah, makes sense.
I found it strange that the result of levelwidth-hresolution-at was 419 and not 420 (1440-480-540= 420)
Maybe it's a rounding problem here:
Code:
drawstring( 140, 50,2,"Camera X:  "+(openborvariant("xpos")% 10000)+" - Camera y:  "+(openborvariant("ypos")% 10000) );

But I tried using ceil() but it returns an error.
Code:
drawstring( 140, 50,2,"Camera X:  "+(ceil(openborvariant("xpos")% 10000))+" - Camera y:  "+(openborvariant("ypos")% 10000) );

It's not available on OpenBOR?

----

@Piccolo I am making some tests with the latest alpha you sent me:
The obstacles are displayed on the right position:
1715177161878.pngpdc - 0058.png

I am using that red box (which simulates the camera position) to check the waits.

The waits are positioned as this:
- 240
- 540
- 960

The WAITS could be a bit tricky to understand (because we are used to work on DIRECTION RIGHT, so the red box was always placed at left)
but, for DIRECTION RIGHT, the red box should be placed at right - so the tool is displaying it right:
1715178318609.png

the first wait, in game:
pdc - 0060.png

Then, so far, everything looks right - we just need to get used to look at it :)

I will be doing more tests and report.
Thanks for your hard work :)
 

Attachments

  • 1715177857571.png
    1715177857571.png
    43.5 KB · Views: 0
  • 1715177333665.png
    1715177333665.png
    78 KB · Views: 0
Then, so far, everything looks right - we just need to get used to look at it :)

I will be doing more tests and report.
Thanks for your hard work :)
Great, it was not so complicated after all, most things stay the same. Now just have to adjust minor things like player spawn points (I guess those are relative to starting side)
 
Now just have to adjust minor things like player spawn points (I guess those are relative to starting side)
Yes, they count from the right side in DIRECTION RIGHT - try the game I've sent you and you will see they spawning on the right place:
spawn4 160 10 0
spawn3 150 20 0
spawn2 140 30 0
spawn1 130 40 0

So P1 spawns 130px from the right side, not left.
And looks like the player spawn preview isn't getting the minz as referecence, take a look:
1715189860639.png
 
And looks like the player spawn preview isn't getting the minz as referecence, take a look:
It always does that for every level when you load them from "opened files". Should read well when opened from library.

The reason is minz and maxz are located outside the actual level, in levels.txt.

So when you open a file from "opened files" it doesn't have access to this information. I might add a feature to look back in nearest levels.txt file but for now it doesn't as it's a pretty minor issue.
 
Thanks for keeping this ambitious project updated and polished.
I always keep an eye on updates and what you guys manage to fix on it.

@DCurrent
BTW the last DL I tried for it was interrupted by my antivirus.
I think it's a false positive, but I wonder if there is a precise reason.
 
BTW the last DL I tried for it was interrupted by my antivirus.
I think it's a false positive, but I wonder if there is a precise reason.
Yeah it's a false positive. A lot of modern antivirus are way too sensitive in regard to apps that are not packed for stores basically (with signature and all). It's also because they are too reliant on machine learning, so for example if a popular virus is made using some "normal" libs/packaging tools, then the machine learning may associate the code of the libs/tools with viruses, and so when not sure, will flag programs that also use those as viruses. And then it gets worse because the positive alerts on one installation are usually fed back to the database so that it will affect other users too...

I can do something about in the sense that I can submit the program to be whitelisted, but the issue is I would probably have to do that for every update...
 
Last edited:
Yeah it's a false positive. A lot of modern antivirus are way too sensitive in regard to apps that are not packed for stores basically (with signature and all). It's also because they are too reliant on machine learning, so for example if a popular virus is made using some "normal" libs/packaging tools, then the machine learning may associate the code of the libs/tools with viruses, and so when not sure, will flag programs that also use those as viruses. And then it gets worse because the positive alerts on one installation are usually fed back to the database so that it will affect other users too...

I can do something about in the sense that I can submit the program to be whitelisted, but the issue is I would probably have to do that for every update...
No problem.
So it's confirmed for me that it's safe just like your previous builds. ^^
Thanks
 
@Kratus could you guys give us some more info about how the Direction Left works, please?
@O Ilusionista According to my tests it works starting from the right border of the panel image but at the left side of the screen. We can use the SOR1 stage 8 as a reference.

1715383906248.png
1715383955895.png
1715384057060.png

Then the "xpos" value will decrease until it reaches the left side of the panel image. However, in the level file the "AT" must be configured using progressive numbers instead of regressive, and this can cause some confusion during the level building.

It seems that the original author of the code added an automatic conversion to avoid calculating "AT" for "direction left" levels, but in case you have scripts based on the "xpos" variant you will need to check the real value.


1715384270885.png

1715384494743.png
 
Is it possible to add a mode where the program totally ignores scripts ? So it does not touch the scripting code at all ? I have some scripts that keeps getting broken and changed by this program, and i keep re-adding missing bits... i think id just prefere if the program did not try to "help" me with the code at all... So when it sees @ tags then it just not does anything at all until it sees another @ that closes scripts, i talk animationscripts inside animations.
Orphans finder gives me this aa.png
 
Last edited:
Is it possible to add a mode where the program totally ignores scripts ? So it does not touch the scripting code at all ? I have some scripts that keeps getting broken and changed by this program, and i keep re-adding missing bits... i think id just prefere if the program did not try to "help" me with the code at all... So when it sees @ tags then it just not does anything at all until it sees another @ that closes scripts, i talk animationscripts inside animations.
As far as I remember that's already the case, scripts are totally ignored. I'll have to check to make sure, but in the meantime if you can reproduce the issue make a report here so I can investigate ;)
 
Back
Top Bottom