ChronoCrash Modders Tools 0.7.8

[O Ilusionista]

@Piccolo I gave the alpha a try and there is something weird about the selection, as you can see in the video.
Before testing the alpha version, I took a screen shot of the previous version options that I use, so I could configure the alpha in the same way to compare:



In the first part of the video, I am using the previous version (using the Vim theme to be easier to spot the versions) and you can see that I can just click on the line I wanted and press tab to fix the indent.

But in the alpha version (using the Solarized theme) the selection never works - it auto selects the first line or the entire block.

From what I see, now I need to double click on a line to select it - and it doesn't even select the line, but the word I clicked on;

 

[Piccolo]

...

Hum you're right, I have this too but it wasn't there during most of my testing so probably due one very recent change, I'll check

 

[Piccolo]

@O Ilusionista I updated the alpha build, thanks for the report. You can use the same previous link to download the updated build.

 

[O Ilusionista]

hum, I've found two things:

1 - the settings are totally separated from both versions. I've changed the highlighted line color on alpha and, when I've opened the current build, the same color were applied. So maybe there could some conflicts between the versions. Also, when I changed SOLARIZED to VIM in Alpha, even after I restart the tool, the select line color is still the same

2 - When selecting a line and hitting TAB, instead of indenting that line, the tool... duplicates the line?

 

[Piccolo]

2 - When selecting a line and hitting TAB, instead of indenting that line, the tool... duplicates the line?

I can't reproduce this one, can you send me the animation text where it does that


As for the settings that's weird, they are in two distinct files so there shouldn't be conflict. Maybe there is some issue with windows version, I'll check, I only did testing on Linux

 

[O Ilusionista]

I can't reproduce this one, can you send me the animation text where it does that

Problably, its related to a behaviour that happens in the previous version too: some issue with platform.
Whenever you have platform on an animation, you can drag and move it. But the values on the text never get updated:

The values will only get updated if you use SET PLATFORM and them drag it and move around.
But it doesn't makes much sense, since I was already able to drag and move it before using SET PLATFORM.

I remember I get some issues with this too, related to other things like bbox - I will try to reproduce, but if you try to draw a bbox on a frame that has platform, the platform graphic moves with it too.

 

[Piccolo]

...

Yeah I just did some test before (when I saw you had set a platform in this anim) and it made me realize this feature is clearly half-baked lol

 

[Piccolo]

I remember I get some issues with this too, related to other things like bbox - I will try to reproduce, but if you try to draw a bbox on a frame that has platform, the platform graphic moves with it too.

I just fixed this in latest update (same link). The platform will still seemingly move as you draw, but it will reset when you release move cursor. It's easier that way instead of having to disable/enable platform drag conditionally. This issue only happened when the start of the box you draw coincided with the platform

I also fixed the issue where coords of platform didn't get updated when not in "set platform" mode, even though you could move it around.

I couldn't reproduce the tab bug (when it duplicates a line). If it was related hopefully it will be fixed

 

[O Ilusionista]

i've been using the alpha build since yesterday and, so far, so good

 

[Piccolo]

i've been using the alpha build since yesterday and, so far, so good

Excellent, thanks for the report !

I made some adjustments to the alpha build today, but they only apply to new features (multiple collision and collapse/expand for new style of commands), so it shouldn't change anything for you if you don't use these.

But it's good that so far all previous stuff work as before for you, as I really don't want to maintain two separate branches of CMT at the same time. So if there is nothing worrying in a week or two, I'll move out this build from alpha to classic release.

Here is the alpha link again for those that want to test

 

[O Ilusionista]

@Piccolo I've found two things (and both happens in both versions, stable and alpha)

1 - When selecting a wall, if you change the value in the xoffset and hit update, nothing happens (In fact, just by dragging the wall around doesn't update the values in the edior, I need to jump into the text mode and then return to the editor to see the values)

2 - Have you tried to load a "direction left" stage? When displaying a stage with direction left, the waits/groups are all wrong, because they are counted from the left side, as on a normal stage. But for "direction left" this should be flipped: the wait/group should be counted from right, as this is how the engine works.

This is how the stage is displayed:


And this is how it should be (pay attention to the blue lines, they are where my waits are placed)


You can easily see the first wait, which should happens 240px FROM RIGHT (near the entrance door at right) as you can see in the second image.
Now pay attention to the first image...and you will see the first wait being placed over the background monitor.

This happens because its flipped: if I invert the image on photoshop, you can see the waits flipped:




ps: something like that happens on more uncommon directions, like outin, but they are so uncommon that I don't know if you should waste time on it now.

 

[Piccolo]

...

@O Ilusionista I fixed the wall x/z issue not updating. Also fixed the issue where values weren't updated when releasing dragged wall.

For the "left" direction levels, there was no support before. I added the first step in this update. But I won't continue until I'm sure I'm on the right way, because honestly I have no idea how those levels works in the engine and I don't want to mess the code needlessly. So to be clear it's not supposed to work right now. Right now what I did was just using "full width" of level to readjust at for entities, waits and groups. And basically I just want to know if it seems right or not.

Link is same as before

 

[O Ilusionista]

because honestly I have no idea how those levels works in the engine and I don't want to mess the code needlessly.

Sure thing. Maybe @DCurrent could share some info about I said here - I remember there was a post about it somewhere, but I could not find it.
But unless I am mistaken, what I said was right: in "DIRECTION LEF" stages, the positions starts to count from right to left (iow, flipped if you compare with a regular level).

I need to check, but I think even the facing is flipped too (in DIRECTION RIGHT stages, the entities are spawned facing left).

 

[Piccolo]

But unless I am mistaken, what I said was right: in "DIRECTION LEF" stages, the positions starts to count from right to left (iow, flipped if you compare with a regular level).

Yes but does this apply to "coords" too or only "at" ? Right now you can check in last update what loading such a level looks like, it only adjusts "at". Maybe it's enough for positional stuff, I don't know, I would need a test example.

Default direction switch will be easy to implement after that.

 

[hbdhl]

You can change the editor font in settings -> editor. The font of the GUI is not editable yet I think, but I can add a setting if you want in next update.

Thank you!

 

[O Ilusionista]

Yes but does this apply to "coords" too or only "at" ? Right now you can check in last update what loading such a level looks like, it only adjusts "at". Maybe it's enough for positional stuff, I don't know, I would need a test example.

I was testing the last demo and there is something weird now. Like it totally broken the spawn and position system.
Let me explain...

I had this BOX placed on the stage:

spawn box
coords 340 180
at 240

Which the tool displays on the wrong position (inside the wall), when I was using the previous Alpha:

(pay attention to the positions at bottom left, as I had my mouse exaclty over the box axis - they doesn't match anything)

But this is how the engine displays it

In otther words, the engine displays it where it should be: 340px from the left side.
No matter the direction (left or right), the coords counts from left AFAIK.

But using this new alpha, once I jump to Level Editor, I can see the box on the wrong position as in the first image, but as soon as I jump back to the text tab, you will notice that the "at" for EVERY spawn is now changed - you can even see that the WAIT and GROUP were placed in 240, but the Box is now spawned at 1200?



So I jumped back to the level editor and....

The box is now placed on a totally different position.

We are having the same issue we had with TYPE NONE before:
- jump to text editor, and it says 1200.
- jump to level editor, and it says 240
and so on.

Take a look at the video and you will see:
- The first version which appears in the video is the latest Alpha. See as I move switch back and forth from text to level the numbers keep changing.
- then I changed to the last stable version and even it displaying the obstacle in the wrong position, at least it doesn't changes anything.

I will pack you a copy so you can check.

 

[Piccolo]

But using this new alpha, once I jump to Level Editor, I can see the box on the wrong position as in the first image, but as soon as I jump back to the text tab, you will notice that the "at" for EVERY spawn is now changed - you can even see that the WAIT and GROUP were placed in 240, but the Box is now spawned at 1200?

Yes this is normal. Maybe I wasn't explicit enough in my previous posts but the support I added for direction "left" levels is not finished at all. The only thing it does right now is translate the "at" when reading the level (or in other words when going from "Text" to "Level"). But it doesn't translate them back (when going from "Level" to "Text") because for that I need to be sure that the initial translation is correct. Otherwise I will just write bad code for nothing. That's why the values are wrong when you go back to "Text" view.

In otther words, the engine displays it where it should be: 340px from the left side.
No matter the direction (left or right), the coords counts from left AFAIK.

I think it is the other way around then. As I said right now only "at" are converted, not coords. So it seems that in "left" direction levels, coords are counted from right corner in engine.

EDIT : Hum I think it's counted from left, but subtracting screen width. The bold part is what is missing

 

[O Ilusionista]

EDIT : Hum I think it's counted from left, but subtracting screen width. The bold part is what is missing

@DCurrent @Kratus could you guys give us some more info about how the Direction Left works, please?

 

[Piccolo]

@DCurrent @Kratus could you guys give us some more info about how the Direction Left works, please?

I just tested the bold part (subtracting screen width to the value), and it works great for entities (I checked in the engine).

The only question now is does this apply to wait and groups as well ? I would say no but I'm unsure.

 

[DCurrent]

@DCurrent @Kratus could you guys give us some more info about how the Direction Left works, please?

Away from my desk, but IIRC, left levels count all object placements, layers, panels, and positions from right > left.

Absolute positions (screen coords, sprite offsets within an object, etc.) don't change.

The simplest way to test is start a left direction level and turn on basic properties debug option.

DC