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 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.
Once I load the stage and jump to Level Editor, I receive this error: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.
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'
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.Once I load the stage and jump to Level Editor, I receive this error:
I will pack the game for you
1st line - playerproperty X and playerproperty Z
2nd line - camerazoffset and cameraxoffset
3rd line - openborvariant xpos and ypos
4th line - openborvariant levelwidth and levelheigh
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
Yeah, makes sense.I'm glad to know I was wrong, because logically, NOT flipping the positioning placements actually makes a lot more sense.
drawstring( 140, 50,2,"Camera X: "+(openborvariant("xpos")% 10000)+" - Camera y: "+(openborvariant("ypos")% 10000) );
drawstring( 140, 50,2,"Camera X: "+(ceil(openborvariant("xpos")% 10000))+" - Camera y: "+(openborvariant("ypos")% 10000) );
It's not available on OpenBOR?
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)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![]()
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:Now just have to adjust minor things like player spawn points (I guess those are relative to starting side)
spawn4 160 10 0
spawn3 150 20 0
spawn2 140 30 0
spawn1 130 40 0
It always does that for every level when you load them from "opened files". Should read well when opened from library.And looks like the player spawn preview isn't getting the minz as referecence, take a look:
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...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.
No problem.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...
@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.@Kratus could you guys give us some more info about how the Direction Left works, please?
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)
That is weird. I have cases where I need to use inline script like you mentioned but I never had any issue with it.I have some scripts that keeps getting broken and changed by this program, and i keep re-adding missing bits...
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 investigateIs 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.