The Dink Network

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

If you don't have an account, just leave the password field blank.
Username:
Password:
Subject:
Antispam: Enter Dink Smallwood's last name (surname) below.
Formatting: :) :( ;( :P ;) :D >( : :s :O evil cat blood
Bold font Italic font hyperlink Code tags
Message:
 
 
July 25th 2022, 06:44 PM
spike.gif
SlipDink
Peasant He/Him United States bloop rumble
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;
}