The Dink Network

New D-Mod: Cursed Blades Part 1: Charlie's Legacy

July 22nd, 06:58 AM
custom_king.png
redink1
King Male United States xbox steam bloop
A mother ducking wizard 
The dynamic team of RobJ and ExDeathevn and have teamed up yet again to release a brand new Epic D-Mod: Cursed Blades Part 1: Charlie's Legacy. This adventure is one of the largest I've seen in a while - the map looks expansive (without being too expansive), and it will surely take several hours to complete.

What ever happened to Charlie?

Will the house be forever vacant, with no answers?

Find out as Dink visits the land of Phospher, and uncover the secret of Horn Lace Tactic and Real Shoe UFOs.

Sometimes, tomorrow does actually arrive.

July 22nd, 09:43 AM
pq_knight.gif
ExDeathevn
Peasant Male New Zealand xbox steam
Don't look at me, I'm a ghost 
Tomorrow is proudly sponsor by Milk Downloads.
July 22nd, 11:35 AM
goblins.gif
ebilV
Peasant Male Romania
C# nerd 
Hooray!

Wait, Part 1 and already an epic?! Is Part 2 gonna take 6 years to come out too?
July 22nd, 01:34 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
There is a minor update I just uploaded, pending. This only adds some minor flavor text, fixes a possible attack_hit_sound bug, and disables a screenlock on a certain screen when Dink is cut off from being able to fight enemies.

It's safe to continue playing the current version, and when this is approved, you can install the new version of Charlies Legacy over the top of your current one, and continue your most recent save without any issues.
July 22nd, 01:38 PM
custom_king.png
redink1
King Male United States xbox steam bloop
A mother ducking wizard 
The minor update is available to download now.
July 22nd, 01:59 PM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
be very careful with the numbering. if the series is going to go beyond 2 games, you're finished. dmodders, and even valve are purely incapable of thirds.
July 22nd, 03:23 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
One more minor update coming, this one fixes some more dialogue stuff, and can still be installed over the top.

More important to install this one, since I fixed some bookshelf text that was messed up and unread-able. Not main story stuff, but extra dialogue.

"be very careful with the numbering. if the series is going to go beyond 2 games, you're finished. dmodders, and even valve are purely incapable of thirds."
I will make up for it by finding and releasing 3000 minor updates.
July 22nd, 03:34 PM
custom_king.png
redink1
King Male United States xbox steam bloop
A mother ducking wizard 
Next minor update is now available
July 22nd, 03:48 PM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
2 updates in a few short hours. i swear, with this track record, there's going to be a bug that overwrites all of dink's memory and breaks the player's save entirely.

July 22nd, 03:50 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
"2 updates in a few short hours. i swear, with this track record, there's going to be a bug that overwrites all of dink's memory and breaks the player's save entirely."

Don't jinx me, I already fixed that one. I don't want round 2.
July 22nd, 03:50 PM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
its no jink. its a full blown curse.
July 22nd, 04:02 PM
pq_knight.gif
ExDeathevn
Peasant Male New Zealand xbox steam
Don't look at me, I'm a ghost 
its no jink. its a full blown curse.

A Cursed Blade.
July 22nd, 04:07 PM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
i see. this is all intentional.
July 24th, 12:21 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
And another update. Still minor stuff.

Same same, install over your current Charlie's Legacy, and continue where you left off.

version 1.04
July 24th, 07:01 AM
peasantmb.gif
yeoldetoast
Peasant Australia steam
I've come to get my meat 
Just noticed if I try and look at the pushing or consumable tutorial in the escape menu, I am greeted with the warning screen for flashing "colors" that appears at the start rather than any sort of instruction.
July 24th, 07:05 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
"Just noticed if I try and look at the pushing or consumable tutorial in the escape menu, I am greeted with the warning screen for flashing "colors" that appears at the start rather than any sort of instruction."

Thanks for that. That's not so big of an issue - those options were supposed to be removed altogether from the help menu, since we ended up putting the tutorials in game. I removed the content, but forgot to remove the option, and its just loading that bmp when you select them.

Not worth doing a separate update just yet, just for that, I'll wait and see if there's any other bugs and will remove those options when another update needs doing!

Also be sure to install the new version, which was revently approved.. this one is sort of important, fixes a freeze bug late game:

1.07
July 24th, 07:24 AM
anon.gif
ghostknight
Ghost
 
The game freezes at the tile puzzle. Here is a screenshot:

https://ibb.co/d6fNQ8y

After I read the sign it just stays like this, no matter how often I hit "shift", "escape" etc.

Another thing I noticed, when I first enter that room the game lags and it comes to a crawl. It only returns to "normal" speed after I read the papers in the neighouring (right) room.

I am using GNU freedink 109.6, Linux version.
July 24th, 07:50 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Hi Ghost Knight.

Unfortunately, I am not able to re-produce any of the above on my end. Although I did not test this on Linux.

Did you try loading an earlier save and re-entering to see if it happend again?

The puzzle works fine for me, and no lag. I'd be interested to see if any other Linux users experienced this.

As an extra measure, can you send me your save game file as well, I'll test on my end.

July 24th, 08:08 AM
anon.gif
ghostknight
Ghost
 
Thanks for replying, robj. I have tried everything you suggested, the result was always the same.
Here is a link to a save file.

https://ufile.io/xec88isg
July 24th, 08:31 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
This is not good. Your save file works perfect for me.
Could this be a Linux issue I wonder.
It's the same FreeDink version so I wouldn't think there would be any difference in the way it would operate on Linux.

If anyone else who has Linux can confirm, that would be great. Maybe SlipDink will see this and respond.. I think he's a linux user.
July 24th, 09:51 AM
death.gif
Savefile works for me too, no lags either. Windows 10, FreeDink, non-English keyboard layout.
Oh, and thank you guys for implementing hints. I was stuck for a while, now I'm having progress again.
The D-Mod is quite fun so far. Except for the sliding puzzle. Then again, I could solve it without external help, just took a bit long.
Then again, it says a lot for the quality of the puzzle that someone as incompetent at puzzles like myself can solve it.
July 24th, 11:22 AM
pq_knight.gif
ExDeathEvn
Peasant Male New Zealand xbox steam
Don't look at me, I'm a ghost 
A cryptic hint on the tile puzzle solving method is on the solution screen, if you can work it out. The tile puzzle was a concept I wanted to bring into existence based on a similar puzzle type, and took a lot of effort (more on Robj's part) to bring into existence.

Odd that there is a possible issue wih it for Linux users. If it can be reproduced and/or any can get to the next screen, there is a hint for an additional method to get past. However it costs you completon percentage (see Savegame menu)
July 24th, 12:40 PM
spike.gif
SlipDink
Peasant Male United States bloop
2nd generation. No easy way to be free. 
As one of the resident Linux users here at the DN, I downloaded the https://ufile.io/xec88isg save9.dat file from ghostknight and loaded it up.

Once Dink started reading the sign, things went ok until the game froze with the explanation of the use of the arrow keys, the Escape key and the shift key still on screen.

I'd sure like to see this fixed since I was just about at the same place in the game as ghostknight and I'd hate to have to give it all up.

I'm using GNU FreeDink 109.6 on Ubuntu 22.04 LTS.
July 24th, 01:29 PM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
how about through wine
July 24th, 01:32 PM
anon.gif
ghostknight
Ghost
 
I ran freedink from a shell and took a logfile:

https://ufile.io/8g93x0l4

I do not know if the errors are the cause of the freeze or related.

I tried to "fix" it by downloading and recompiling the source with "MAX_VARS" and "MAX_SCRIPTS" set to 5000. It still complains that it ran out of "var space", all 5000 used.

Possible WORKAROUND, but also SPOILER:

I further took a peak into the scripts and thus I learned that I can use the wrench to tamper with the controls. If I read the sign while having the wrench equipped I get the option to tamper with the machine. This is the only way I can advance in the game and earn a flattering compliment as a reward after I collect the talisman. I do not know if I have to read the papers in the next room first to get the option to tamper but it sure is recommended since it removes the lag.
July 24th, 01:35 PM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
it removes the puzzles, too, which is quite lovely.
July 24th, 01:52 PM
anon.gif
ghostknight
Ghost
 
it removes the puzzles, too, which is quite lovely.

Puzzles? Plural?! Do you mean it removes ALL the puzzles? That would not be good.
July 24th, 02:32 PM
death.gif
I wish I knew that before.
July 24th, 02:49 PM
pq_knight.gif
ExDeathevn
Peasant Male New Zealand xbox steam
Don't look at me, I'm a ghost 
So it's been discovered now - The Sliding Tile puzzles (yes, plural) can be bypassed using the Wrench - Which break upon use but can be repaired later. Reading the notes in the next room simply eludes to it being possible.
For Linux users this might be the only option though, sadly, until we can work out what the problem is.
Edit: This Shortcut come at a cost.
July 24th, 03:06 PM
goblins.gif
ebilV
Peasant Male Romania
C# nerd 
>Hooray!

>Wait, Part 1 and already an epic?! Is Part 2 gonna take 6 years to come out too?


I would like to point out that when I made this post for some reason I thought Charlie's Legacy is the same thing as The Dark Avilan...
July 24th, 04:03 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
"Puzzles? Plural?! Do you mean it removes ALL the puzzles? That would not be good."

No, not all the puzzles. It's an extra way to bypass tile puzzles, if you have a wrench handy, because we knew it was cryptic and probably should make another way past. It only works if you examine the correct papers, so when ghost knight said it was recommended to read the papers.. well, you can't do the wrench trick without it.

I'll be trying to fix the bug Linux users experienced anyway. So obviously Linux and Windows has a different FreeDink version or something? Even though they both say 109.6? Weird..

Edit: Indeed for some reason on Linux, it is exhausting all variable space. I will look into this.
July 24th, 07:25 PM
death.gif
So, uh... what exactly is the goal of the pillars puzzle?
July 24th, 09:43 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
"So, uh... what exactly is the goal of the pillars puzzle?"

As in. what's the answer?

So I'm currently debugging the Linux version. There's clearly some shenanigans going on. There is over 200 variable slots used and over 100 scripts used on Linux when enetering that screen.

When playing on windows, it's 69 variables, and 39 scripts.
Thats a massive difference. I'll report back soon.
July 24th, 10:20 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Ok, reporting back.

This Linux version definitely differs to the windows version, and let me just say, this is NOT a Charlie's Legacy issue. This would cause havoc in any dmod making use of "external" when passing arguments. Is it an earlier version compared to the windows one? 109.6.x?

I don't know.

Basically, it does not treat aguments passed to procedures as "pseudo" variables... it's treating them more like globals. So if I call a procedure with external at some point in the game (on the linux version), and pass say, 8 arguments to the procedure, and then later on call a different procedure and only pass 3 arguments, it will remember the previous values for &arg4 - 8 from the previous procedure, instead of reading them as 0(as it should since nothing was passed).

Short of editing every external call in the entire game, there would not be any other fix.

Actually, this is unfix-able come to think of it. because if externals are stacked in procedures, you lose your previous &arg values, because they are overwritten by whatever the last external call was.

This version is beyond broken because of this, it will make a mess of external procedures when they rely on &arg1 - &arg8.

What's the normal version that Linux users are usually playing with, when not using this 109.6 linux version? Maybe I can try to alter the dmod to get it working on it. Is it 108.4 or something?

If you see this SlipDink... let me know.
July 25th, 02:43 AM
peasantmb.gif
yeoldetoast
Peasant Australia steam
I've come to get my meat 
It should be identical across platforms. You can see which packages are used in various distros here but all of them are 109.6 except for FreeBSD and old Ubuntu 18.04 which use 108.4 by default. I tried the save file on macOS under 109.6 and the same thing is exhibited there with endless "unknown var &val1" errors due to dc-f.c. I have a feeling we're dealing with something deep here such as a 64-bit portability problem.

Edit: I was right. I loaded up a VM of Debian i386 with Freedink and it seems the tile puzzle works perfectly!
July 25th, 04:00 AM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
the simplest solution may baffle some of you. i do not think you are quite ready for this revelation.

do not use any linux distro.

speaking of dink on weird, alternative platforms, has anyone tried running dink on the steam deck? or is that overhyped money pit still not being sent to anyone?
July 25th, 05:36 AM
goblins.gif
ebilv
Peasant Male Romania
C# nerd 
I don't think the Steam Dink is out yet? I've actually ordered one because I want to mess with it a bit, but I haven't received any notification about it yet...

As for the 64 bit issue... I wonder what the heck is going on there...
July 25th, 06:04 AM
peasantmb.gif
yeoldetoast
Peasant Australia steam
I've come to get my meat 
I'm not exactly sure, but if ghostknight or anyone else has a working build system it would be interesting to see if doing what shevek suggested in this thread, i.e. changing every instance of "int" in dinkc.cpp to "int32_t" so as to enforce 32-bit data types, and then recompiling would rectify things. It may break them in other ways, or the issue may lie elsewhere, however.

Otherwise, in the short-term, the only thing I could suggest for those on GNU/Linux is setting up a 32-bit chroot with corresponding libraries and then compiling Freedink in that, or otherwise just doing what I did and using a 32-bit distro in a VM and taking a performance hit. SlipDink also uses Wine which might also be a suitable last resort, despite the sheer absurdity of doing that .

You may also be able to get away with passing the -m32 flag to GCC upon compiling all the necessary libs yourself along with Freedink without a chroot though. Not sure...
July 25th, 11:51 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Yeh, this Dmod makes use of external procedures a lot. So it's not just the tile puzzle I'd be worried about. If you continue playing in that broken Linux version, you will probably encounter game breaking bugs and other strange minor bugs caused by that.

EDIT: Version 1.08 released. It is recommended to upadte your Charlie's Legacy install before continuing your save. It's again, nothing major though.

"Oh, and thank you guys for implementing hints"
You will be thankful for solving the first tile puzzle properly. If you bypass it, you get penalised by not getting any hints (unless you go back and solve it properly)
July 25th, 06:44 PM
spike.gif
SlipDink
Peasant Male United States bloop
2nd generation. No easy way to be free. 
Sigh... I find it a bit annoying that some folks are mixing this conversation with Discord conversations on the same topic. Oh well... to my main points.

First, a word about the reference in Discord that RangerLord about a dmod bug that he called a "strange one in @SlipDink 's last D-Mod that only happened in FreeDink for Windows." The problem was one that permeated a major part of the code. I can tell you what the essential change made was to fix things. I had many places where I thought that an "sp_touch_damage(&current_sprite, 0);" at the top of the touch() procedure followed by a "wait(xxx);" at the end of this touch() procedure would give the player plenty of time to move away from the touched object before I invoked "sp_touch_damage(&current_sprite, -1);" again to allow for the object to be once again touchable. No matter how large I made xxx, it seemed to not work as anticipated. Yet somehow, I did not see this problem during development. I'm not clear on why that is, though I have a theory about it that I can't really test. But, I can tell you that it seemed that somehow the "-1" variant got executed before the xxx period transpired during RangerLord's testing. The fix I made was to REPLACE almost all of these troublesome touch() procedures with similar code in a talk() procedure and to invoke "sp_touch_damage(&current_sprite, 0);" at the top of main() in each script where I made this change.

Second, please remember, the &arg[n] family of variables are "PSEUDO variables".
https://dinkcreference.netlify.app/guide/procedures.html#advanced-procedures

This tells me that in DinkC, there is (in effect) no real stack. They are NOT stack variables, THEY ARE GLOBALS. That is what I understand by the term "pseudo variables".

Therefore, in Contact Charlie's example on Discord (reproduced below), we should not expect Dink to say anything but "7". In DinkC, I have always coded by this understanding and have never had problems with the "pseudo variables".
=====================================================
void main(void)
{
external("test", "test", 1);
}

void test(void)
{
external("test", "test2", 7);
say("&arg1", 1);
return;
}

void test2(void)
{
return;
}
July 25th, 06:56 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
"This tells me that in DinkC, there is (in effect) no real stack. They are NOT stack variables, THEY ARE GLOBALS. That is what I understand by the term "pseudo variables".

While that may be the case, that seems to be the only Dink version I've seen that behaviour occur in.

Even in Vanilla 1.08 for windows, and DinkHD, it works in the way I described. This is the way I've always coded.

And I disagree. In fact nothing in the pseudo variable list is a true "global" in the way other globals are declared, they all work in different ways, sure, but they work as described in the list. But even back in the 1.08 days, when an argument was passed to a procedure, that argument value was specific to that procedure. I tested this on many different engines again. That linux 109.6 version is the only one that behaves in that (in my opinion) incorrect way. I'd say the way the other engines do it, that allow you to store more values without having them overwritten seems like the intended purpose anyway(especially since the odd one out of all the engines, is that it doesn't do that) I definitely won't be wanting to re-write several hundred lines of scripting to conform to the one odd engine out of the bunch.

So Freedink 109.6 on Linux is the only one that overrides arguments passed to procedures. I tested that script on Dink Smallwood 1.08, Freedink 108.4, Freedink 109.6(windows), DinkHD. They all make Dink say "1" in that scenario, since that is the 1st argument passed to that procedure. The wording makes sense in the DinkC reference for this as well. For instance under &arg1, It does not say "the last known first argument passed to a procedure" (like it does with pseudo variable &return, which does in fact get overwritten, as it's supposed to, with the last known return value). It simply says "The first argument passed to a procedure.", and all engines besides that one linux version behave that way. I'd be more likey to try and get it working for an older version of FreeDink on Linux that DID behave in the correct way. I think FreeDink 108.4 for Linux, probably. This Linux 109.6 seems to have issues.

Pseudo Variables

Edit: Furthermore, as user "someone" says here, he looked in the original source code every script has it's own &arg1-9 variables, so yes, the Linux version is indeed buggy. It took out this functionality and made them "globals" (they aren't supposed to be). This was all the way back in 2008, as I said, back in the 1.08 days.
'Someones' post on &arg1-9 variables
They are supposed to be able to be different values in different scripts, concurrently.
July 26th, 05:35 AM
peasantmb.gif
yeoldetoast
Peasant Australia steam
I've come to get my meat 
I got a build environment going and tested a few things out. Changing dinkc.cpp's integers to 32-bit ones didn't do anything, but for fun I decided to compile a 64-bit Windows exe (if anyone wants it, let me know) in MSYS2 with the expectation that it would grind to a halt like on Linux/macOS x64 only to run it and discover that the tile puzzle works perfectly... The question now seems to be why is 109.6 not clearing those variables specifically on *nix x64 platforms and perhaps vindicates Skorn, just this once.

I also tested that external() demo script on the broken x64 platforms, as well as known good ones, and all made Dink say "1".
July 26th, 05:55 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Well hopefully the Linux build can be fixed to rectify this issue(and any other issue that might be present). Until then, to put it plainly - it's botched, and some dmods won't work as intended.

But yeh, another issue that would come of how Freedink on Linux treats &arg as global variables, instead of the way they are supposed to work as described in their pseudo variables description, is that if you call an external procedure and specify no extra arguments, it'll actually pass whatever arguments were prior(if you've called externals previously). So if you're external proc is based on &Arg checks you'd basically always have to pass eight 0's to make sure they are cleared. Which is counter-intuitive. If nothing is passed, it should be 0's by default - Again, script specific. Not global behaviour.
July 26th, 11:45 AM
spike.gif
SlipDink
Peasant Male United States bloop
2nd generation. No easy way to be free. 
It may be true that Dink engines for Dink Smallwood 1.08, Freedink 108.4, Freedink 109.6(windows), DinkHD all actually implement real stack variables. However, I seem to recall that 100% of the prototypes for internal to DinkC scripts and user generated functions follow the format "void function_name( void );". This fact, plus the idea that the "&return" pseudo variable (like the &arg[n] variables) is clearly a global(*) which DinkC documentation also calls a "pseudo variable", led me to believe that there are no (user accessible) stack variables in DinkC. We (Robj and I) apparently read "the way they are supposed to work as described in their pseudo variables description" VERY differently.

Behaviors like external() seeming to "actually pass whatever arguments were prior (if you've called externals previously)" sure sounds to me like these variables are intended to be global variables. In my opinion, according to the way I read DinkC documentation, this use of pseudo variables as globals may be poor design, but it also seems like the intended design. I just accepted this as another quirk of DinkC, like there being only one type of variable (int) available.

To me it seems ironic that if the scripts Robj mentions actually used the &arg[n] and &return variables as globals, that they would work on all current platforms.

But more important (to me) is the fact that "some dmods won't work as intended" and that some of us don't care about that for ANY of the Linux users coming here from using 1.09x in their distro. They will be in for some serious disappointments. This seems to me to be as troublesome as the many problems that seem to surround the DINKHD series that could cause people to leave the DN in frustration.

It may be the case that "Contact Charlie" on Discord thinks that this not important when he said, "I thought my dmod was at fault and I spent time yesterday getting ubuntu loaded up on a virtual machine only to find that the FreeDink engine is to blame. Only on Linux. That's as far as I went. Not my problem anymore. lol", BUT the end result will mean that we will once again find a way to loose newcomers who show up at https://www.dinknetwork.com/ looking to become part of our community.

(*)according to this text from https://dinkcreference.netlify.app/guide/procedures.html#advanced-procedures:
[
It is also possible for custom procedures to return values. Note that it is not possible to get the return value of a custom procedure like an internal function. You must use the &return pseudo variable.
]
July 26th, 02:55 PM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
this is the sort of thing that prevents most devs from bothering with designing or updating their games to be compatible on linux.

linux is horseshit and there's a billion different versions of them.
July 26th, 03:00 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Seth is currently fixing DinkHD so Charlie's Legacy works on it, and in doing so, improving compatibility for other dmods.

This is the way Dink Smallwood has always worked. This is a flaw with the Linux version.

Yes it says it is possible to return values for custom procedures, and when it says that, it is using the example to get that value using the psesuo variable &return, which is the "last known return value from a procedure". That's working how it says it does, as Redink1 implemented when he added such functionality in Dink.1.08. works the same way in every engine, unlike &arg variables.

I don't know why you're trying to insinuate my dmod is to blame or something and I should fix it, it's not broken, and would take me ages to manipulate every script to get it working with the way that engine handles things. The engine it doesn't work on is faulty, plain and simple. There are ppl on the discord discussing why it's broken, trying to get it to build properly.

The solution is NOT to limit a dmods potential by restricting our scripting in such a way we have to work around an issue that makes it so the engine isn't giving each script number their own &arg1-9's, AND also not clearing them to 0 when NO arguments are passed. The solution is for someone to fix the Linux build so it works.

Freedink has a new maintainer according to the website, maybe someone should email and let them know of this fault.

EDIT. An update on the DinkHD thing I mentioned. Seth has been in contact with me updating me, and it looks like we are on track to having it working fully, so Charlie's Legacy can be played from start to finish. So far Push and Pull(which only previously worked on FreeDink, and would lag on DinkHD), now actually runs smoother on DinkHD.

EDIT2: Some folks are already coming up with a fix, so it might just be a case of getting the current maintainer to make those changes officially..
July 26th, 03:20 PM
anon.gif
ghostknight
Ghost
 
EUREKA! After patching the source and recompiling I finally got it working. There is no more lag, no 'out of var space' errors and the puzzle tiles glide smoothly. The escape and shift key work as intended.

It is a bug that exists in 109.6 and probably prior versions. The linux "version" does not treat variables differently because it is the same code as for windows. The bug simply does not show when compiled with the windows compiler. It shows when compiled with a Linux (gcc) compiler. You may think that this is weird. It is actually a lot weirder. None of those compilers are broken. The C standard allows that and both compilers conform to that standard. I do not know how familiar you are with C, so I am not sure if you are interested in a further explanation.
July 26th, 03:25 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
@ghostknight Well, I did find it weird why the same version on 2 different OS's was behaving differently. I assume this means &args are working correctly now?

If so, that's great news.
July 26th, 03:28 PM
goblins.gif
ebilV
Peasant Male Romania
C# nerd 
I started looking around the dinkc.cpp source, to see how this argument stuff is working, things are pretty complicated at first glance...

First of all, it seems that all functions, regardless if they're engine functions or user functions, they get processed with the function "get_parms" on line 1748. This function parses a function's parameters and stores them in temporary buffers depending if they are strings or integers (line 50)
/* store current procedure arguments expanded values of type 'int' (see get_parms) */
static long nlist[10];
/* store current procedure arguments of type 'string' (idem) */
static char* slist[10];


Next, the first thing "get_parms" does is to clear these temporary registers, so they are guaranteed to be 0 / empty strings before parsing (line 1750)
  /* Clean-up parameters */
  memset(nlist, 0, 10 * sizeof (int));
  {
    int i = 0;
    for (; i < 10; i++)
      slist[i][0] = '\0';
  }


The function "get_parms" uses the function "decipher" defined on line 603, here you can see that when deciphering the special &return, &arg1 .. &arg8 variables, the &return variable is indeed a GLOBAL one, but the &arg variables are CONTEXT dependent on the current script! (Line 611)
//v1.08 special variables.
  if (dversion >= 108)
    {
      if (compare(variable, "&return"))
	return returnint;
      if (compare(variable, "&arg1"))
	return rinfo[script]->arg1;
      if (compare(variable, "&arg2"))
	return rinfo[script]->arg2;
      if (compare(variable, "&arg3"))
	return rinfo[script]->arg3;
      if (compare(variable, "&arg4"))
	return rinfo[script]->arg4;
      if (compare(variable, "&arg5"))
	return rinfo[script]->arg5;
      if (compare(variable, "&arg6"))
	return rinfo[script]->arg6;
      if (compare(variable, "&arg7"))
	return rinfo[script]->arg7;
      if (compare(variable, "&arg8"))
	return rinfo[script]->arg8;
      if (compare(variable, "&arg9"))
	return rinfo[script]->arg9;
    }


One thing to note is that each function can have up to 10 parameters that can be either string or int. In practice, only engine functions can use string parameters, user functions can only use up to 8 int parameters! Why 8? Because they are called with "external", which passes its own arguments starting with &arg3 to the user function. Parsing the "external" function is done on line 2540. I'm not going to post the whole code segment, but there you can see that "external" parameters are defined like this:
int p[20] = { 2, 2, 1, 1, 1, 1, 1, 1, 1, 1 };

Which means the first two arguments are string, the next 8 are int.

Next, after "external" parses its arguments successfully, it sends them to the called script's own context here: (line 2559)
	      rinfo[myscript1]->arg1 = nlist[2];
	      rinfo[myscript1]->arg2 = nlist[3];
	      rinfo[myscript1]->arg3 = nlist[4];
	      rinfo[myscript1]->arg4 = nlist[5];
	      rinfo[myscript1]->arg5 = nlist[6];
	      rinfo[myscript1]->arg6 = nlist[7];
	      rinfo[myscript1]->arg7 = nlist[8];
	      rinfo[myscript1]->arg8 = nlist[9];


So putting all of this together, it means that the correct behavior for Robj's test code above is like this:

>SCRIPT 1: main gets called, in turn it calls its own test function using "external",
>SCRIPT 2: test gets called, in this context, &arg1 = 1, now external calls its own test2 function
>SCRIPT 3: test2 gets called, in this context, &arg1 = 7, nothing else gets done so the script ends
>SCRIPT 2: we're back in test, it calls "say" next, passing the 1st argument a string with the value of &arg1, and the 2nd argument an int with the value 1, when "get_parms" parses "say" arguments, when "deciphering" the &arg1 value, it should use SCRIPT 2's own context, so say will effectively display "1";

>after say does its thing SCRIPT 2 exits and we are back in SCRIPT 1 which also exits

So I think SlipDink is wrong in his assumption here:
Therefore, in Contact Charlie's example on Discord (reproduced below), we should not expect Dink to say anything but "7".

The only way "say" would evaluate "&arg1" to 7 is if SCRIPT 2 and SCRIPT 3 contexts end up using the same script ID, which should be buggy behaviour...

EDIT: @Robj
This is the way Dink Smallwood has always worked. This is a flaw with the Linux version. I would literally have to take most of my externals and do this for the later ones:
External("<script>", "<proc>", 0, 0, 0, 0, 0, 0, 0, 0);.


This should definitely NOT be necessary ever. According to my understanding of the dinkc parser code, unused arguments should be guaranteed to be 0 when calling a function with "external"...

July 26th, 03:33 PM
goblins.gif
ebilV
Peasant Male Romania
C# nerd 
ghostknight, so what exactly did you patch to get it to work? Would be useful to know.
July 26th, 04:04 PM
anon.gif
ghostknight
Ghost
 
/* store current procedure arguments expanded values of type 'int' (see get_parms) */
static long nlist[10];


Change long to int! A long takes up 8 bytes on a Linux 64bit system and an int uses 4 bytes. Thus, the entire array takes up 80 bytes. However, the code here
/* Clean-up parameters */
memset(nlist, 0, 10 * sizeof (int));


Only cleans up 40 bytes (10 * sizeof(int) = 10 * 4 = 40). So the last 5 elements of the array never get cleared. This is what robj observed when he suggested that only explicitly passing '0' in a function may "fix" it.

In conclusion, robj's dmod is NOT to blame.
July 26th, 04:50 PM
goblins.gif
ebilV
Peasant Male Romania
C# nerd 
Oh my lord I'm blind, how did I not see that long?!

Edit: I even quoted it and I missed it... I really am too tired.

Edit2: Hmm, perhaps, it would be a good idea to replace all shorts/ints/longs with int16_t/int32_t/int64_t to make sure everything is the intended size?...
July 26th, 05:13 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Hopefully a fix can be submitted to the current maintainer so it can be updated officially and the Linux people can also enjoy this dmod, it sounds like it's possible.

Now for an on topic post. For those currently playing, I have uploaded another update.

Charlie's Legacy Version 1.09

This fixes a crash bug that will happen only when Dink is wielding a certain secret weapon, and he gets shot by an enemy missile.
Also adjusted text box scripts so the background sign text boxes properly wrap around the text when using DinkHD.

Also, I left some key-## scripts for debug purposes in version 1.08 by accident, which only will be triggered if the correct keys are pressed. These won't affect game play if you don't use them.. if you accidentally press a key that brings up an extensive menu full of debug options, close it(last option on all of them). In the next version update(when DinkHD is done and I'm finished tweaking a few things), I'll overwrite those debug scripts to get rid of the menu's.

Please note a Dink Smallwood HD update hasn't been released by Seth yet, he is still ironing some stuff out, so probably wait for that first before playing on Dink Smallwood HD or it might crash sometimes.
July 26th, 05:50 PM
anon.gif
ghostknight
Ghost
 
Oh my lord I'm blind, how did I not see that long?!

Well, someone made a comment in the line above with the clear intent that he wanted 'int' ... and then went on and defined 'long'

Hmm, perhaps, it would be a good idea to replace all shorts/ints/longs with int16_t/int32_t/int64_t to make sure everything is the intended size?...

I tried that but then the dmod did not recognize the freedink version. It said 1.08 (?), I think, and would not start. I did not investigate any further.
I was going to look for other 'long' variables that get assigned to 'int'.

There are some other issues that *might* be problematic, e.g., in line 2580:

strcpy (s, h);


The compiler issued a warning that source and destination overlap, so I changed that, too

strcpy_nooverlap(s, h);


I saw several statements, like

intval = atol(parm);


which should be changed to

intval = atoi(parm);


I was thinking about uploading my build script which will compile the patched 109.6 version and install it in '/opt'. It *should* work on any debian based system. Let me know if there is interest for that or if you prefer to wait for the maintainer to release a new version.
July 26th, 06:28 PM
goblins.gif
ebilV
Peasant Male Romania
C# nerd 
We don't really know what the maintainer is up to, so I'd vote for you uploading your patch. Shoot the maintainer a DM over at http://savannah.gnu.org/users/kjharcombe too for good measure.
July 27th, 01:34 AM
peasantmb.gif
yeoldetoast
Peasant Australia steam
I've come to get my meat 
Yes ghostknight your build script would be greatly appreciated! Does it also patch that SDL2 error in input.cpp?

If the new maintainer doesn't get in contact with us soonish, it might be about time we considered starting our own fork. I would also suggest that RobJ write a simple test case for this to include in his Version Checker so as to inform users that their x64 build is incompatible.
July 27th, 01:57 AM
anon.gif
ghostknight
Ghost
 
Does it also patch that SDL2 error in input.cpp?

Yes, it does.
July 27th, 02:00 AM
goblins.gif
ebilv
Peasant Male Romania
C# nerd 
Now that I know how to actually build it, I'd be willing to fork it over to my github and apply all the fixes if no one else wants to do it, but before we consider that, has anyone actually contacted the current maintainer?

I would also suggest that RobJ write a simple test case for this to include in his Version Checker so as to inform users that their x64 build is incompatible.
That sounds like a good idea!

Edit: PS I see Seth lurking around here, if you're reading this know that I am excited about DinkHD getting updates having better compatibility, since I'm mainly a windows user myself. (Although as far as I know it's not available for Linux user, so that's unfortunate for them)
July 27th, 02:34 AM
peasantmb.gif
yeoldetoast
Peasant Australia steam
I've come to get my meat 
I did manage to get RTDink compiling and (sort of) working on Ubuntu a few months ago because I wanted it to work on my Jetson Nano, but the reception was lukewarm and then I just kind of forgot about it. If any Lunix Users are interested I can upload the build scripts and a guide for that too. Seth seems quite happy to accept pull requests for the cmake side of Proton/RTDink as well which could mean with a bit of tinkering we could easily get full Linux support and perhaps generate an AppImage.

I've just signed up on Savannah and sent the new maintainer a message with a link to this thread explaining briefly what's going on.
July 27th, 03:39 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
I actually updated vcheck today, but not for that, for a bug rangerlord found that makes 109.6 detect as vanilla 1.08 if sound is disabled.

But yes, if there is another working version for Linux users it would be a simple matter to add the current Linux 109.6 into vcheck to block it

I will wait til the fork is available to download so Linux users have the working version, then update my vcheck script!

EDIT: Yeh, wth, I ran that &arg test again, and Dink responded correctly with "1", on the Linux version, so why did it not work the other day when I tested it?! Strange shenanigans.. But anyway. At least Ghostknight found a fix for the actual issue, because it was somehow messing up the arguments passed to some procedures in Charlie(wrong values stored) and making that tile puzzle not function (as well as the maxing out the variables and scripts bug)
July 27th, 06:53 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
"The linux "version" does not treat variables differently because it is the same code as for windows. The bug simply does not show when compiled with the windows compiler"

I was thinking about this, and I think maybe windows has it's own bugs, maybe due to these issues in the code. As I said on discord:

That might explain some weird disappearing sprite bug I kept experiencing that I could not figure out (there was no reason why it should happen), it was editor placed sprites too, not created sprites(although it might have happened to both), and it would only happen after you've played for a long period of time. It happened once to someone in the ending of the dmod, and once to someone else half way through, both when playing for a long time, both for no reason. The sprites would be there, dialogue would work, but they were not drawn. Maybe that's part of the windows version stuffing up cause of some of that stuff I dunno. It was strange indeed, a rare bug that was very random.

Or it could be un-related or a different issue. I don't know. I can't re-produce it in any reliable way. Just happens rarely, after playing for a long time (hours) without closing the game. And then saving and loading(sometimes closing the game) fixes it.
July 27th, 07:20 PM
peasantmp.gif
Skurn
Peasant Male Equatorial Guinea xbox steam duck bloop
can't flim flam the glim glam 
this duckin dmod is pushing the boundaries and windows is better at handling it.
July 27th, 07:51 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
"this duckin dmod is pushing the boundaries and windows is better at handling it."

Not just in Charlie's Legacy, that bug. I've experienced it in 3 others dmods, so it probably is something to do with what ghost knight found or something.
July 29th, 03:33 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Version 1.10 of Charlie's Legacy is available. Fixed a few more minor things and removed some debugging stuff I accidentally left in the last version, where Dink will say random numbers in some situations.

This is also perfect now to play with the new DinkHD 1.97 beta that Seth just posted in a separate thread.
July 29th, 12:45 PM
anon.gif
ghostknight
Ghost
 
SPOILERS ahead!

...

I am attaching a savefile.

The magic barrier to the north is already down. Go through the accessible tunnel and use warppoint to 'enchanted oasis'. Try punching the magic pole. The game freezes.

Dmod version is 1.10.

@Robj can you check if this is a dmod issue? Otherwise it may be another bug in the freedink source.
July 29th, 01:21 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
"@Robj can you check if this is a dmod issue? Otherwise it may be another bug in the freedink source."

I tested your save on windows FreeDink 109.6 and Dink Smallwood HD 1.97 - everything works fine.
Weird thing too, the north barrier was indeed down for both FreeDink 109.6(windows) and DinkHD (as it should be since puzzle is solved). When I loaded the save file on FreeDink 109.6(Linux), it was not down, and the puzzle reset itself. Also yeh, when I tested on the FreeDink Linux build the oasis entrance screen lagged really bad, and hitting the pole crashed the game.

The lag tells me that the FreeDink engine somehow bugged out and maxed out all the scripts and variables again, it was the same thing that happened when it did it on the tile puzzle screen. Maybe you didn't notice the lag, because you were using your patched version, and you fixed that issue, the puzzle resetting could also be a symptom of the unpatched version(I didn't update the Freedink version I was using on my Linux VM with your patched one yet).

I did find a typo in one script on that screen where sp_brain(16) instead of sp_brain(&current_sprite, 16) was used, and my first instinct was maybe for some reason FreeDink Linux had a problem with this typo, instead of ignoring it like the other engines do - but no, I fixed it, and still experienced the lag and crashing when hitting the pole. Anyway, I've flagged that typo to fix if I do another update(it's not worth it's own update, since it doesn't even affect anything in game)

There's only 2 scripts on that screen, both basic. So, that one is an even bigger mystery to me.
So yes, this crash seems to be another issue in the FreeDink Linux source.
July 29th, 11:26 PM
peasantmb.gif
yeoldetoast
Peasant Australia steam
I've come to get my meat 
Hi ghostknight, I just tested that save file in Debian and can confirm it crashes at the point you mention. However, when I switch off sound it seems to work perfectly and I get the little explosion meaning it must pertain to what Gokussj mentioned in the other thread:
"FreeDink crashes with SIGSEGV (Segmentation fault) when a specific sound plays like hitting an object".

I haven't looked into it yet, but I assume the problem is with SDL2-Mixer in certain circumstances.

Edit: It seems to occur when punching any sprite on that screen, and even when going back through the warp sometimes. I wonder if it's related to this
August 5th, 12:30 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Charelie's Legacy version 1.11 released.
August 7th, 10:44 PM
pq_knight.gif
ExDeathevn
Peasant Male New Zealand xbox steam
Don't look at me, I'm a ghost 
Updated to Charlie's Legacy version 1.12
August 8th, 02:58 AM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
I believe 1.12 should work on FreeDink 109.6 for Linux. If anyone experiences any bugs, let me know.
August 8th, 12:37 PM
duck.gif
Koera
Peasant Finland
 
[Warning: Spoilers ahead]

Hi, could someone please tell me if I've missed something along the way: I got a light sword and another flaming one and I think that I reached the main goal /shock of the game. My issue is a pile of wood that is in my inventory. I got it from a logger but I did not find any use for them? My save game data at Undersea Volcano says 75% and for me that number looks a bit low if there is only a few screens left. Please tell me if there is more to be explored?

ps. sorry for posting here, but I'm not able to begin a (new) File Discussion at the DMOD page, where they usually are located at.
August 8th, 12:42 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
[Warning: Spoilers ahead]

Hi Koera, there are intentionally a number of secert areas in the game to explore, some are very cryptic indeed, super secret I guess. The percentage system is indeed there to let you know if you've missed anything. You need to get absolutely everything (not including pickups - they don't count towards percentage) to receive 100%.

The wood is part of a fetch quest, if you can remember who gave it to you, you can go back and talk to that NPC and there will be a clue given by either the NPC or Dink as to where to take it.

EDIT: As for the rest of the percentage your missing.. I don't know, because I don't know what side-quests/secrets you have and haven't found. I'd have to list everything

I do plan to release a walkthrough of Charlie at some point later. And also I will live stream a full playthrough of it at some point, where I get 100% (And also get something else that doesn't contribute towards percentage that I'll wager no one has found)


EDIT2: Keep in mind, trying to get everything when you reach the near end of the game will prove impossible. Certain side quests are only available for certain periods of time.
August 8th, 04:34 PM
custom_robj.png
Robj
Jester Male Australia
You feed the madness, and it feeds on you. 
Oh and also

Version 1.14 released

That ones kinda imporant. If you're mid play, please update. Ebil found a bug where a certain thing can revert &story variable backwards, essentially rewinding progress. So, throw that in if you are mid-play.