Hi.
There is a new version 1.8.1
Replays from version 1.8.1 work very well.
Moreover, replays made with version 1.8.1 work on all Gdash backwards, even the 2010 version.
Regards
GDash new port
Moderator: Admin
Re: GDash new port
Hello, LogicDeLuxe.
I am very glad to read you here on the forum.
You are a very smart person, you know more about Boulderdash than many people here on the forums.
I have a personal question for you, please answer it.
Are you still working on the xdc engine?
Write something more at what stage of work you are at.
Even if you abandoned this project, say so too.
Please.
I am very glad to read you here on the forum.
You are a very smart person, you know more about Boulderdash than many people here on the forums.
I have a personal question for you, please answer it.
Are you still working on the xdc engine?
Write something more at what stage of work you are at.
Even if you abandoned this project, say so too.
Please.
Re: GDash new port
Thank you Logic for the info, this was very helpful! 
So, to sum it up:
1. The perfect way to deal with the MW (and Amoeba) timings would be:
- if "scheduling type" is BD1, BD2 or PLCK, then milling time 0 should always be interpreted as 256.
- If scheduling type is "1stB" (still to add) or "CrDr7", then the milling timer does not start immediately when a magic wall is activated, but it still waits for the cave timer to switch to the next second. (This also implies that the timer always waits for hatching if the magic wall is activated before.) Milling time 0 is really interpreted as 0 now.
- If schedulig type is "milliseconds", there're no specific rules. The timer starts immediately when a magic wall is activated, and 0 means 0 (1 frame).
Come to think of it, even this perfect solution has a potential flaw because there might be GDash original games where scheduling type was set to BD1 and milling timer was 0. If such a cave was made with an earlier GDash version, then 0 should be 0, but the "perfect" GDash version would re-interprete the timer as 256, so the cave would no longer work as intended.
Another problem: it might be too hard to program this.
2. Less perfect, but more practical solution:
- Add the "milling time 0 is infinity" option to the magic wall (already implemented) and fix the GDash originals with timer 0 by hand (that's my job for the near future, work in progress). I'm also checking the 1stB/CLCK originals and if there're any milling time 0 settings, I'll change it to 1
I think I should write down which caves I changed this way, because if in the future a better magic wall timing will be programmed, then these caves should be changed back
BTW, I also thought about the amoeba timer already, but that's not such a big deal in practice because hardly any early fangame maker who used BD1/BD2/PLCK forgot to set the amoeba timer. Everyone wants the amoeba to run faster from a certain time on so it suffocates more quickly.
SUMMARY on how the magic wall works in the new GDash port.
- The new option "Milling time 0 is infinity" means that all fangames where the magic wall used to work too shortly (only 1 frame) are now automatically fixed!
(Perhaps this info should be added on GitHub because it's not so obvious to everyone what positive effects the new feature "milling time 0 is infinite" has!)
- On the other hand, a few caves now have the magic wall working too long. This is less severe because it shouldn't make any caves unsolvable, but of course this will be fixed by me manually.
So, to sum it up:
1. The perfect way to deal with the MW (and Amoeba) timings would be:
- if "scheduling type" is BD1, BD2 or PLCK, then milling time 0 should always be interpreted as 256.
- If scheduling type is "1stB" (still to add) or "CrDr7", then the milling timer does not start immediately when a magic wall is activated, but it still waits for the cave timer to switch to the next second. (This also implies that the timer always waits for hatching if the magic wall is activated before.) Milling time 0 is really interpreted as 0 now.
- If schedulig type is "milliseconds", there're no specific rules. The timer starts immediately when a magic wall is activated, and 0 means 0 (1 frame).
Come to think of it, even this perfect solution has a potential flaw because there might be GDash original games where scheduling type was set to BD1 and milling timer was 0. If such a cave was made with an earlier GDash version, then 0 should be 0, but the "perfect" GDash version would re-interprete the timer as 256, so the cave would no longer work as intended.
Another problem: it might be too hard to program this.
2. Less perfect, but more practical solution:
- Add the "milling time 0 is infinity" option to the magic wall (already implemented) and fix the GDash originals with timer 0 by hand (that's my job for the near future, work in progress). I'm also checking the 1stB/CLCK originals and if there're any milling time 0 settings, I'll change it to 1
I think I should write down which caves I changed this way, because if in the future a better magic wall timing will be programmed, then these caves should be changed back
BTW, I also thought about the amoeba timer already, but that's not such a big deal in practice because hardly any early fangame maker who used BD1/BD2/PLCK forgot to set the amoeba timer. Everyone wants the amoeba to run faster from a certain time on so it suffocates more quickly.
SUMMARY on how the magic wall works in the new GDash port.
- The new option "Milling time 0 is infinity" means that all fangames where the magic wall used to work too shortly (only 1 frame) are now automatically fixed!
(Perhaps this info should be added on GitHub because it's not so obvious to everyone what positive effects the new feature "milling time 0 is infinite" has!)
- On the other hand, a few caves now have the magic wall working too long. This is less severe because it shouldn't make any caves unsolvable, but of course this will be fixed by me manually.
Boulder Dash X Rock, Paper, Scissors:
ROCKFORD collects DIAMOND, digs DIRT
DIAMOND outvalues DIRT & BOULDER
DIRT carries BOULDER, blocks FIREFLY
BOULDER kills FIREFLY & ROCKFORD
FIREFLY kills ROCKFORD, guards DIAMOND
ROCKFORD collects DIAMOND, digs DIRT
DIAMOND outvalues DIRT & BOULDER
DIRT carries BOULDER, blocks FIREFLY
BOULDER kills FIREFLY & ROCKFORD
FIREFLY kills ROCKFORD, guards DIAMOND
- LogicDeLuxe
- Member
- Posts: 655
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
Re: GDash new port
That's why I suggested interpreting it while reading the binary file. 0 in a BDCFF file should always be interpreted as 0. Reading a GDS file on the other hand should automatically read 0 as 256 when it is a BD1, BD2 or PLCK game.Dustin wrote: ↑Sun Aug 06, 2023 5:29 pm Come to think of it, even this perfect solution has a potential flaw because there might be GDash original games where scheduling type was set to BD1 and milling timer was 0. If such a cave was made with an earlier GDash version, then 0 should be 0, but the "perfect" GDash version would re-interprete the timer as 256, so the cave would no longer work as intended.
The main reason GDash uses GDS files instead of all BDCFF files is exactly the possibility to fix things like this, I guess.
Re: GDash new port
Ah, I see, this makes a lot of sense! 
BTW should scheduling type "CLCK" also be added? Is there any major difference between 1stB and CLCK scheduling?
I mean, there exists scheduling type "CrDr7" of course, but it's not working for all CLCK-made games, is it? Most other CLCK games have "Construction Kit" as scheduling type...
BTW should scheduling type "CLCK" also be added? Is there any major difference between 1stB and CLCK scheduling?
I mean, there exists scheduling type "CrDr7" of course, but it's not working for all CLCK-made games, is it? Most other CLCK games have "Construction Kit" as scheduling type...
Boulder Dash X Rock, Paper, Scissors:
ROCKFORD collects DIAMOND, digs DIRT
DIAMOND outvalues DIRT & BOULDER
DIRT carries BOULDER, blocks FIREFLY
BOULDER kills FIREFLY & ROCKFORD
FIREFLY kills ROCKFORD, guards DIAMOND
ROCKFORD collects DIAMOND, digs DIRT
DIAMOND outvalues DIRT & BOULDER
DIRT carries BOULDER, blocks FIREFLY
BOULDER kills FIREFLY & ROCKFORD
FIREFLY kills ROCKFORD, guards DIAMOND
-
altermaven
- Member
- Posts: 71
- Joined: Sat Apr 24, 2021 6:26 pm
- Location: Pennsylvania, USA
- Contact:
Re: GDash new port
Alchemyst Dig 2.bd is out of date. The most recent version is 1.02 (13 May 2021). You might want to fetch my bundle release which contains two extra cavesets, which can be bundled into the GDash suite. Check the issue I have submitted.
EDIT: this was rectified
EDIT: this was rectified
Alchemystics Design: The chemistry of creativity.
Boulder Dash 40th prerelease beta tester/bugchecker.
Responsible for Alchemyst Dig/Dangerdash series!
Boulder Dash 40th prerelease beta tester/bugchecker.
Responsible for Alchemyst Dig/Dangerdash series!