ChronoCrash Modders Tools 0.6.10

[O Ilusionista]

@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]

@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.

 

[Piccolo]

@O Ilusionista 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.

Download last alpha build

 

[O Ilusionista]

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

 

[Piccolo]

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.

 

[O Ilusionista]

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


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)



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)



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)


Hope that helps

 

[DCurrent]

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

 

[O Ilusionista]

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:

drawstring( 140, 50,2,"Camera X:  "+(openborvariant("xpos")% 10000)+" - Camera y:  "+(openborvariant("ypos")% 10000) );

But I tried using ceil() but it returns an error.

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:


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:


the first wait, in game:


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

 

[DCurrent]

It's not available on OpenBOR?

No, it isn't I just checked. Odd omission. I'll see about adding it. Until then, you'll have to write in the formula manually. Sorry.

DC

 

[Piccolo]

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)

 

[O Ilusionista]

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:

 

[Piccolo]

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.

 

[NED]

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.

 

[Piccolo]

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...

 

[NED]

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]

@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.





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.

 

[Piccolo]

Piccolo updated Chronocrash Modders Tools with a new update entry:

Changelog 0.6.10

Fixed a loading bug in Level Editor @O Ilusionista (the one related to xOffset)

Important note : this update is the first standard release of version 0.6.x, so it also contains all the changes from the previous alpha of 0.6 (refer to forum posts to see what they are)

Read the rest of this update entry...